Gameboy Emulator in ARM Assembly(github.com)
github.com
Gameboy Emulator in ARM Assembly
https://github.com/cottsay/arm_asm_emu
37 comments
I'm pretty sure there are similar projects for ARM-based microcontrollers, which is probably a bit more interesting as a hobby project.
Curious if this can work on the GBA ARM platform? I’m under the impression that the current gb emulator is a bit lacking.
I thought the GBA literally included the GB chip and just passed control to it though?
Would be cool to see this run on the GBA still.
Would be cool to see this run on the GBA still.
When playing an 8-bit GB game on a GBA that is indeed what happens. It even uses the Z80 chip for sound in GBA titles.
That said, there is a homebrew GB emulator for GBA (Goomba), and at least one reason to use it: neither the Game Boy Micro nor the Nintendo DS can natively play 8-bit Game Boy games. As far as I understand it, the only reason why they can’t is because 8-bit Game Boy carts use 5V power and logic, but GBA carts use 3.3V power and logic, and there’s only so much power and switching circuitry you can fit into a pocket-sized gadget.
That said, there is a homebrew GB emulator for GBA (Goomba), and at least one reason to use it: neither the Game Boy Micro nor the Nintendo DS can natively play 8-bit Game Boy games. As far as I understand it, the only reason why they can’t is because 8-bit Game Boy carts use 5V power and logic, but GBA carts use 3.3V power and logic, and there’s only so much power and switching circuitry you can fit into a pocket-sized gadget.
I've always found the "include the old console in the new console" strategy for backward compatibility a really smart implementation idea.
PS2 did the same thing for PS1.
PS2 did the same thing for PS1.
The Sega Genesis did something similar - its hardware is a strict superset of the Master System's, so it can run SMS games natively.
However, unlike the Game Boy and GBA, the cartridge ports on the two systems are physically different (50 pins vs 64) so a cartridge adapter is still needed.
In that situation, I think an approach like the Super Game Boy's is probably better: include the old console's hardware in the adapter rather than in the new console, so that the new console's design need not be constrained by backward-compatibility.
However, unlike the Game Boy and GBA, the cartridge ports on the two systems are physically different (50 pins vs 64) so a cartridge adapter is still needed.
In that situation, I think an approach like the Super Game Boy's is probably better: include the old console's hardware in the adapter rather than in the new console, so that the new console's design need not be constrained by backward-compatibility.
The initial PS3s also did the same to keep PS2 backwards compatibility.
True, but that model was _very_ short lived.
To add mor context: there were two main PS3 models with PS2 support, the first one with most of the PS2 hardware (which you might be referring to), and the second one with just the gpu + software emulation for the CPU. The later PS3s scraped it all and had no PS2 emulation. With PAL/NTSC variants, that amounts to quite a spectrum of backward compatibility.
and included a grill!
In a sense also the Wii (Wii was basically a GameCube with 1.5x the clock and extra hardware) and Wii U (3 Wii cores strapped together + both the new and Wii GPUs + extra hardware) did so
For the same reason it is actually possible to play GameCube games on a Wii U (through homebrew in the vWii System)
Is it through homebrew Wii? I thought it was kind of a VM situation but was still the WiiU in control (that’s how you can have the game pad work with GC games). Though I’m not sure.
I would love to read a nice breakdown about Nintendont ( the GC comparability software for WiiU homebrew) because I think it’s pure magic.
I would love to read a nice breakdown about Nintendont ( the GC comparability software for WiiU homebrew) because I think it’s pure magic.
One thing to note is that Nintendont is not for Wii U only, it's also useful for later Wii models that removed GC support.
The Wii has two processors: the main PowerPC one which runs the game bare-metal dubbed Broadway, and a smaller ARM9 core hidden inside the GPU package dubbed Starlet which runs a separate firmware called IOS. The game running on Broadway accesses all the Wii hardware by sending requests to IOS - which also controls clocks etc. Wii U has a similar architecture with the Espresso and Starbuck respectively. On the Wii, Starlet also handles background network activity and WiiConnect 24.
The Wii holds multiple IOS versions in its main NAND flash, and everytime a game loads the System Menu (the one with the channels) reads the required version from the game metadata and reboots both Broadway and Starlet into the game and correct IOS versions. This is why for example early games like Twilight Princess didn't light up the drive led bar when receiving messages like in more recent games: that game was stuck on IOS4, which didn't support that feature.
Now, what happens when the user inserts a GameCube disk into a compatible Wii is that the System Menu loads a special IOS called MIOS. This disables access to all Wii-specific hardware, downclocks the CPU and GPU, sets up the memory layout and effectively turns the system into a GameCube (it's been a while, but I think it also completely disables Bluetooth so you can't even use the Wiimote to shut it down, you need to get up and walk to the machine to turn it off). In the initial versions it didn't scrub memory, so the Twiizer Hack happened: in GC mode you can only access 16 of the 64 MB memory, but using tweezers to manipulate the address lines they managed to "move" this window and dump it over the controller port serial, and found keys.
IOS can and has been hacked or entirely replaced, the Twiizers team even wrote their own 100% free replacement, but other teams came up with hacked versions that i.e. redirected optical drive calls to USB devices, to enable piracy.
Nintendont skips MIOS: it runs with IOS, so it has access to all the hardware as if it was a native Wii application, so it can access the SD, USB, Bluetooth and even the NAND flash or network if it wanted to.
The Wii U works similarly: Starbuck runs a firmware called IOSU (not based on IOS). When starting the Virtual Wii mode, a process called cafe2wii is launched. This shuts down IOSU, lowers clocks, disables access to Wii U hardware and reboots into IOS80 to run the Wii System Menu.
You can read more at hackmii.com, wiiubrew.org and wiibrew.org
The Wii has two processors: the main PowerPC one which runs the game bare-metal dubbed Broadway, and a smaller ARM9 core hidden inside the GPU package dubbed Starlet which runs a separate firmware called IOS. The game running on Broadway accesses all the Wii hardware by sending requests to IOS - which also controls clocks etc. Wii U has a similar architecture with the Espresso and Starbuck respectively. On the Wii, Starlet also handles background network activity and WiiConnect 24.
The Wii holds multiple IOS versions in its main NAND flash, and everytime a game loads the System Menu (the one with the channels) reads the required version from the game metadata and reboots both Broadway and Starlet into the game and correct IOS versions. This is why for example early games like Twilight Princess didn't light up the drive led bar when receiving messages like in more recent games: that game was stuck on IOS4, which didn't support that feature.
Now, what happens when the user inserts a GameCube disk into a compatible Wii is that the System Menu loads a special IOS called MIOS. This disables access to all Wii-specific hardware, downclocks the CPU and GPU, sets up the memory layout and effectively turns the system into a GameCube (it's been a while, but I think it also completely disables Bluetooth so you can't even use the Wiimote to shut it down, you need to get up and walk to the machine to turn it off). In the initial versions it didn't scrub memory, so the Twiizer Hack happened: in GC mode you can only access 16 of the 64 MB memory, but using tweezers to manipulate the address lines they managed to "move" this window and dump it over the controller port serial, and found keys.
IOS can and has been hacked or entirely replaced, the Twiizers team even wrote their own 100% free replacement, but other teams came up with hacked versions that i.e. redirected optical drive calls to USB devices, to enable piracy.
Nintendont skips MIOS: it runs with IOS, so it has access to all the hardware as if it was a native Wii application, so it can access the SD, USB, Bluetooth and even the NAND flash or network if it wanted to.
The Wii U works similarly: Starbuck runs a firmware called IOSU (not based on IOS). When starting the Virtual Wii mode, a process called cafe2wii is launched. This shuts down IOSU, lowers clocks, disables access to Wii U hardware and reboots into IOS80 to run the Wii System Menu.
You can read more at hackmii.com, wiiubrew.org and wiibrew.org
Thanks for this response. I know what a few of the words means but this nicely puts it all together in my head. :)
Happy it helped!
I also found some info about how Nintendont lets you use controllers and virtual memory cards: it provides the game with its own implementation of the GameCube system calls which then use whatever is best suited for the task, even for the controllers. The USB GameCube controller adapter is completely different from the native ports in GC and GC-compatible Wiis (it's a USB HID device, while the original one sits on an internal bus). Same for memory cards, in the original hardware those sit on the EXI bus while the Nintendont just works on files on the SD card), and the same applies to the Optical Disc Drive.
In my opinion one of the best, if not THE best, ways to play GameCube games on modern screens
The very first one was http://mapage.noos.fr/gbongba/ because everyone then said it was impossible to achieve. It surely motivated goomba to spawn and do a much better job.
Some versions don't, like the GameBoy Micro and, in a sense, the Nintendo DS which includes the GBA CPU but not the GB one. There's already an emulator called Goomba that runs on the GBA, even in older GBA models it's useful because you can launch it from a GBA flashcart
Probably challenging given that the GBA's ARM7TDMI core runs at about 17MHz. Perhaps doable if the graphics hardware as accessed from the ARM core can operate in the same modes the Z80 core uses (I forget if it's a strict superset, or what, exactly).
I never got that far, but my goal was always to give it a shot. All of the ARM instructions used in this emulator are supported on that CPU. You'd have to implement interface adapters specific for the GBA hardware, but I structured the project such that you shouldn't need to untangle anything.
That’s awesome. Hopefully someone maybe picks it up because goomba is kind of terrible and weird :)
Can the GBA run Linux?
Not in the most meaningful sense of "natively and without heavy modifications", because the GBA's ARM lacks the proper MMU. You could always go the route to just emulate something that runs Linux, but it's probably not going to be very usable for anything.
You can configure Linux to run without an MMU - it seems like that should be doable?
Oh I didn't know, indeed: https://www.kernel.org/doc/Documentation/nommu-mmap.txt
Probably not, but there was a neat project from a while back that got an ancient version of UNIX running on it: https://web.archive.org/web/20060831141959/http://www.kernel...
I remember running a version of uCLinux on my GBA SP back in 2006
The GPU implementation is surprisingly simple
https://github.com/cottsay/arm_asm_emu/blob/main/src/gpu.S
https://github.com/cottsay/arm_asm_emu/blob/main/src/gpu.S
Makes me wonder how easy it would be to implement something like this with WASM and either WebGL or WebGPU.
Depending on how 'correct' the video emulation is (e.g. per pixel, per scanline or per frame), it won't make much sense to offload the video emulation to the GPU because it must run in lockstep with the rest of the system emulation. Moving the entire emulation to the GPU also makes little sense because such old-school system emulations are hard to parallelize (because of the above mentioned lock-step problem - for a cycle-correct emulator you basically need to emulate one clock cycle for all 'subsystems' after another). You could probably emulate a ton of fairly slow gameboy emulators in parallel though :)
Digging a bit deeper, it seems this is intended to run on a 32 bit ARM-based Linux system. (Cross-)Compiled out of the box with arm-none-eabi-binutils (obviously no gcc required...), but I haven't tested the binary so far.