|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Attempts to build m68k MacMESS (Read 128126 times) | ||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
on: September 25, 2025, 04:50
Ok, starting new thread since it looks like this MIGHT just be possible...but not simple or quick. Because there's so much PPC assembly in use, this can't be just a simple port, but will take some work. Not sure how long it will take, maybe a bit, and I might work on and off, so will track what I do here. ---- The first steps in doing an m68k port of an existing PPC program, that you have the source to, are: 1. Make sure you can build the PPC version. This sometimes isn't trivial, since you might need exactly the same compiler/setup/etc that the original author used. Or...which turned out to be the case here, you need to find all the parts and put them in the right places. 2. Change the project types to m68k, preserving the 4 character creator code, and memory sizes. (At this point the order you do the remaining is arbitrary) 3. Decide what to do about int sizes and segment model. Usually you need to go 4 byte ints, 8 byte doubles, and at least "smart" segmenting, but a lot of times you need to flip all the "far" switches, and use the large model. If you go "far" (which means 32 bit offsets for everything, instead of 16 bit ones, which are faster and save space) you need to make sure you use the right ANSI etc libs. You also need to decide if you are going to use 68020+ instructions. 4. Find and work around anything that uses the Mixed Mode or Code Fragment Managers. 5. Find and work around anything that might be MacOS 8.5 or higher. If you want to support System 7.5, then find the MacOS 8 stuff too (usually Appearance Manager). 6. Deal with some esoteric PPC only MacOS calls. This can be video driver gamma calls, programatically hiding the control strip (yes, this comes up more than you'd think), high resolution timers and a bunch of other stuff that the m68k can't do. 7. If there are 3rd party libs used, like GUSI, or WASTE, or SDL, etc, you need to find and use the m68k versions. 8. If there's powerpc assembly, find replacements or replace with SOMETHING, I usually write C equivs because it is quick. I might be forgetting stuff, but that's mostly it. If you're lucky, at this point, you're done. ---- So I've done all the above for MacMESS, but are running into a few problems, and am at step 8: The blitter is just empty right now and I'll need to find or write a replacement. It is relatively small and I can probably write something in C that'd be pretty fast. (I've done this before for other projects). The timers are also empty, and I need to have them do calls to the MacOS Time Manager. Again, I've done this before, so shouldn't be hard. There's some odd vector multiplication code that uses a powerpc instruction, but NOT altevec. I need to figure out what exactly it does, and replace with a C version. (The m68k won't have a single instruction that can do it, and C should be fast enough). I found how to switch to the C versions of the CPU cores. There seems to be a bug in m68k CW5/6 with VERY large switch statements. I ran into this with MiniVMac's cpu main opcode switch table. I couldn't figure out what was going on so I disabled some esoteric '040 only FPU instructions to get the table just under the size. This might be due to the m68k instructions CW uses to do switches, it should use 32 bit if you do "far", but it might be trying to use an instruction with a 16 bit offset, so when the table gets larger than 32k/64k it fails. You'd think it'd be smart enough, and the error message is strange, so I think it's a bug. Anyway, the m6809 C cpu core's switch statement is doing the same thing. Will need to look closely to figure out how to get it smaller. The m68000 cpu core requires running a separate CW project to generate C code from a text opcode table. This is a very clever way to do it, and is done when you build MAME, which MESS is a patch over. Since I'm not building MacMame, this step isn't done. I'm not building MacMame because the supplied project files in the source archive we found are broken without some work. I'm going to look into fixing them. A bonus will be we can probably get an m68k MacMame 037b10 out of it. Don't know if that already exists or not. If I run into too many problems with those two cores, I can just disable them, Mame and Mess are very configurable. ---- The m6809 was primarily used by the Tandy Color Computer, the Vectrex, and some Williams arcade machines like Defender, Sinistar, and others. We all know where the m68000 was used! Emulating an m68k on an m68k will not run well at all, if my experience from porting MiniVMac is any indication. I might just cut my losses and disable it for m68k Mess. ---- So that's where I am currently. Once I get past the cpu core problems, there may be others (because compilation stops without fixing those problems), but so far it is looking like a lot of work, but doable. Between Mess and Mame, there's emulation for just about every cpu, video, sound, and io chips you can think of, and the code is fascinating to look at. Not to mention how hundreds of different arcade machines and home computers work! We might find a blitter from some other m68k Mame version and just copy that part over. Otherwise, I think we don't need any other source code than what we have. |
||||||||||||||||||||||||||||||||||||||||||
Last Edit: September 25, 2025, 05:00 by lauland
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #1 on: September 25, 2025, 21:16
|
Quote from: Lauland We might find a blitter from some other m68k Mame version and just copy that part over.While I keep finding some interesting tidbits regarding MacMAME, like this discussion that touched upon blitter for PowerPC Macs in a (modern url) Bannister.org forum thread from '06, I then realized (modern url) this forum is still active and has a non-Windows section  so that may yield a little more help from anyone there that may be interested in pitching a bit on the Mac side of things! And who knows? They might even have access to some potentially useful stuff that's no longer available online, too!  Quote from: Lauland A bonus will be we can probably get an m68k MacMame 037b10 out of it. Don't know if that already exists or not.All I found was the old MacMAME 0.28 which I've used many times before, and I dug away just in case someone somewhere had done anything before running toward that the old PowerPC bandwagon, so this would be a huge 68k MacMAME update! As an aside, iNES plays fine with a ROM of my favorite NES cartridge, which I still have actually. 1.2 needs 8.1's default system extensions to be enabled on SheepShaver to even open and its save states don't work on either emulator. I couldn't select any menu items when using Basilisk II, so I disabled it and just use v1.0.2 which doesn't need those system extensions enabled and its save states work fine 
Last Edit: September 25, 2025, 23:00 by cballero
|
Cashed
|
128 MB Posts: 192 System 7 Newcomer!
Reply #2 on: September 26, 2025, 02:32
|
cool progress. Forgot to mention the other day that I noticed there also was a SDL version. Read up on the two SDL threads yesterday -well skimmed them. From what I deduced it's slow on 68K, and best suited for PPC -just wanted to empty head and chime that in.
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #3 on: September 26, 2025, 03:47
|
Interesting, Cashed! I know Lauland spearheaded some really super-cool Classic Mac OS SDL projects: version 1.2 and version 2.0 that he detailed here on the forums!  It's really cool to know there was an SDL MacMAME version! So it's a 68k version as well?
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #4 on: September 26, 2025, 16:08
|
SDL is an all purpose lib that handles OS/graphics/sound/input kinds of things, so if we didn't have the Mac front end, an SDL version of Mame/Mess would be something to look at. I doubt anyone has ever built a classic Mac SDL Mame/Mess, but it might be used for the MacOS X versions. I do have SDL1/2 fully functional, but missing some features, on m68k. We might find generic "blit" and "timer" funcs in SDL Mame/Mess, but they'd be calling SDL, and translating to MacOS APIs wouldn't be much easier than just writing new ones. And...even the SDL version may use PPC assembly for them for speed! So that might not end up saving any time at all. And I'm betting the bottleneck is in the CPU cores and drawing, neither of which SDL would help with. ---- One thing SDL MIGHT be REALLY useful for would be porting a much newer version of Mame/Mess to classic Mac, one that nobody wrote a Mac gui for. On a fast PPC this might run VERY well, but that'd be a different project than this one, one I'm totally not opposed to looking into at some point. (But would probably be extremely slow on m68k, mostly due to the CPU cores, which'd be the same as what I'm working on, SDL or not).
Last Edit: September 26, 2025, 16:10 by lauland
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #5 on: September 26, 2025, 18:29
|
Quote from: Lauland One thing SDL MIGHT be REALLY useful for would be porting a much newer version of Mame/Mess to classic Mac, one that nobody wrote a Mac gui for. On a fast PPC this might run VERY well...That sounds totally amazing! And if it would run as low as maybe 7.6.x and up, oh my goodness! Can you imagine?  I'm still super excited about these 68k exploits of updating MAME, wow, along anything else worth updating under the MESS hood, all of it's truly exciting and absolutely worth doing and celebrating..thank you, Lauland!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #6 on: September 27, 2025, 18:31
|
Like I said, an SDL Mame/Mess for classic Mac would be a totally separate project...well...almost 90% separate. A hypothetical m68k SDL Mame/Mess would need the exact same work I'm doing here just for plain old MacOS m68k Mess. A classic PPC SDL Mame/Mess would be first, and far easier (since we could just use any existing PPC assembly,etc etc). The key to it would be picking a particular version we wanted to port, and that wouldn't necessarily be simple. My guess is the older the better. The reason is if we pick something TOO NEW, it will use too many modern language and OS features, that are extremely difficult or impossible to do on classic Mac. Things like threads, or aggressive memory management, which are trivial on modern systems like Windows, Linux, or MacOS X, but can only be done half arsed on classic MacOS. If we eventually did get a really old version to build, we could try newer ones until we hit a wall of it being "too modern for classic". ---- Not necessarily saying it will be possible, but I can certainly take a look and ascertain how much work it would take. So, you guys can help by researching SDL Mame/Mess. It might not be a bad idea to find the oldest source you can for a start.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #7 on: September 29, 2025, 17:18
|
So I disabled the 6809 and 68000 cpu cores for the m68k build, but now have to make sure all the systems that depend on them are disabled too...which you'd THINK could be done automatically, but nope, so slogging through THAT. Now running into something very strange to me...MacMESS uses a whole bunch of what are usually termed "accessor" calls, which are when you call a function to set or get parts of system structures like Windows or GrafPorts, etc. As far as I knew, these were all added for Carbon, where, for "reasons", Apple needs to keep the guts of the system under tight control, to enable protected memory, multitasking, and more. The problem is MacMESS is using these even for the non-Carbon build. This means either Apple added them to MacOS in general (or in addition?) BEFORE Carbon (only for PPC?) or I'm confused. As far as I can tell, they are not available on m68k. There's TONS of them, so it's probably not feasible to fix them by hand...its goofy stuff like replacing: "GetWindowBounds(theWindow,&myBounds);" with "mybounds=theWindow->port.bounds;" So I need to look into if I'm understanding correctly, that these are valid for PPC MacOS, but were never added to m68k. If that's the case, I might write a bunch of tiny "compatibility shim functions" that just translate the calls into direct structure access. If I'm REALLY lucky, somebody else out there has already written such a thing and I can just grab and use it!
Last Edit: September 29, 2025, 17:20 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #8 on: October 04, 2025, 05:09
|
Ok, so my guess about those extra functions like GetWindowsBounds() was correct. Some of them are part of MacOS 8.5, and the rest are part of a weird extra lib called "CarbonAccessors.o"...which includes a bunch of functions that ARE part of Carbon, but you can use on non-Carbon. A few, but just a few, have "inline" macro versions, in the universal headers. Since those fall in to three categories, I'll have to work around them in three different ways. If they are 8.5 only calls, I'll have to work around them, maybe disabling the parts of the code that use them...or...and it may take a lot of work, write 7.5/8.0 code that does the same thing. I'm not sure if CarbonAccessors.o is ppc only. If not, then I'd need to treat what's there the same way as the 8.5 funcs. If so, then maybe I can just use it? Maybe? I'm not sure why it isn't already using the inline versions of the funcs that ARE available...we can use IsWindowVisible() as an example. If OPAQUE_TOOLBOX_STRUCTS and ACCESSOR_CALLS_ARE_FUNCTIONS are both false, then it should just use a macro. On m68k both these should ALWAYS be false. It could be the MESS source someone is explicitly setting one of them true. If I'm lucky, that might be the case. So, bit of a pain...
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #9 on: October 04, 2025, 15:07
|
I can only imagine the challenge of imagining what the programmers were figuring out in their minds when they were building this out, Lauland! I remember adding notes within my Pascal code in my intro classes; I'm curious - did the devs leave any such in theirs? I'd call it breadcrumbs just to know what the hexagon I was creating at any given juncture, but then that's how I solution a lot of things I do work on, like html coding, which I haven't done in a very long while either, even if I leave it out of my final code to 'optimize' it. It just sounds like 'yikes! no map, no trail, nothing but straight-up code.' which in itself leaves clue to those who know it well, but still 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #10 on: October 13, 2025, 17:16
|
An update: I found the Mac Mame/Mess people had turned on OPAQUE_TOOLBOX_STRUCTS and ACCESSOR_CALLS_ARE_FUNCTIONS on purpose in the main header file. They left a comment that they did this so they could make the code more "Carbon" like, even when not on Carbon. That's fine for powerpc where you can use the "CarbonAccessors.o" library which implements most of them for non-Carbon...the name of that is quite confusing...but useless for m68k. So I turned those off for m68k builds, and was then able to use many apple supplied macros to replace the functions already built into the Universal Headers. That got probably a third (or more?) of them. But there were a bunch that were either just added to PowerPC in general, or specifically to MacOS 8.5 or higher. ---- So I started writing my own version of something like CarbonAccessors.o but for m68k...it's all stubs for now, but will end up a ton of tiny things like this: Pattern *GetQDGlobalsBlack(QDGlobals *qd) { return qd->black; } I'm also going to implement the non-Carbon, but 8.5 and higher stuff...it's all very similar. Apple's idea being you should never access system structures directly, but call functions instead because on a real pre-emptive multitasking memory protected OS, it would be dangerous. That was supposed to be Copland, but ended up being Carbon, but the idea was exactly the same. This little lib will make porting powerpc 8.5+ stuff in general easier to back port to m68k 8.1, or even older. ---- But then once I got past that hill (or at least skipped past the hill with a library of null functions), more fun in mess land: Input Sprockets are used. I keep running into this since Apple never released them for m68k. So I started writing a fake "dummy" Input Sprocket for m68k, that just returns NULL's and FALSE's and basically says there's no controllers...don't know if that will be enough, or if it'll be useful but I think it might. "Textension" is used. This is something I hadn't heard about in MacOS before. It is a fancy extension of the standard TextEdit manager, and, of course, PPC only. It is part of Carbon, but also available as a separate library, and used by the Mac Mess/Mame gui. I'm not sure how to get around it. Probably going to write a "dummy" Textension for m68k, with just all null functions. Unlike Input Sprocket I don't think this'll work, as I probably can't just tell it that it "isn't available" and it'll fall back to plain old TextEdit. It's probably also too complex to actually write a working version that uses standard TextEdit, although that would be The Right Thing (tm) to do. ---- Anyway, my point is I'm still working on this in the background, but have hit some major roadblocks, and still can't say one way or the other if it is possible, or how well it will work. One idea I had is to bypass the current Mac gui, and just replace it by taking the parameters as a "command line"...as the gui is FULL of powerpc'isms, 8.5'isms, and Carbon'isms.
Last Edit: October 13, 2025, 17:21 by lauland
|
|
Pages: [1]
|
| |||||||||||
|
© 2021 System7Today.com. |
