gb6: game boy emulator for System 6

I think the speed increase would come from the fact that optimized 68K code would read from aligned addresses? The emulator has to check for this alignment and use the slow path for unaligned accesses. Compare the instruction cycle counts in the CPU manual between aligned and unaligned accesses to see if this can be true.

Mac OS APIs are full of structs with 32-bit members that are only 16-bit aligned. For example, the parID field of FSSpec and portBits.baseAddr of GrafPort.

(I think you were clear on this, but in case I confused anyone else, I was talking about emulating 68K code on a little-endian host.)
 
Mac OS APIs are full of structs with 32-bit members that are only 16-bit aligned. For example, the parID field of FSSpec and portBits.baseAddr of GrafPort.

(I think you were clear on this, but in case I confused anyone else, I was talking about emulating 68K code on a little-endian host.)
I think both I and @joevt still thought this was about emulating a Game Boy (not GBA, nor Color Game Boy) on a 68000 Mac, as per the beginning of the thread. If, e.g. you're thinking about emulating a 68000 on ARM you might want to check out the posts and comments on MØBius (unless you've already chatted to me about that. No, just checked, that was @nicovr ). MØBius is a 68000 emulator written in ARM Cortex assembly code in under 6kB and will be able to emulate a Mac Plus on a standard 125MHz Raspberry PI PICO RP2040 (or RP3250), at least full speed.
 
I think both I and @joevt still thought this was about emulating a Game Boy (not GBA, nor Color Game Boy) on a 68000 Mac, as per the beginning of the thread. If, e.g. you're thinking about emulating a 68000 on ARM you might want to check out the posts and comments on MØBius (unless you've already chatted to me about that. No, just checked, that was @nicovr ). MØBius is a 68000 emulator written in ARM Cortex assembly code in under 6kB and will be able to emulate a Mac Plus on a standard 125MHz Raspberry PI PICO RP2040 (or RP3250), at least full speed.
MØBius sounds very cool! Is the source available somewhere?
 
MØBius sounds very cool! Is the source available somewhere?
Thanks, I think it is, indeed cool. One of the coolest aspects is that it's small enough to fit in half an RP2040's 16kB cache and because of the way the cache is partitioned, a Mac ROM and disk will occupy the other half most of the time. Correction though, there's not enough RAM for a Mac Plus, but an RP2040 should be able to emulate a 256kB Mac (cf https://68kmla.org/bb/threads/the-mythical-mac-256k.46149/) and an RP2350 can emulate a Fat Mac. Perhaps I'm building up a bit of an interest base! It's written, but doesn't yet fully assemble. If people are willing to pester me I'll open the source code once it assembles.

You can read the progress and ideas behind it from here:

 
I recall some PalmOS Gameboy emulators used to work okay, granted that was on a 16mhz Dragonball.

Might be a good source of 68k assembly routines.

 
Last edited:
Wow, I totally missed the recent discussion in here. I picked this project back up in 2025, implemented a JIT SM83 -> 68k compiler, and it works well now. On my IIfx I can get 60fps with sound, and on my 40 MHz C650, 120-200 fps with sound. With sound turned off, it's decently playable (30fps ish) on SE/30 and IIci. Original 68000 compact Macs get around 7 fps. I've learned a lot since I originally started this and my goal of running on the Plus was a little unreasonable, but this is still a lot faster than the original interpreter version which was about 1 frame every 5 seconds on 68000.

More info on my website: http://constcast.org/gb6.html and the code/downloads are here: https://github.com/mlaux/gray-brick
Me playing Tetris:

Re: phoinix PalmOS GB emulator, I ended up using their strategy of holding 2 GB registers in one 68k D register in 0x00BB00CC format and using SWAP to access the high word, it worked well. I also used their flag handling strategy of `move sr, Dn` and keep the flags in 68k format instead of GB format.

If I had to do this over I'd probably skip the compiler and go with a "threaded interpreter" approach where it's still interpreted but each instruction's handler jumps directly to the next one's handler. The compiler required a lot of compromises with the GB interrupt handling.
 
Last edited:
Back
Top