How to obtain CPU and other hardware specs for emulator development

Question

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?

Answer 1

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!

Answer 2

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:

• Writing a graphical Z80 emulator in C or C++

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...