Let's have a look at the most difficult part of the documentation process: the dumping!
I usually go through a 3 steps path:
2)Actually dumping them
3)Checking what I've done
On a standard PCB we will find one, more or even all of the following components: CPUs, TTLs, ROMs, RAMs, PLDs, Others.
I use coloured water-markers (of the kind used to write on CDs) to mark each single component when it is correctly identified: green is for CPUs, blue for TTLs, gold for ROMs, purple for RAMs, silver for PLDs. This colour marking system is of great help when working on PCBs, it gives an immediate visual overview of what is what, it avoids missing out something important to dump, it saves a lot of time because I do not have to re-identify components when I look at a PCB after some time.
First thing we have to find the main CPU (maybe there are more than one!); it's usually the only chip whose size is remarkably different from all the others. We have to remember that 6502, Z80 and 68000 are the most used CPUs in arcade game history, learning by heart what they look like is fundamental. Obviously each chip sports some writing (markings), and looking that up on the Internet is always a good way to confirm what a chip is. For CPUs identification I would recommend CPU-World as a reference.
Sound CPUs are usually found grouped together, close to the volume trimmer. Most common sound CPUs are M6295 (and clones) and all of the various YMxxxx.
On some PCBs we will also find MCUs; they are like CPUs, but with an internal memory which is unfortunately read-protected 99% of the times.
On some PCBs there will also be “support chips” like I/O chips, CRC controllers or Peripheral Interface Adapter; let's mark all of them green as well.
Second thing let's rule out all of the TTLs; they are easy to identify, because they are small (300mil) and marked 74xxx (in very old PCBs they can also be 54xxx), let's mark them blue. TTLs are usually the most common component, ranging from some tens to some hundreds of them on a single PCB. They are pure logical operators and are of very scarce interest for the dumper, apart from a few remarkable exceptions: 74s188, 287, 288, 370, 387, 471, 472, 473, 474, 570, 571, 572, 573. These are all PROMs, they have to be marked gold and are addressed here following.
Third thing is to correctly identify and colour mark ROMs. They come in a variety of forms: PROMs, EPROMs, EEPROMs, FlashROMs, MaskROMs. The most common are EPROMs, they sport a transparent window, they are 600mil, ranging from DIP24 to DIP42. In most PCBs they are socketed, and their extraction is very easy using a small flat screwdriver and slowly lifting them with small movements from BOTH sides to avoid any pin bending. MaskROMs are of the same size as EPROMs, but without the window, and very often they are soldered through the PCB. Removing them is a little bit more complicated, and the best suggestions for it can be found at Guru's site. EEPROMs and FlashROMs have different sizes, are usually SMD, and special adaptors are required to insert them into your programmer; adaptors could be rather expensive. Finally PROMs are small chips (300mil) usually soldered through and quite similar to TTLs, therefore learning by heart their specific markings and labels comes handy in many cases. A good reference is available here.
Fourth thing are RAMs, they come in many sizes, from long 300mil to thin 600mil to other (less common) sizes. Mark them out, because you will need to mention them in the documentation.
Fifth thing is to find out if any PLD is on your PCB. To understand what a PLD is, please refer to this very good article on wikipedia. PLDs always incorporate a “read protect” feature, in 95% of the case it's activated by the producer; until recently it was impossible to read them, a dumper simply gave them a try hoping to be lucky and get into the 5% which is not protected. Recently Charles McDonald found a way to read also a certain category of PLDs (the most common on arcade PCBs), so the above situation is changing.
Sixth and last thing is to identify all other components of the PCB. You will find resistors, trimmers, LEDs, audio parts, heat exchangers, connectors, jumpers, switches and a lot of other things. You will need to describe them in the documentation as well.
Dumping memory chips is the core part of the whole dumping process. It basically requires an EPROM programmer, a PC and some dedication. I'm not going into describing various EPROM programmers, their pros and cons, what they can do and the like. There are too many of them, let's assume that you know how your EPROM programmer works.
Before inserting chips into the programmer's socket you have to check for all the legs to be clean and straight. If any rust or dirt is on the legs, use a piece of very fine sand-paper to clean them, on all sides (internal, external and in-between legs). If legs are bent use a small plier (or your fingers) to straight them back; be very gentle and use a very minimum of force, it's easy to break them.
Then insert your chip into the programmer, configure your software accordingly to the make/model of the chip you have inserted, read it and save the result in a safe place. Now comes the very important part: remove the chip, clean the cache of the software, insert back the chip and read it again. Then do all of this a third time. Only if the three reads are IDENTICAL (check it with crc32) then you have a good dump. If there is any difference, start again from the cleaning part of the procedure. Sometimes, even after perfectly cleaning and polishing all the legs, you can not get a constant read of a chip. In this case try to read it with a slightly different voltage/current if your reader supports such a feature; firstly try with ±5%, eventually with ±10%. Do not go beyond ±10%, you will risk to ruin both the chip (not so important) and your programmer (much more important)! Some modern readers automatically perform the three reads procedure, and the reads are also made with different voltage/current parameters; it's an incredible speed up of the whole process. Do not forget to save all resulting files with a sensible name, possibly following the standard convention for roms naming: label.position (e.g.: vb401.u14 ); if label is missing, number them yourself; if position is missing, skip it.
Checking the dump