Reverse engineering an old video game console without documentation

[chilistudios]

Has anyone here ever reverse engineered an old console like the NES or Genesis without the use of pre-existing documentation like Rare and all those other third party devs back then? I've been studying hardware engineering as of recently and I want to learn more. What do I need?

[Stephen Moss]

1) If you do not know your resistor colour code  you will need a resistor colour code chart to help you determin the vaule of any through hold resistors

2) A magnifyer of some destrition to help read the device number on IC's value of surace mount resistors/capacitors and value printed on any small capacitors. Plus it can help with visually following a PCB track about the board.

3) A Multi-meter to continutiy check the pcb traces as when a trace becomees surrounded by other it can become difficult to follow visualy, plus when it goes under an IC or to one of its pins you cannot be certain whether or not it makes other connection underneath the IC either other pin on that IC and/or emerges from under it at another point on either the same and/or other side of the other side of the PCB.

 

For regular components it should be possibleto look up the datasheets and marry pin number with the names (indicate pin fucntion), but with any custom made devices that data may be difficult, if not impossibleto come by and so while oyu may be able to obtain a full diccenction diagram as full schematic may not be possible as without IC pin name indicating their function it can be difficult to get a full picture of how parts of the console work together and how it works as a whole.   

 

[DanBoris]

On 7/29/2023 at 7:37 PM, chilistudios said:

Has anyone here ever reverse engineered an old console like the NES or Genesis without the use of pre-existing documentation like Rare and all those other third party devs back then? I've been studying hardware engineering as of recently and I want to learn more. What do I need?

 

When I wrote my Odyssey 2 emulator back in the 90's there was no documentation available except of the Intel 8048 processor it used. I had to figure out everything else through reverse engineering. Funny enough, once the emulator was out there, one of the original O2 programmers sent me the official documentation for the machine. 

[Crazy Climber]

Didn't Dan Kitchen do this with the Atari 2600 back when he wrote Space Jockey for US games? 

[+bent_pin]

I have a 4-channel oscilloscope and a 34-channel logic analyzer that I use for chip/bus timing analysis, clock frequency, etc. With the speeds of these older systems, you do not need to spend too much money on these. I think I spent less than $500 for the pair, but you could probably do better on ebay.

 

Just make sure you have at least 10 samples per clock of the fastest component, more is better. So, a 2600 would require a minimum 36MS/s. An NES would require 220MS/s. A Sega Genesis would require 54MS/s. I'm working on hardware emulation of older chips right now where I have 8 operations on the new hardware to emulate 1 operation on the old hardware, so I analyzed the bus at 8 samples per clock to get the most accurate timing that I could recreate. 

 

You can probably find timing charts to help, but nothing beats seeing the systems tick. I've also pulled chips and built basic systems around them to run at 2Hz. 

[DanBoris]

23 hours ago, DanBoris said:

 

When I wrote my Odyssey 2 emulator back in the 90's there was no documentation available except of the Intel 8048 processor it used. I had to figure out everything else through reverse engineering. Funny enough, once the emulator was out there, one of the original O2 programmers sent me the official documentation for the machine. 

 

Some background on how I did the reverse engineering for this system.

 

First I needed rom dumps, so I built a cartridge reader and a reader for the BIOS ROM that is in the processor.

 

For schematics I hand traced the board and drew them out with schematic capture software. With the exception of the audio/video chip everything else on the board was off the shelf parts. 

 

Obviously the hardest part was the audio/video chip. I took a two pronged approach to that. First, I wrote the beginnings of an emulator that implemented everything but that chip and just logged all the writes to the chip. Since almost all O2 games start with the game select screen, I let it run until I was sure it had written that screen to the video chip. I then looked at the logged writes and tried to match them to what was on the screen. This was made somewhat easier by the three 'e' in "game select'. The O2 doesn't have traditional character based video so it wasn't as straight forward as finding the characters in video memory. 

 

To verify what I had figured out a build an adaptor so I could connect an eprom emulator to an actual O2, this allowed me to run my own code on the system. I took what I learned from the emulator and applied those same video writes to the actual system to see how the behaved. This initially produced some strange results because as it turns out, I had mistakes in the 8048 CPU core I had written for the emulator, so the values being sent to video memory weren't entirely correct. Once I figured out that screen I moved on to the grid style background that is common on O2 games. I used Football as a test case here since it has a simple use of the grid. From that it was pretty easy to figure out how the grid was drawn. I basically continued this process until I figured out all the graphic objects. 

 

I would have taken this same approach to figuring out the sound, but as I mentioned above, I was provided the documentation which showed how the sound worked, it also helped me verify my assumptions about how the video worked.