[HN Gopher] Extracting the GameBoy ROM from photographs of the die
___________________________________________________________________
Extracting the GameBoy ROM from photographs of the die
Author : pabs3
Score : 369 points
Date : 2023-03-22 02:49 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ch33zer wrote:
| In the past when I've had to identify grids opencv worked well.
| Specifically the edge finding pretty reliably identified the
| grid. I wonder if it could work here? Maybe I provide a guide
| that the user can later edit?
| nezza-_- wrote:
| The Game Boy ROM is so much fun to dump in various ways. For
| example you can clock glitch it by just by scraping a contact
| with a jumper wire: https://youtu.be/64FgfhfvJ4s?t=154
| Medox wrote:
| Fun fact: in the save video, you can see Neviksti's photographs
| of the die from 2003 (https://youtu.be/64FgfhfvJ4s?t=256)
| captainkrtek wrote:
| This is fantastic. Love these kinds of deep technical adventures
| tacker2000 wrote:
| Wow this is really cool!
| jtchang wrote:
| How many bits are in a gameboy rom? How do you even take a
| picture of a rom?
| twawaaay wrote:
| You take picture of a ROM because in the past we did not have
| technology to have permanent non-volatile storage on a chip. We
| later had eproms and eeproms which were programmable and re-
| programmable but they were also expensive and problematic.
|
| 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.
| fallat wrote:
| It's also why it make sense to collect Game Boy games -
| they'll be playable for basically ever :D
| twawaaay wrote:
| Not only that, but also old gaming hardware can be
| maintained basically forever. Or even recreated from
| relatively simple components. There is no shortage of kits
| that you can assemble yourself. Old electronics is
| relatively very easy to understand, debug and fix. Well
| within ability of an average electronics engineering
| enthusiast like me.
|
| Contrasted with new games and new gaming hardware which
| will become useless in couple years when Micro$oft or $ony
| or NintEURndo decide it no longer makes business sense for
| them to maintain their online infrastructure to support
| those old consoles and games.
| HeckFeck wrote:
| My SNES still boots first time every time and it is
| inching towards 33 years old. I've never needed to open
| the case to maintain it. Meanwhile I went through two
| Xbox 360s in 4 years which RROD'd themselves.
|
| 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.
| codyd51 wrote:
| Might be of interest to folks in this thread: I wrote about the
| GameBoy boot ROM here: https://axleos.com/writing-axles-
| gameboy-emulator/
| JonathonW wrote:
| With a microscope, after removing the packaging of the chip
| (with nitric acid, in this case). The readme in the linked repo
| goes into detail both on how they produced the image used, and
| how the image is used to extract the ROM.
|
| 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).
| ilikehurdles wrote:
| I believe you mean 256kilobytes? Even at 90s handwritten
| assembly standards, 256 bytes seems too small for basic
| games.
| hyperman1 wrote:
| A quick google turns up this disassembly of the ROM:
|
| 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
| fredoralive wrote:
| Most Game Boy games use a bank switching chip in the
| cartridge, so can be larger than the 32k slot in address
| space.
| hyperman1 wrote:
| If you browse a bit on the second link, it will give you
| a list of common cartridge models.
|
| 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.
| sumtechguy wrote:
| The 256 bytes is the boot loader? You do not need much for
| that. Basically enough to init the cpu, setup a couple of
| interrupt tables, and kick it running. For example the
| 80s/90s version would be the first sector on a floppy that
| inits the OS. In addition to the BIOS setup that probably
| put the read of that floppy in motion.
|
| 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.
| toast0 wrote:
| This isn't a game rom, this is the boot rom, included on
| the cpu, that runs the boot logo / audio, and does some
| checks on the cartridge rom.
| blkhp19 wrote:
| Ah, that makes way more sense.
| tyingq wrote:
| No, it's 256 bytes of platform boot ROM.
|
| _" Loaded 128x x 16 h => 2048 bits (256 words)"_
| maxvu wrote:
| I'm guessing it's the ROM for the system. Poke various
| hardware bits, map the cartridge and jump to a certain
| address within it.
|
| 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.
| phkahler wrote:
| >> 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.
| toast0 wrote:
| It's clever, bur probably doesn't hold water legally, see
| https://en.wikipedia.org/wiki/Sega_v._Accolade
| ChickeNES wrote:
| > The ROM itself is 256 bytes, and has been previously
| extracted using a similar technique.
|
| Actually, it was originally extracted via clock glitching to
| cause the CPU to skip the instruction that unmaps the bios
| JonathonW wrote:
| From what I was reading, the original Game Boy boot ROM was
| originally extracted photographically.
|
| 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.
| gumboshoes wrote:
| Extraordinary. I love other people's well-explained expertise
| even if I have no use for it whatsoever.
| nrabulinski wrote:
| I love Travis' work. Had the pleasure of meeting him last year in
| Stockholm. Not only does he have fascinating and engaging talks
| he's super cool and down to earth.
| tmountain wrote:
| I love stuff like this. I saw something loosely related a while
| back where someone had taken apart an old kids toy (the atomic
| powered robot), and it had a little plastic disc inside for a the
| sound and voice effects.
|
| 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.
| amelius wrote:
| Then you will like the recovery of sounds from ancient pottery.
| tmountain wrote:
| Nice try...
| userbinator wrote:
| _a little plastic disc inside for a the sound and voice
| effects_
|
| It took me longer than expected to realise you were talking
| about a phonograph record.
| tmountain wrote:
| Not vinyl though, but yeah...
| svendahlstrand wrote:
| Shameless self-promotion: if you enjoyed Travis' ROM dumping, you
| might find my piece about sniffing the Game Boy's LCD data bus to
| take screenshots interesting as well.
|
| https://github.com/svendahlstrand/game-boy-lcd-sniffing
| circuit10 wrote:
| Something that I think is even more interesting is that someone
| made a screen capture device that would go between the
| cartridge and the console and work only based on what code the
| game was accessing by reconstructing the entire state of the
| Game Boy based on what paths were taken in the code
|
| https://there.oughta.be/a/game-boy-capture-cartridge
| miduil wrote:
| So cool and really love that people still found even less
| intrusive ways to capture gameplay:
|
| https://there.oughta.be/a/game-boy-capture-cartridge
|
| https://news.ycombinator.com/item?id=34069305
| wkjagt wrote:
| This is really amazing, thanks for sharing! How did you know
| which pins to look at? And do you know what the other pins do?
| I'm super curious now, and actually have an original gameboy
| which I now want to open up :-)
|
| I wonder if these same signals can be used to make an adapter
| to connect an external screen.
| HopenHeyHi wrote:
| You figure out which pins to look at by time consuming
| painstaking trial and error. :)
| hashhar wrote:
| Anyone who liked this would probably also find
| https://www.youtube.com/watch?v=6mOJtrFnawk very interesting.
| v-erne wrote:
| Wow that's amazing - he actually created almost an entire
| gameboy just to "capture" video signal from gameboy. Its
| astonishing and terrifying at the same time. And rises some
| interesting philosophical questions (if he managed to create
| perfect emulation is this really video capture from the point
| of view of user or something wholly different)
| causi wrote:
| _A biological microscope will not work, because the silicon
| substrate is opaqe to visible light; in a metallurgical
| microscope, the light reflects off of the sample rather than
| transmitting through it._
|
| Is there a reason you couldn't just use a biological microscope
| and add top=-illumination yourself?
| ckocagil wrote:
| You can if there's enough space between the lens and the die.
___________________________________________________________________
(page generated 2023-03-22 23:02 UTC)