I agree, it's so much easier when you can read up on what something is supposed to do. Reverse engineering is much slower.
For cps1 you'll need the z80, 68000, ym2151 & oki6295 manuals ( Although _nobody_ writes their own cores for these nowadays ). If we had the internal code from the qsound chip then you'd need a dsp core for that ( can't remember which off the top of my head ). Otherwise you'll need the docs that were going around for a while ( or MAME, again nobody bothers to write another qsound.c ).
That leaves the graphics, I'm sure the guy that used to do demos for arcade hardware did a cps1 version. There are probably a few interrupt issues you'll have to play around with.
I really don't see the point in spending lots of time documenting things, which are either documented already or can be trivially derived from the source. The whole point is to make MAME the documentation, it's the only thing that can be verified as working. A large text file that describes the hardware is likely to be wrong and missing anything complex.
If you can get documentation from the manufacturers then good luck. In alot of cases we don't understand quite what the hardware is doing either, which is why writing games using MAME as a test bed can cause frustration when you run it on the real thing.