The DMG boot ROM fits into the top 0x100 bytes. To protect it from being snooped, the last instruction shuts off the boot ROM by flipping a register that can’t be flipped back, mapping the top 0x100 back to the cartridge (and allowing the cartridges interrupt vectors to be installed.) So, there is no jump to 0x100 at any point; they just fit the DMG boots ROM perfectly into 0x100 bytes and control flow leaves bootstrap right as PC hits 0x100.
This simple security mechanism was extremely effective, and lead to the DMG BIOS being undumped until relatively recently, when it was dumped by imaging the ROM directly and via fault injection to skip the last instruction.
In only 0x100 bytes of ROM that is so simple, there’s unlikely to be too many software bugs that allow dumping. Decapping a chip and imaging it isn’t cheap either. The hardware mechanism for locking the boot ROM may be hard to figure out without having the boot ROM already. And given how simple and effective the hardware mechanism is, it, too, is unlikely to have any obvious flaws to exploit.
So they didn’t exploit flaws, they just tried to work around the protection.
Even though the Gameboy is relatively slow (~4.7 Mhz processor IIRC) it’s still not going to be easy to hit exactly at the right time to be able to perform your fault injection.
The protection is simple enough to be effective. If you did it with a modern manufacturing process it’d probably be quite difficult to be able to image the bits directly...
Nowadays, for say Nintendo Switch, you are more likely to see keys and firmware data dumped via early boot exploits or privilege escalation.
Fault injection is a method to cause microprocessors to execute instructions "incorrectly" by manipulating external factors (clock frequency, input power, etc). Getting the CPU to fail to write to a memory address, or flipping the truth of a comparison instruction, and other "glitches" can influence execution of security-sensitive code and ultimately undermine security mechanisms.
In my mind, "network play" refers to playing multiplayer games over a network, which this isn't? This is about playing a Game Boy game on an emulator that is running on a server somewhere, which sounds very much like "Cloud gaming" to me.
No. Execution actually starts at 0x0 like most architectures, but the boot loader fits in the first 256 bytes, so after the last instruction executes, execution continues on at 0x100
Myself curious to write a GB emulator... how do you get images? After a quick search I see a list of "homebrews" on a collection repo on GitHub [0]. Is there a particularly good place to find games?
Legally? I've been tracking down physical cartridges and using a ripping tool, which is basically a hardware slot for a gameboy cartridge that connects to a PC via USB. The one I own personally is this one, which can dump all the common cartridge types ("mappers") and their save data:
The popular titles (especially Pokemon) can be hard to track down at a fair price, but lesser known gameboy games can be found easily on Amazon and from other used sellers for a few dollars each. Even stuff like Tetris is easy to get ahold of because so many copies were produced. Bad games still make great test cases. :D
If you're after homebrew there's a whole bunch of sites that host it. One site that I pulled my early test ROMs from was:
But there are of course countless others. The demo scene is quite lively, and once your emulator is working at a basic level, demos can be good test cases since they often use the hardware in surprising and unusual ways. Finally, once you're serious about accuracy, check out this list of test ROMs:
Especially the tests by blargg; these are designed with a simple pass/fail result but go seriously in depth checking out hardware edge cases, and the source code is available which makes debugging them a breeze. Finally passing his CPU test was a major milestone.
The rabbit hole is very deep, but it's a fun dive!
Being copyrighted, it's not legal to redistribute them. You're favorite torrent search engine might be able to help, though. Or you can buy them off eBay and dump the image yourself. I'm not sure what the current state of dumping hardware is, but 10 years ago I hacked together one that used a PC parallel port.
> Works with Windows XP or higher and Linux/Mac (console version). On Linux/Mac the speeds are much slower.
How come?
> You'll just need a Micro-USB or USB-C cable depending on the connector type you choose. Please note the USB-C connector only has the USB 2.0 lines attached so it may not work with devices expecting a USB-C capable device; you might need a USB-C to USB-A adapter and then a USB-A to USB-C cable.
Do you know if there are plans for a future revision of the hardware which will allow for the greater speed that USB-C can provide to be utilized?
>> Works with Windows XP or higher and Linux/Mac (console version). On Linux/Mac the speeds are much slower.
Not sure. It dumps the cart over serial and there were some problems with higher speeds at one point.
> Do you know if there are plans for a future revision of the hardware which will allow for the greater speed that USB-C can provide to be utilized?
I don't think the carts themselves are that fast, there wouldn't be a huge amount of benefit. At least when I tried it it wasn't even coming close to using full USB 2 speed.
The emulator itself seems to be in the clear, however `gameboy.live` certainly is not. It's hosting quite a handful of copyrighted games, and that's likely to earn it a cease and desist if it gets popular. Of course, at the moment it is also being hugged to death; I was not able to start a session.
I can't imagine that telnet versions of gameboy games are really going to take off in any capacity. That said, if you do choose to self host, make sure you protect the access in some way, or only distribute freely licensed homebrew, etc etc.
Nintendo has written or contracted a lot of emulators themselves. The grandparent may be thinking of the pervasive use of the iNES header format, which originated with an unofficial (though not open source) emulator:
At uni, a large chunk of my final-year grade hinged on a large project, where we'd meet up with a supervisor, build a non-trivial application, and write a dissertation on it.
One of the best projects from recent years that was handed out as inspiration was someone that built a game boy emulator, with the ultimate aim of being able to run Pokemon Red.
This dissertation was public on the CS site for about 5 years, with source code to run it, and although this was pre-GitHub Nintendo were still very litigious back then. No ROM's were provided, so I assume Nintendo either missed it, or didn't care.
Yes. I cannot understand the point of those people who kept "forking" repositories on GitHub, but don't do any development on them. They have a long list of untouched forked repositories, like Linux kernel, Apache, nginx, ..., and makes it particularly difficult for me to find the repos of their original works.
Even as a "backup", it's pointless, because it's all Copy-on-Write, there's no backup.
As if they never learned to use the "Star" button to bookmark...
Personally, I don't fork any repos unless I'm working on a derived program, or working for a patch, even so, I'll delete my forked repos as soon as the patches are accepted (if it's a one-time contribution), so these forked repos won't spam my own list.
I wish github had a bookmarks feature. Currently most people star when stars should be a "I used this and its good" rather than "Seems interesting, should take a look later"
I know it's an obvious suggestion, but 'GitHub' folder of browser bookmarks? Not clear to me what value it would add as a GH feature, just interface clutter IMO.
The Gameboy & in fact, all games consoles completely passed me by - my experience of hand-held gaming was Donkey Kong and TomyTronic. Now I'm going to have a chance to see what I missed out on - sort of :)
If you like puzzle games, Tetris, if you like adventure games, Link’s Awakening. If you like platforming, I’d recommend any of the Super Mario Land or Donkey Kong Land games!
What do you mean? 19 year olds have no responsibilities to speak of except "school". When I was 19 I was doing the same shit, loads ands loads of time.
The emulator will firstly break at the ROM entry point 0x0100 in debug mode, which is the entry point of the game program.
That start address is the same as in CP/M, and subsequently DOS 16-bit COM-format binaries. I wonder if Nintendo was inspired by that.