GIDE for the P112
I built a simplified version of the GIDE interface for use with the P112. The modified design fits nicely in two 16V8 PAL chips (the original requires a 16V8 and a 20V8). The support for the 72421 chip was removed, since the P112 already has a RTC chip. I can also live without the address selector switch: the GIDE I/O base address was fixed to 50h, which is what the ROM monitor uses. If I ever need to change the I/O address I would just reprogram the PAL. The resulting PCB board is also smaller. The board was designed to be plugged directly into the P112 expansion socket.
After using the GIDE interface for a while, I noticed sector data corruption from time to time. It seemed to happen only during write operations: an extra byte was sporadically being inserted into the data stream and written to the disk sector, all the remaining bytes ending shifted. Very annoying when it happened to a directory block. The bug made the interface practically useless, since I could never be sure about the integrity of the files copied to the hard disk.
The problem only happened when the OTIR command was used to write the data. The GIDE test programs, in the other hand, use the IN instruction, with plenty of time between accesses so the test procedures always passed. Adding extra I/O wait states did not help at all. Both CP/M and UZI were affected, so it was not a software issue. Sometimes a day would go without experiencing (or, well, noticing) any data corruption, then at the next reboot I would get immediately a corrupted directory listing.
Hooked a scope, checked the power supply lines: clean, no glitches; clock signals: fine. Added more power supply filtering just in case: no help. Checked the PAL design over and over: everything was fine. Changed the hard disk cable: nope. Changed the disk: same thing. Checked with a digital storage scope the signals: could not catch the glitch that was making the PAL flip-flop to flip at the wrong moment. The only suspicious signals were the hard disk lines at the IDE connector: the power lines looked clean, but the data and control lines showed the noise spikes, overshots and undershots distortions typical of data transmission cables.
What seemed to be happening is that the overshots were causing somehow the PAL flip-flop to switch at the wrong moment. There must have been some small amount of ground-bouncing or cross-talk happening inside the PAL chip between the output IOWR line and the flip-flop circuitry.
The cure? A simple resistor, inserted in series with the IOWR line, of value somewhere between 100 Ohms and 1K Ohm. Lowered the Q, removed the glitches and cured the problem forever. The resistor is not shown in the schematics, neither is included in the PCB layout, so if you experience the same problems you'll have to cut by hand the printed board trace that runs between pin 16 of U1 and pin 23 of JP2 and solder the resistor between those two pins.
In my implementation I used 16V8 GALs from Atmel. Apparently these chips are not designed to drive a load like an IDE cable+disk, at least regarding noise levels. PAL chips from other manufacturers may not show the effect.
Last updated: 4-Feb-2006