|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Attempt to add color to MvM running on MacOS 7/8/9 PPC (Read 168223 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #30 on: December 29, 2024, 21:42
Ok, I'd say halfway there... The old non-AppleEvent way is CountAppFiles(), my CodeWarrior's Universal headers don't include it, but I have the code in there to try on older CodeWarriors or MPW at some point... https://preterhuman.net/macstuff/insidemac/Files/Files-68.html I have my AppleEvent code basically working...but...it turns out the AppleEvent contains an FSSpec, which is very much not a filename! I have code for Carbon that turns the FSSpec into a filename string, but looks like I never wrote the version for classic MacOS because at the time I couldn't figure it out! If I remember correctly, it turns out being a bit of a pain. When I wrote my AppleEvent stuff, I was mostly developing for Carbon. Obviously I'll be looking into it with fresh eyes soon. Below is the debug printf output from a run of MvM where I dropped a disk icon on the application... ---- amac_initAppleEvents()... Initing AppleEvents... amac_initAppleEvents() done. amac_waitForHighLevel()... amac_waitForHighLevel native event type 0 amac_waitForHighLevel native event type 23 amac_handleHighLevel()... Received AppleEvent: OpenDoc. Calling amac_handleAEDescList to handle parameters... amac_handleAEDescList()... 1 items passed in appleEvent. (Get fullPathBuf not implemented on classic MacOS!) fullPathBuf is '' Going to OpenWD... Going to SetVol... Going to CloseWD... Getting fname from fullPathBuf... 1 : '' vRefNum=-1 parID=56682 amac_handleAEDescList() done. Done handing OpenDoc event. amac_handleHighLevel() done. amac_waitForHighLevel() done. Going to call SDL_main... Going to call InitOSGLU... Going to call ScanCommandLine... Couldn't open audio: Unable to create audio channel Going to call ProgramMain... ---- amac_* are new functions I added to SDL_main... event type 0 is a "Null event", nothing happened when I called GetNextEvent... event type 23 is a high level event, and triggers calling the AppleEvent handler, which eventually figures out it is a single dropped document. fullPathBuf should be the full pathname for the dropped icon...as you can see, it is empty since I don't have the classic MacOS code to get it. The OpenWD/SetVol/CloseWD is code that would set the application's "current directory" to where the icon was dropped from. This is needed if the icon was in a different folder than the app. As it goes, since the path is empty, it is useless... The "1: '''" should be a list of all the icons dropped on the app...again...sadly empty! vRefNum and parID MIGHT be valid info for the dropped icon, but they aren't strings so not human readable... The rest are debug printfs I added to my MvM to show where starts, and then processes the command line. I'm running on SS which is why the audio error is there... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: December 29, 2024, 22:03 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #31 on: December 30, 2024, 18:45
|
Well...I have it working...most of the time? It seems to work fine almost every time I test it, but sometimes something goes wrong and there's a scrambled command line string. I had to hack quite a bit to glom the filename onto what SDL has by default, and am probably overflowing a string that isn't quite large enough, or some such. So in most runs it is good, but depending on what other apps you've opened, etc? Anyway, I'll see if I can figure out where the mess up is... BTW, turns out FSSpecs absolutely contain the filename, so that ended up being easy. The problem is it isn't the full pathname, so if you drop an icon from another folder onto MvM it doesn't work. Oh well. UPDATE: I had a malloc where I should've had a calloc, so sometimes a string wasn't null terminated. I think that fixed it. Here's a run where it worked... ---- Received AppleEvent: OpenDoc. 1 items passed in appleEvent. fullPathBuf is 'dmydisk.dsk' 1 : 'dmydisk.dsk ' nargs is 1 commandLine is 'minivmac ' Adding amac_filePath to commandLine... nargs now 2 commandLine now 'minivmac dmydisk.dsk ' 0 : 'minivmac' 1 : 'dmydisk.dsk' Going to call SDL_main... Going to call InitOSGLU... Going to call ScanCommandLine... Got a disk name dmydisk.dsk to insert... Couldn't open audio: Unable to create audio channel Going to call ProgramMain...
Last Edit: December 30, 2024, 19:02 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #32 on: January 03, 2025, 19:07
|
I've uploaded my 3.5.8 SDL PPC and M68k build folders here: http://macintoshgarden.org/apps/mini-vmac-source-code They include the source with patches I needed to make, and built binaries for both platforms. Rebuilding may require up to date SDL 1.2.15, possibly (but probably not) the "unstable" version. (Binaries tested as working and usable speed-wise in SS and Basilisk). The PPC version is mostly what is created by the source generator, but with a few fixes, for CW6 and non-CW related, and, of course, keysym->sym to make keypresses work. The M68k version is the standard black and white version created by the source generator, with OSGLUMAC.c replaced by the PPC SDL OSGLUSDL.c with patches for m68k specifics, and the cpu emulator with '040-specific fpu instructions removed as CW6 was unable to compile them (due to compiler bug handling the switch statement). Sound may or may not work in the binaries, as I was working on that in SDL at the time. If you build fresh versions with a known good SDL, sound will work.
Last Edit: January 03, 2025, 19:09 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #33 on: January 03, 2025, 20:01
|
I will try these tomorrow, but above all I'm looking forward to checking and comparing the sources.  This is great! Thanks for sharing all this!!Yes, I can personally confirm SDL Color Mac II PPC works completely normally, with sound and everything, when using regular SDL. I think I tested only with 1.2.13, but I will try 1.2.15, and your improved (AKA "unstable") 1.2.15 with it, as well. I'm hoping to "migrate" the code fixes to the "base" Mini vMac source code, so that compiler options can be used on top of it like normal. I'm assuming the newly-added PPC and 68k source downloads are only with the pre-configured source, which is perfect for compiling and running Color Mac II without "normal users" getting scared away, but adding the fixes back to the "base" 3.5.8 source would be really helpful. I will try sorting things out for us this weekend. I hope I can sneak in such activities here and there with the tiny bits of free time I will have!
Last Edit: January 03, 2025, 20:03 by Jatoba
|
MigMac
|
2 MB Posts: 2 System 7 Newcomer!
Reply #34 on: January 06, 2025, 20:44
|
Mini vMac looks gorgeous. The main issue I have is mouse availability, once the app is launched it's captured and the only way you have to retrieve the mouse and its cursor is to shut down the emulator. On a Pismo G3, MacOS 9.2.1
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #35 on: January 06, 2025, 21:24
|
Well hi there, Micmac! welcome to the System7Today forums!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #36 on: January 06, 2025, 21:31
|
@MigMac, I'm assuming the mouse capture you're seeing is with the new SDL version, correct? If so, that is how the original code was written, but I can definitely try turning disabling it, and seeing how things work. If it doesn't cause mouse problems (like getting out of sync) then it's definitely a feature to do. We'll have to see how it acts without it.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #37 on: January 14, 2025, 15:50
|
@MigMac and I talked more about this on HotLine. It looks like the SDL version of MvM has code that "constrains" or "captures" your mouse, and doesn't allow you to move it out of the window. So, even though you COULD switch away from it to another running program, it won't let you. I believe I can see the part in OSGLUSDL.c where it checks the mouse coords, and if they go outside the window, it will "warp" the mouse back into it. At some point we can try disabling this, probably just comment it out, and see if that works. The worst that can happen is MvM might get confused and the mouse might get out of sync, but we'll see. ---- @Jatoba, was thinking again about maybe trying Color QuickDraw, instead of SDL. If you're interested, we can take a stab at it.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #38 on: January 14, 2025, 20:11
|
@lauland Definitely! Would love to learn anything I can about a QuickDraw -> Color QuickDraw conversion, and if there's anything that you think could be delegated to me in a manner I don't get in your way, I'd be more than glad to help! (Although I might be a bit slow, as much of it is not quite my domain of expertise, plus hectic work week and life... But anything that needs to be done, I can get it done, and hopefully become better at it each time, and do it faster each time.) Mini vMac is great, and it'd be a shame if no one ever worked on a Color QuickDraw version. So we can be the ones to try.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #39 on: January 14, 2025, 20:55
|
I think the $10,000 question is: Why didn't anyone do it? Why, exactly was there no color Mac II MvM for Classic MacOS? I have to wonder...was there a good reason...one we'll run into...or was it just lack of demand/effort/time? It just seems strange to me, because it sounds like it should be easy...but maybe it isn't? So, the first steps are changing the NewWindow call to NewCWindow...to tell the MacOS we are doing color. The second will be changing from a BitMap to a PixMap for the screen buffer. I already tried these, so you can either look at what I did...I don't remember if I actually shared my code...or do it again. The thing to always remember with PixMaps is "rowBytes" ie how many bytes per row, is handled specially, with the high two bits set...this is a hack apple did to distinguish between 1 bit per pixel only bitmaps and pixmaps that can be any depth. Imaging_With_QuickDraw/Color_QuickDraw rowBytes_QuickDraw_MacOS_8 You don't have to understand WHY you have to do this, just always remember you have to with color quickdraw. So, it's a 16 bit number, which goes up to 65535. Drop one bit, it goes up to 32767. Drop another, and you're left with a max value of 16383. So you can't have a pixmap with more than 16383 bytes per row. Apple assumed you'd never need more. In 256 colors, it is one byte per pxiel...but 24 bit (aka "truecolor" or "millions of colors") can either be 3 bytes per pixel, or 4 which has an extra byte either wasted, or used for "alpha" (basically brightness/contrast or mixing/transparency). You'll see 4 bytes per pixel A LOT, because it works out to an even 32 bits...which 32 bit cpus can deal with easily and quickly. "Thousands of colors" is 15 or 16 bits per pixel. Either 5 bits each per r g and b (and 1 bit wasted)...or sometimes one color will be 6 bits, the others 5. Once you have NewCWindow and a PixMap, the application is color, but still only displaying two of them, black and white...the next step will be telling MvM to use more than 1 bit per pixel...we'll cover that later...
Last Edit: January 14, 2025, 21:20 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #40 on: January 25, 2025, 05:57
|
@Jatoba (and everyone else, your opinion too!), I've been thinking we might as well put binaries up on MG on one of the "official" MvM pages, other than the source one where they're lurking semi-hidden with no explanation. Or we could create a new "MvM Color Mac II MacOS 9" page. They're stable as far as I can tell, and it would get them into the hands of people who'd test them to actually be sure. And/or find bugs that we can fix. I hate sitting on something someone out there might actually like and want to use. @MigMac pointed out the "mouse is captured" in the window, but that is just how OSGLUSDL.c is. "Fixing" this would go beyond just a port. Otherwise it seems to me the PPC version works very well. Obviously the m68k version is just a curiosity, other than running in Basilisk on fast hosts...
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #41 on: January 25, 2025, 10:56
|
@lauland I agree, I hate it when that happens, too. I think a new MvM page (Mini vMac II Color Builds for Mac OS) gives it the proper spotlight it deserves, Mac OS Mini vMac never had Color, so this is a huge, BIG deal! Plus, if anyone requests for more builds (different resolution, or this, or that), it can be added all in the same place. I will try to make some time today for it. It's been a crazy busy week on my end, with no time to blink. Still want to write something @Knez asked me to 2 weeks ago, and I still want to get the MPW side of things going for the SDL add-ons, plus make a page for them. Let's see how many of these get done! I'm looking forward to working on Color QuickDraw Mini vMac anytime, though! So whenever/if you get in the mood, I'll gladly join right away!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #42 on: January 25, 2025, 16:56
|
Just let me know anything you'd like me to look into or do specifically, knowing you've been under the weather...probably literally, physically, AND timewise. Even let me know if there's anything unrelated to MvM and SDL I could help you with. You go on and create that Color MvM page, I totally agree, it's a big deal, from a technical standpoint. I haven't done MPW builds of SDL MvM, so that's something we should definitely do, to make sure it still works. If it doesn't, fixing it should be easy. I'll start back on the Color QuickDraw version and let you know what I think will be involved. FYU My gut tells me an m68k version, even using that will be slow, and not run well on real hardware. SDL is relatively thin as far as layers go, so the speed may be dependent on the CPU emu in MvM, and not drawing. I'll talk more about SDL itself in that thread...I've been busy with the add-ons, and have sdl_gfx ready to go up on the page.
|
Bolkonskij
|
Administrator 1024 MB  Posts: 2023
Reply #43 on: January 26, 2025, 06:57
|
I also think it deserves it's own page with a little explanation how it came about (or a link to here; for "documentation of the process"). This should get folks exited - I know I am :-) It's amazing to think this was always very achievable but never done for whatever purpose. Great work!
|
Knezzen
|
Administrator 512 MB Posts: 608 Village idiot
Reply #44 on: January 27, 2025, 08:43
|
I totally agree with you, Bolkonskij. But I know that documentation takes a lot of the fun away, though 
|
|
Pages: 1 2 [3] 4
|
| |||||||||||||||
|
© 2021 System7Today.com. |
