|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Attempt to add color to MvM running on MacOS 7/8/9 PPC (Read 168224 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #15 on: December 27, 2024, 18:52
FYI, changing "r->sym" to "r->unicode" on line 1127(?) in DoKeyCode() in OSGLUSDL.c seems to get all keys working. No idea if that was a typo, bug, or some MacOS 9 SDL quirk. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: December 27, 2024, 19:22 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #16 on: December 27, 2024, 21:24
|
I think I got the whole SDL vMac project setup exactly like your screenshot (but using CWPro8 libs instead of Pro7, I could tell from the file sizes being different in the screenshot than those I got), using the built-in Sherlock 2 was great help in finding all those. Also found the SDL.rsrc file in a "devel" folder/download for SDL, got my own previously-compiled SDL 1.2.15 lib to reference, yadda yadda... All looking set. But then I got to this part: Quote from: lauland Renamed "include" inside SDL to "SDL" so include "SDL/SDL.h" works. I feel stupid getting stuck at this, but renaming the SDL "include" folder which contains SDL.h to "SDL", then putting it in the same folder where the likes of "stdio.h" are located in CWPro8 did not do the trick in locating SDL.h during Make/Build. I also tried putting SDL.h and all the other files that were in the SDL folder directly in the folder where "stdio.h" and the others were in, but same issue. I guess I'm simply putting these in the wrong place? I also tried putting a copy of that folder ("SDL" containing "SDL.h" and gang) on the same folder we keep the Mini vMac newly-generated MCP project, just to be sure, but of course that didn't work, it needs to be wherever CWPro8 looks for these C headers/libs... Where exactly should I put it? EDIT: This is the path I thought the renamed SDL folder (with SDL.h) was supposed to go into: pathToCodeWarrior:Metrowerks CodeWarrior 8.0:Metrowerks CodeWarrior:MSL:MSL_C:MSL_Common:Include:
Last Edit: December 27, 2024, 21:41 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #17 on: December 28, 2024, 06:42
|
Apologies, I glossed over the "include" folder thing, should've explained more...this is a bit drawn out, but covers ALL the bases... ---- Most SDL code you'll encounter is coming from the Windows or Linux world (and modern MacOS X too). They ALWAYS have their SDL include files in a folder named "SDL", for example, something like "/usr/include/SDL/SDL.h" (although in reality, these days, it is hardly ever EXACTLY that). Then, in any program code that uses SDL, you'll see this line: #include <SDL/SDL.h> In the case of MvM it shows up at the top of CNFGRAPI.h But, SDL-1.2.13-devel, which I'm using has the SDL.h (etc) file in folder called "include". So, any code that has "#include <SDL/SDL.h>" then NEVER works, as is. (Some older Mac compilers purposely ignore any paths in includes, but CW doesn't AFAIK). You either have to modify your SDL distro, or move the SDL files somewhere in your CW (which you tired), or modify the original include statement. If you don't move the files (to the right places, which is tricky as you found) you MUST add the SDL folder to your project access paths. (Which is needed ANYWAY for the resource and lib files). I usually don't want to modify the original code at all, keep it the same on all platforms, and keep my CW clean, so I instead modify the SDL folder to match the Windows/Linux/MacOSX standard more. The path of least resistance was to just change the name from "include" to "SDL", but otherwise leave SDL-1.2.13-devel untouched. I then add that folder (SDL-1.2.13-devel, not SDL) as an access path. (This gets the includes, the resource file, and the lib all at once). I've added a screenshot to the MG page that shows both my SDL devel folder, and the access path settings for the project: https://macintoshgarden.org/sites/macintoshgarden.org/files/screenshots/Screen_Shot_2024-12-27_at_11.23.58_PM.png It probably makes more sense to put the SDL folder under "System" and not "User", but either works if you have the "Always Search..." box checked. BTW, not entirely sure why what you tried with "...:MSL Common:Include:SDL" didn't work. Off top of my head it looks like it should have.
Last Edit: December 28, 2024, 07:38 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #18 on: December 28, 2024, 08:40
|
Quote from: lauland BTW, not entirely sure why what you tried with "...:MSL Common:Include:SDL" didn't work. Off top of my head it looks like it should have. Upon checking the checkbox from your screenshot, "Interpret DOS and Unix Paths", ALL suddenly worked! Except for 3 errors that still popup, which are complaining about not finding "extras.h". If I copy the whole devel folder like you instructed, and also check "Always Search User Paths", I believe everything will work, so I'll do that next. Thanks for the extra steps!
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #19 on: December 28, 2024, 08:56
|
Ok, doing that didn't fix the extras.h issue, it seems that it is supposed to be a CodeWarrior header, so no SDL issues at this point anymore. The exact error message is that the file could not be opened (rather than not found), and happens 3 times in the code during compile, for some reason. No other errors. I'll poke around to try to figure out what's up with that.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #20 on: December 28, 2024, 09:34
|
It compiles! And indeed only launches if increasing the default memory allocation in Get Info > Memory. For SOME reason I don't know, CW was not able to find any of its headers if they were in "pathToCW:Metrowerks CodeWarrior 8.0:Metrowerks CodeWarrior:MSL:MSL_Extras:MSL_Common:Include:. To confirm that, I copied its contents to blablabla:MSL:MSL_C:MSL_Common:Include: (except for "stdio.posix.h" which already existed there). Then it just compiles. What might be a hint to why this happened, at one point, a 4th error HAD popped up, saying it could not find "MSL_Extras_PPC.Lib", even though I hadn't moved it at all when I first referenced it in the project. Weird. So I removed it and re-added it, and THAT error went away, but it still could not find "extras.h" after that. (And if you moved JUST "extras.h", then it would complain about the next header file from there that it could not find. So I copied the whole damn thing and voila.) For the record, I also had cleaned up the mess I originally made on my MSL C include folder: I kicked out all the SDL stuff I had put in there, and instead referenced everything exactly the same way that you described. I agree, it's much better to keep the CW folders "untouched" and immaculate. (Except that now I have the MSL Extras includes in my C includes, but hey, at least we can compile for the time being.  But maybe I can try to get CW to at least see/check the MSL Extras includes, too... No idea why it doesn't.)Oh, and I also kicked out my SDL 1.2.15 in favor of the official 1.2.13 since we are using the 1.2.13 devel folder. So... I guess our next steps are going to be on the source. You figured out the keyboard issue (awesome!), and so now the only thing left is for us to figure out what is causing / how to fix the drag'n'drop of disk images into the vMac window or vMac app icon, right? After that, then I'd like to try the original idea of QuickDraw -> Color QuickDraw conversion... maybe it can teach me each of these two to some extent... EDIT: Oh yes, I was able to confirm also on my end that applying your following fix...: Quote from: lauland FYI, changing "r->sym" to "r->unicode" on line 1127(?) in DoKeyCode() in OSGLUSDL.c seems to get all keys working. No idea if that was a typo, bug, or some MacOS 9 SDL quirk ... indeed fixes/enables all keyboard inputs, just like that. How you figured out to change "r->sym" to "r->unicode" to fix this is beyond me, I would have taken years at best. I mean, we can see this line has to do with keyboard mapping, but to know to replace, specifically, "sym", and that we could use "unicode" there instead... I really don't see myself as being able to figure THAT one out. Just amazing. Also, it seems the extra memory we put in Get Info needs to be only ever-so-slightly increased (well, technically, doubled, but considering how small the original setting is, it's a pretty small increase). To spare us the trouble of doing this after each compile (for anyone else reading along our rants), we can set it within the CW project preferences in Target > PPC Target. We move up "Preferred Heap Size (Kb)" from 6000 to 11667, and "Minimum Heap Size (Kb)" from 3000 to 11667. This is the absolute minimum from what I tested, down to the last KB, and the resulting Mini vMac will be allocated by default with exactly 11998 KB (close to 12 MB) of RAM. What's so cool about Mini vMac II with Color in Mac OS 9 is that now we can play "near-natively" those lower-than-256-colors Color games which, normally, are either impossible on Mac OS 9 or, if it even exists, require some obscure 2MB VRAM PCI GPU that, just maybe, allows one to select a lower color depth than that. (Note: Such a GPU probably does not exist, and even if it did, the likes of the Mac mini G4 cannot use it as is.) With this, all those incompatible 24-bit-dirty and low-color-depth software now can be accessed VERY easily under Mac OS 9! System 1 ~ System 7 banger of a VM! And that too with the "latest" Mini vMac codebase, 3.5.8, as opposed to the earlier 3.4.1. How far this has come! And more is to come? EDIT 2: I also grew a bit of a brain and added MSL_Extras:MSL_Common:Include: to my project settings' Target > Access Paths > User Paths, and deleted its files that I had previously copied to the equivalent path in MSL C. D'oh. So much better, now my CW install files and folders are "clean" again.
Last Edit: December 28, 2024, 10:48 by Jatoba
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #21 on: December 28, 2024, 17:46
|
Quick update, I tried to figure out why drag'n'drop isn't working, and I still don't know. But: - I checked all the 85 different compiler options for version 3.5.8 to see if I could "force" drag'n'drop, or if there was some drag'n'drop setting, but nope. I'm assuming most likely the author made assumptions that SDL 1.2.x = Any OS BUT Mac OS, and so that could have "kicked out" relevant drag'n'drop code? So it might be worth peeking at the "non-prepared", "raw" source to see what should have been there, but isn't. We can also "diff" a normal Mac II for Mac OS source (-t mppc -m II -e mw8) with an SDL one (-t mppc -m II -e mw8 -api sdl) and see if we spot something! One can hope, so I will be doing that next. - Peeking at OSGLUSDL.c, which clearly is the "main file" (and has the main method itself at the bottom), I could not spot anything I could identify to have to do with drag'n'drop, but I could be wrong. I did notice that the generated source code is VERY nicely-commented, though, so you get a general idea of what each part is doing, ESPECIALLY if you know the compiler options. Will keep on looking/poking.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #22 on: December 28, 2024, 18:21
|
Well, I believe the culprit has been found: Seemingly all drag'n'drop code is available in OSGLUMAC.c, a file which doesn't exist if we use SDL. With SDL, instead, we have OSGLUSDL.c, so the SDL implementation, to "keep it simple", doesn't seem to make OS assumptions, since basically any OS can be the one using SDL. Of course, OSGLUSDL.c very well COULD have included OS-specific code and detected things accordingly with ifdefs and whatnot, but the effort simply wasn't put there towards that. I think we can consider ourselves lucky that the SDL implementation worked as well as it did just like that! Looking into bringing the code over from OSGLUMAC.c to OSGLUSDL.c did not seem very trivial, and seemed rather an involved process, at least to me. But it looks doable. The question is: would it be faster to just do the Color QuickDraw conversion instead to "get drag'n'drop support", as well as 68k Mac support, both in one go? Anyway, we can pursue this, totally, but it's not gonna be a 1-line change this time, for sure. What do you think, @lauland? Which way would you rather go? Although something tells me if we go SDL + drag'n'drop, the next step would be trying to compile SDL 1.2.x for 68k.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #23 on: December 28, 2024, 21:37
|
Dang, I owe you even MORE apologies...you eventually figured both out, but, yes, I indeed increased the Minimum and Preferred memory settings in the CW project...and I needed to add the MSL extras when I did a build using CW8 on MacOS 9.1+...forgot about it, and didn't need it, when I switched to CW7 on MacOS 9.0. ---- I used "debug printfs" to figure out the r->unicode thing. I first put them at the top and bottom of the switch statement in SDLKey2MacKeyCode(), since I suspected a problem there. Was surprised to see that both v and i were always zero, but the function WAS being called. So I knew the problem was before that. So I added this line right AFTER the call in DoKeyCode(): printf("%d %d %d %d -> %d\n",r->scancode,r->sym,r->mod,r->unicode,v); This showed me all four members of the SDL_keysymm r. After running and typing a...b...c...control...backspace...and quiting, I could see in stdout.txt that r->sym was always zero, but there was a likely code in r->unicode. I did "Go to constant definition..." for SDLK_A, SDLK_LCTRL, etc, that I could see in SDL2Key2MacKeyCode() and saw their values matched exactly what I saw in r->unicode...voila! Still no idea if that it was a typo (more likely) or a bug in MacOS 9 SDL (less likely, or keypresses would be broken everywhere?). BTW I first tried setting breakpoints where the printf's ended up going, but my CW7 in SS just skipped over them, could not get a breakpoint to actually break to save my life. No idea what's up with that, irritating, and doesn't bode well for when I might need them for further hacking. (Pretty sure I'm not doing something silly...I've done lots of breakpoints for other projects, but none for the combo of CW7 on MacOS 9.0 on SS, so suspect that is a clue...) ---- One thing I did at one point was build an SDL-1.2.15-devel-jatoba folder...used your lib, but the headers and resources from 1.2.13. I didn't end up building with it, because I wanted to eliminate as many variables as possible. But I trust your lib, and think we should end up creating an "official" SDL-1.2.15-devel-jatoba and upload it to MG. (Need to include updated 1.2.15 headers, if they exist, of course). ---- Drag and drop is handled via an AppleEvent. So, the first place to look is AppleEvent support in MacOS 9 SDL. It might need to be added there...because it is unlikely SDL passes AppleEvents on in any form to the running app. If it is added, the form it takes will be tricky. The initial "drop the disk image on the app icon" event (called an "OpenDoc" event...hehe) would be handled at app startup, and translated into an argc/argv passed to the app as a pseudo command line parameter, which MvM would understand and be none the wiser it hadn't just been typed. I've done this for other projects ported to Mac, so not too difficult, but will be hacking SDL. If something like that isn't already there, and broken somehow, it really needs to be! Handling dropping disk images on the running app's window is different, and harder just communicating it...we can look how (if?) this is done in Windows and Linux. It might be SDL has support for some sort of "application event" already and, again, it is missing or broken in MacOS 9 SDL. (Carbon has more sophisticated event handling, not QUITE up to AppleEvent level, but a lot more complex than MacOS 9, so the MacOS X code might not be helpful). ...then...in MvM there needs to be code that receives and handles the "event", whatever form it ends up taking. ---- Next steps: Hmm...the AppleEvent stuff above looks pretty obvious, as it is irritating having to have the disk named "disk1.dsk"...and I already have very good ideas how to implement it in SDL (the pseudo command line stuff). The "drop image on running window" will be trickier for reasons explained above, so might punt that for later. So any of that will be SDL (not MvM) hacking, on I think an SDL-1.2.15-devel-jatoba will be a good idea. I think if we had it able to run with a disk with any name other than "disk1.dsk" we might as well release it to the world...and/or just release it now, as it is really useful already as is. Your call. ---- After that, or sidewise projetcs...sure, m68k SDL would be very nice, and probably not too far a mountain to climb. FYI it might require CFM-68k...half the differences between PowerPC and M68k code is the use of CFM and universal proc procedures, so porting it that way will likely save a lot of time. We can definitely at very least take a look at SDL2 MacOS 9 PowerPC, at the very least to try and figure out the scope and amount of work. And, of course, converting the original MvM (non-SDL) to Color QuickDraw...although I think that could end up taking more work than you might think. Two approaches: 1) Take the existing code and "color it up", 2) Take the Carbon MvM and de-carbonize it, and replace the CoreGraphics bits with (new?) Color QuickDraw bits. The reason #2 might be better is we know it supports colors, and things like different bit sized pixels, so might save time. #1 might be harder than expected if too much of the code expects 1 bit pixels, ie having OSGLUMAC.c "tell" MvM it understands different formats. Doing the diff's (in BBEdit) on the Carbon and original OSGLUMAC.c and copying parts over from one to the other, and then colorizing, SOUNDS relatively easy. And would be, if the code were more readable and organized more logically. But it's a mess and there are a LOT of misleading differences. The QuickDraw vs CoreGraphics support COULD'VE used similar function and variable names, but, nope. ie Doing this is a bit of a slog and close careful eyeballing. But I can take a fresh look. ---- Something else we really should do...especially since we are speaking right now on a forum dedicated to System 7...is see if we can build the SDL version we have to run on it! Trying an older version of CW is the first step, and I can definitely do that. The trick will be if SDL supports System 7...if it does, this would be just me messing with CW, and we're golden.
Last Edit: December 28, 2024, 22:45 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #24 on: December 29, 2024, 16:50
|
Quote from: lauland I think if we had it able to run with a disk with any name other than "disk1.dsk" we might as well release it to the world...and/or just release it now, as it is really useful already as is. Your call. I find it "releasable" as is for the reasons you stated, it's really awesome as is right now already, but I think there's also no rush, and we will probably want to "crawl down towards System 7 PPC" as the top-most priority, although I don't have a pre-OS-9 system to test with, but I sure do have every CW version set up to try to compile things with. I think the "disk1.dsk" string is handled in this bit of code below and seems like something very quick and easy to change to anything we would like (what should it be changed to, if so?): ============================ (In OSGLUSDL.c, around line 334 or so) LOCALFUNC blnr LoadInitialImages(void) { if (! AnyDiskInserted()) { int n = NumDrives > 9 ? 9 : NumDrives; int i; char s[] = "disk?.dsk"; for (i = 1; i <= n; ++i) { s[4] = '0' + i; if (! Sony_Insert2(s)) { /* stop on first error (including file not found) */ return trueblnr; } } } return trueblnr; } ============================ Incidentally, is there a way to search for text across multiple files at once? Both in CW and BBEdit, I seem to be able of searching in only 1 file at a time. (Was trying to find the definition for "AnyDiskInserted".) About a 1.2.15 devel folder, that's probably a very good idea. I'll look into it during this week whenever I can, I agree it'd be helpful to have that set up, and not leave it at just 1.2.13. (There's also nightly code for 1.2.16, which I will also try to look into, since there are hardly any commits for it anymore.) SDL 2, I think I saw once written in their official docs a statement saying that it can be ported to earlier versions of PPC Mac OS X (like 10.2 Jaguar) with "some effort", seemingly not too much. For OS 9, I'm not sure where to start. I think the first step would be gettting the latest SDL2 compiled and running on such older Mac OS X PPC. Then the path to OS 9 will also become clearer? Slowly but surely the way is getting paved.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #25 on: December 29, 2024, 18:34
|
disk1.dsk: You are, of course, correct about there being no hurry! Being able to drop the disk images on the icon is pretty critical for how I actually use MvM. I have several to switch for different purposes like System 6 vs System 7 etc. LoadInitialImages() is where the code that handles defaulting to "disk#.dsk" names is, but ScanCommandLine() (called by InitOSGLU(), which is first called by main() itself) handles every OTHER name with the lines: } else { (void) Sony_Insert1(pa, faslblnr); goto label_retry; } The else is from higher up, where it handles command line options that begin with "-" like "-rom". pa is my_argv[i++]. my_argv is set up by main(). So we go back to main(), right at the bottom of OSGLUSDL.c, where there is the standard argc/argv. The problem is that on classic MacOS there is no command line, unless the compiler sets it up for you, which most do NOT. They might set argv[0] to the program name, but that's it. The trick is, that with SDL programs, main() is not the REAL main(), which in our case is really in SDLmain.PPC.LIB. This isn't a Mac thing, all SDL programs on all platforms work that way, so SDL can do some initial setup, and sneakily handle some command line options for itself, before the program even gets to see them. The way to do this right, and add new support for passing "command line" options for ALL MacOS 9 SDL programs, not just MvM, at the same time, is to add support for handling the "OpenDoc" AppleEvent to SDL_main(), translating the filename it contains to an argv string. ---- Multiple file searching: In BBEdit/TextWrangler this moved around, depending on versions. On some it is "Mutli-File Search...", but on others it is a checkbox that opens up an expansion of "Find...". In both cases you need to specify which directories to search in. You'll have to see, depending on your specific version. CodeWarrior was more consistent. You want "Find in Files...", and it is very versatile. In most cases you'll want to use the "In Projects" tab, because you want to limit to code you're actually working on. In this case, we can look for how SDL handles main() by doing a search for "main(" (leave the rest out, because when people refer to it sometimes includes argc,argv, sometimes not). I checked all the boxes, because I want it to show me results in MvM, but also in the SDL headers (it'll show EVERYTHING, including MSL, but that's fine). Go ahead and do this in your CodeWarrior, and you'll see not just main(), but other functions with similar names (like ProgramMain). But the important result is SDL_main.h, which is where SDL sneakily puts it's main() (so it is called first) in front of the programs's main(). Again, this is an SDL thing, and not a Mac thing. So, code to properly handle turning the dropped icon AppleEvent into an argv that EVENTUALLY gets to MvM's ScanCommandLine() belongs in SDL_main(), and will be hacking SDL, and not MvM. I'll look into this, as I said, I already think I know how to do it and may be able to repurpose some code I already have. ---- Definitely do a new "Jatoba 1.2.15 devel"! I'll hack on whatever SDL source version you have at MG, or just 1.2.13...it won't matter as SDL_main() won't have changed much or any between versions. I'll take a look at SDL2PPC9 and SDL1m68k and let you know if I have anything useful to say (other than "OMG they're a mess, this would probably be too much work"). If you are so inclined, since you already have multiple CW versions good to go, you might look into building MvM SDL with CW6 to support pre MacOS9. I know I have CW6 set up someplace, but not handy right off the top of my head. It will probably involve importing the .mcp.xml file, and then reproducing what I did for CW7 (and you for CW8), adding MSL and SDL parts, setting up the access path and Minimum/Preferred memory, etc. If you run into import problems, we can just create the project from scratch, since it isn't complex, it wouldn't be too much pain. I've got pre-MacOS 9 PPC hardware for testing, but also am pretty sure QEMU can emulate at least beige G3's, and likely even earlier, (ie "old world" machines). This is what I use to emulate "New World" (ie MacOS Rom file) ones: qemu-system-ppc -M mac99 -m 512 -hda macos9.img -hdb extra.img -netdev user,id=mynet -device sungem,netdev=mynet -device usb-mouse -device usb-kbd The change will be to use something other than "mac99" (and different non-usb mouse and kbd), which we'd have to look up. (Obviously you'd change hda and hdb to be your disk images). I believe I installed MacOS 9 mounting it as hdb or hdc via a toast image download from MG. So installing older OS versions would probably work the same. I can look into this at some point if you don't.
Last Edit: December 29, 2024, 18:43 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #26 on: December 29, 2024, 18:58
|
I'm looking at SDL 1.2.15 source, and can see in the MacOS version of SDL_main() there is support to put up a dialog box where you can type command line options if the command key is held down when you double click the application icon. This works in MvM so you can type a disk image name. There isn't any AppleEvent code there, so I'm looking into adding some...
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #27 on: December 29, 2024, 19:12
|
Got it, @lauland! I just got the CW Pro 7 build up and running, and will attempt CW Pro 6 next. Funny how CW Pro 7 is a bit easier to set up than Pro 8... And also funny how the resulting binary's RAM requirements are a bit higher with Pro 7 (from 11998 KB to 12016 KB). I will leave the drag'n'drop on app icon to you, then, sorry to leave all the "hard parts" like that to you... But I'm glad I can keep up, thanks to your explanations. I finally understood what you meant by "outside MvmM" and that this is going to be a hack over at the SDL sources to take that sneaky SDL main() method and "args-fy" dropped-in files via the "OpenDoc" AppleEvent. Very educational, even more so to know that the main() hijacking from SDL happens in all platforms, and to know what AppleEvent to watch for and implement code over for app icon drag'n'drop in the future. Also thanks for the CW/BBEdit multi-search guidance! This will certainly be VERY productive to know. I was already amazed at how powerful BBEdit's "diff" option was, it was REALLY helpful and well-put together, so having multi-search to the mix will further improve my output. Finally, heh, how neat that SDL Cmd + double-click option is! Nice find!
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #28 on: December 29, 2024, 20:03
|
CW Pro 6 compiles! Resulting binary works fine! Will Pro 6 bring us the System 7 PPC compatibility we need? Can someone test? I uploaded it on Hotline in the "Uploads" folder as "Color MacII test on SSW 7.sit". To anyone reading, remember to use the file name "disk1.dsk" and put it on the same folder as vMac, else it won't boot! MacII.ROM already included for convenience. @lauland Here are my notes from the "extra steps" required for CWPro6 to build compared to others: - In Project Settings > Target > PPC Target, had to adjust File Name to "minivmac" and Creator to "MnvM". Somehow the CW Pro 6 import of the XML file loses that info. I also had to bump up the Preferred and Minimum Heap sizes from 11667 to 11668. The resulting binary is and requires 11994 KB RAM, which is a bit lighter than the ones from both CW Pro 7 and Pro 8; - Had to remove the reference to MSL Runtime PPC and re-add it, because the file name is slightly different on CW Pro 6. The name here is "MSL RuntimePPC.lib" instead. Other MSL libs to be added also follow this slightly different spelling; - No need to add the MSL Extras lib... Because it doesn't exist! Yet I see extras.h is there in Pro 6 (and earlier versions). Perhaps extras.h is joined with the other MSL... groups, or divisions, or whatever they are called, so it gets found after we check in Project Settings > Target > Access Paths > Always Search User Paths + Interpret DOS and Unix Paths. Wonder if SDL itself is running on any version of System 7 PPC, like 7.1.2. And I wonder if PPC binaries produced in CW Pro 6 are good enough for the likes of 7.1.2. System 7 as a whole is great, not just 7.5.x and 7.6.x, some things are doable only in 7.1.x and earlier. If by any chance CW Pro 6 is not good enough, I can try Pro 5 next. Any testers?
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #29 on: December 29, 2024, 20:24
|
I think we'll have to write up a "Guide to ACTUALLY compiling MvM with CodeWarrior" doc and add it to the MG page. There's so many extra steps you have to do to get the .mcp to actually build, unfortunately. For us who aren't scared of CodeWarrior it is still a pain, for others it could stop them cold. I'll try a CW6 build on MacOS 7/8.0 at some point. ---- I WAS able to repurpose the AppleEvent code I'd written in the past. It is super-fugly, and a lot longer than I remembered, but it pedantically checks for every possible error condition (Your OS doesn't support AppleEvents? There was a problem installing the handlers? etc etc etc) and has extensive debug output. Had to translate it from C++ to C and remove/fix a lot of screwy lauland-isms, but I was able to build a new SDL_main.PPC.LIB that included it into an MvM and it runs...but there's a still more to do to make it function. (It turns out it also used a complex argv string handling utility function I wrote, which is in C++ that I still need to translate). AppleEvents are...a bit complex, you might argue over-engineered...first you have to install the handlers...I've got that done...but then you need to get to where Mac events are handled, and check for a "high-level event" which is really an AppleEvent. This goes where keypresses and mouse clicks are checked, so SDL's "event loop". So, what I have now inits AppleEvents, has handlers for the four "core suite" events, and installs them. But the handlers are never called without adding "high level" event handling to the event loop. Technically, I also need to add a "check event" call to SDL_main() that would grab the initial "OpenDoc" AppleEvent, before MvM even starts, and translate that into an argv. So, I need to rebuild all of SDL, and not just SDL_main...which means I need to get OpenGL and other depenedencies, etc etc...sigh. ---- Unfortunately, AppleEvents are the way drag and drop is handled on MacOS. But...it occurs to me that the "drop the icon on the application" CAN be handled using a much simpler pre-AppleEvent way...which is how it was done before AppleEvents existed, so System 6 or if you don't have AppleEvents installed on really old System 7. I wrote code for THAT too in the past, and will look at getting it in there too. It doesn't involve adding code to the event loop, so is a LOT easier to hook into a program. The "drop a disk icon onto the running MvM window" would be pure-AppleEvents. Doing the code that intercepts it and parses it into a string is one thing...but then still need to look into getting that info to MvM...I know SheepShaver and Basilisk support this, but actually don't know if MvM does, so it may be that whole thing can be skipped. I won't even try and get into it, but it is very good I already wrote code to process AERecords, etc etc etc. Just take a gander at this: https://en.wikipedia.org/wiki/Apple_event
Last Edit: December 29, 2024, 20:33 by lauland
|
|
Pages: 1 [2] 3 4
|
| |||||||||||||||
|
© 2021 System7Today.com. |
