In order to write emulators for older systems, one has to know the "inner workings" of the original hardware and understand what makes it "tick". I've noticed that with some systems, proprietary documentation can be found online (leaked), but if one does not have access to this official documentation, how can one figure out how the hardware works and be able to transfer the hardware logic to software logic?

I know that one can simply dump their system BIOS or ROM, but what about CPU, sound, or video cards?

2 Answers 2


Not in all cases the schematics, parts lists, board views or even ROM assembly listings are "leaked" - it was quite common until into the 1980s to ship (or offer as an addon product) full documentation of that kind with professional electronics (which many computers were categorized and priced as) and also sometimes with consumer electronics. Existing copies of these might or might not have been copied with the publisher's consent, but they were available to the general public.

IIRC, So called "technical reference manuals" were available for ISA based IBM PCs (not MCA based ones, though detailed "maintenance manual"s exist) and 8-Bit Apples.

Mainboards and extension cards in the 1980s and 1990s commonly had schematics in the included documentation.

Often, so called "leaked" material, while never intended for the general public, was originally marketed to the washed masses (professional repair workshops and developers).

Also, programming books from that era (eg books on EGA/VGA or PC assembly programming) commonly describe things in register-level detail - which was needed if there was no sufficiently capable device driver included in your OS or programming environment!).

Look for the documentation coming with early implementations of a standard: These often assumed that the user had no documentation about the standard that they could be referred to... For example, printers using the parallel interface still sometimes found today in old or niche devices existed a decade(!) before PCs, and 1970s manuals would assume that the poor user that just unpacked the printer will now have to write a device driver or even design an interface board.

On a sidenote, it was not rare to find the schematic papers inside the case in a pouch or similar 1970s/1980s TVs (have found such in a curbside find Philips K11 or K12 TV which I stripped for parts ages ago, whoever put them there...)...

Even today, for CPUs as well as peripheral and memory chips datasheets¹ are commonly available online, either from the manufacturer or from online datasheet archives. These will either contain instructions on how to program them or refer to further manuals (eg if there is an embedded CPU core, they will commonly refer to the pertinent CPU/architecture manual).

The biggest problem in understanding hardware architecture from existing hardware and/or schematics are programmable (Flash, OTP, external, mask ROM...) parts that do not allow reading back and/or interpreting the code. Examples:

  • microcontrollers with a protect bit set - if they can be overwritten, that is often only as a whole, if you want to overwrite the protect bit you overwrite the content!

  • PALs/GALs/CPLDs... that actually have the "result" of code and not the code itself stored in them - think of these as parts that you can rewire at will via some coded input from a programming device, and they do not allow you to read back the rewiring instructions - and what is in them can be stateful with some devices and so cannot reliably be analyzed by just measuring out truth tables.

  • Devices that will be fed code from an external memory (sometimes stored in ROM or mass storage and uploaded via an init routine from some CPU) that is in a non-source, undocumented format: RAM based FPGAs, for example.

  • Parts that are INTENTIONALLY made hard to reverse engineer, eg modules that are potted and/or outfitted with self-erase/self-destruct devices (crypto hardware)...

  • ASICs and gate arrays - the hardwired version of PAL/GAL/CPLD

  • Application specific chips that have a whole, programmed computer system inside, which is documented only at a functional level (no one except the manufacturer of that chip has the code in that ROM). The PS/2 keyboard controller in a modern PC would be such a thing - a deeply embedded MCS48 or MCS51 with ROM and all, though the code might be very similar to what is in an actual dedicated keyboard controller chip.

¹ The "datasheet" is a type of formal documentation when it comes to electronic parts, very different from the use of "datasheet" for marketing brochures!

  • 1
    This is a good answer but misses one thing; a lot of the information on figuring out how a piece of hardware behaves is by testing out pieces of code on the hardware itself and seeing what happens. For example, this is how the undocumented flag bits on the Z80 were finally explained. The documentation is often incomplete or wrong, and only experimentation can give a good explanation. Aug 23, 2017 at 21:16
  • 1
    Sounds like you are describing a distinct method that you should put in a distinct answer. Aug 23, 2017 at 23:46

The "old" computers usually used ICs with enough info to reverse engineer their functionality via program (I remember that most ICs datasheets also contained their circuit diagram). For example mine ZXS emulator works this way including chips like:

  • Z80A
  • AY8912
  • WD2797
  • MHB8255A

Which allows HW emulation without hacks. For example even custom low level FDD or tape loaders works (on most emulators are those just hacked by scannig for specific call instruction instead making custom loaders not usable). The draw back of this approach is that it requires MC (machine cycle) level timing of the simulation which lowers the performance.

The chips that are a black box you hack or search for reverse engineered info as most likely someone already did it and post online ...

Yes chip data-sheets contain errors especially the Z80 ... took me a long time to sort its instruction set out (and even claimers of 100% correctness are usually wrong). For info about debugging such things see:

So to answer your question I would try this (in present order):

  1. obtain machine schematics

    circuit diagrams where commonly shipped along with the HW. So just google for circuit diagrams ...

  2. obtain datasheedts on all used IC's you can

    You can obviously ignore the common TTL logic if you can reverse its functionality.

  3. obtain testing SW

    some architectues provide autotests that could surface hidden problems ... like ZEXALL. Using demos and games is also a good way but those usually either work or not but do not disclose what is wrong.

  4. check against different emulator core

    This is best from start you can execute program both in your and in foreign emulator on per instruction manner. And simply check the registers and specific memory places for discrepancies. If found you know exactly which instruction went south...

  • Note for when you're checking against a different emulator - do not copy the other emulator. Instead, write test code and test it on the real thing, then observe the behaviour. If you found it hard, the chances are that somebody else did.
    – wizzwizz4
    Sep 8, 2017 at 17:05
  • @wizzwizz4 stepping computer on HW level is difficult due to the other processes which are bound to clock. But yes comparing with real HW is best (but not always possible).
    – Spektre
    Sep 8, 2017 at 17:12
  • I was thinking more along the lines of (the pseudocode): setup, tricky instruction, POKE 8000, register0, POKE 8001, register1..., display text on screen.
    – wizzwizz4
    Sep 8, 2017 at 17:18
  • @wizzwizz4 heh more like POKE ... POKE Randomize USR and PEEK ... PEEK ... :) problem with using higher level stuff is it runs a lot behind ... and using shared VRAM on real HW for test is really tricky but doable like DEVASTACE :) but during building your Emu the OS usually does not work yet ...
    – Spektre
    Sep 8, 2017 at 18:32
  • I meant writing a testing program on the machine, storing the values of the registers so the printing function didn't clobber them if there wasn't hardware printing then printing the values.
    – wizzwizz4
    Sep 8, 2017 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .