Extracting the GameBoy ROM from photographs of the die
github.com
github.com
I wonder if these same signals can be used to make an adapter to connect an external screen.
The ROM itself is 256 bytes, and has been previously extracted using a similar technique. The last thing it does on boot (before moving on to the cartridge’s entry point, which is adjacent) is remove itself from the system’s address space, so special techniques like this are needed to extract it (can’t just do it from normal Game Boy code).
Actually, it was originally extracted via clock glitching to cause the CPU to skip the instruction that unmaps the bios
The Super Game Boy boot ROM was extracted using clock glitching, and the Game Boy Color ROMs (it has more than one) were extracted using a combination of clock and power glitching.
https://gist.github.com/drhelius/6063288
You can see the comment of the last line is $00fe and the first line is $0000, so assuming the last instruction takes 2 bytes, that's 256 bytes.
Besides, it is a 16 bit machine, so it has 64K addressable space. Going above that requires bank switching. Here is the memory map:
https://gbdev.io/pandocs/Memory_Map.html
I see 32K cartridge ROM (at most), 8K work RAM (built in), 8K video RAM, and some memory mapped devices. At E000, almost 8K is actually wasted as an echo of another range.
As a kid, I once wrote a flame simulation in DOS. The resulting com file was about 100 bytes, so it was possible to write usable programs in <256 bytes. Presumably a very simple DOS text mode game might fit in 256 bytes
See e.g. https://gbdev.io/pandocs/MBC5.html which gives you 8MB as peak ROM size, but it is all paged via the 2nd half of the cartridges address space, in blocks of 16K. Code used by the whole program preferably resides in the first (unbanked) 16K.
This pushes program designs to prefer to either use banking mainly for data (maps/graphics/...), or split the program in independent 16K sized sub-programs that don't communicate too much. If code in bank A uses data from bank B, you'll have to switch back and forth a lot, mediated by unbanked code. You can go all the way, of course, but it is an annoying way to program.
If memory serves, it also checksums the Gameboy logo-intro at the start of every game cartridge -- subjecting non-licensed game publishers to additional copyright claims.
That is quite clever! Don't run without a valid logo, and therefore violate a trademark or copyright if your game is to run without permission. It's like DRM but enforced legally not technically.
"Loaded 128x x 16 h => 2048 bits (256 words)"
If I remember my GB history right this was a DRM measure to stop companies from copying the rest of the game rom and it still work on the actual hardware. Most emulators did not really need it as they had basically figured out what that area was doing anyway. Think in the GBA they even had an animation in there (which you can tweak going by setting a few HW registers) and the ROMS checked to see if the screen memory was correct at startup.
So the main solution to have any programming on the chip was to actually etch it permanently. That's why we can read it today.
Contrasted with new games and new gaming hardware which will become useless in couple years when Micro$oft or $ony or Nint€ndo decide it no longer makes business sense for them to maintain their online infrastructure to support those old consoles and games.
I know the hardware is magnitudes of orders more capable, but the old kit is winning on the Darwinian front. It'll probably still work when my grandchildren uncover it from the attic. It might even play the Super Mario World outro theme when the heat death of the solar system arrives.
They were able to play it back by taking a high resolution photo and decoding the image.
This feels like magic to me no matter how well I understand the science behind it.
It took me longer than expected to realise you were talking about a phonograph record.
Is there a reason you couldn't just use a biological microscope and add top=-illumination yourself?