Debugging stuck bits

I’ve been blocked on making progress on the retro pc project due to bad reads from the ROM. The seemingly simple snippet of boot code should light an led wired to to the i/o ports (any port).

section .text
resb 0x7F0
org 0x7F0

mov al, 0x1


out 0x10, al
jmp again

When assembled, this turns into the following x86 bits:

00007f0: b0 01 e6 10 eb fc

Unfortunately, when I tried to boot the bundle of wires on the breadboard, I got the following while looking at AD[0:7] on the 8088.

00007f0: b0 01 e2 10 ...

Hmm… that isn’t going to work very well at all. Looking at this more closely, bit 2 (the third bit) is zero when it should be one. What could be causing this bit to be zero instead of one?

  1. It’s possible that the bits in the ROM are simply incorrect and the circuit is reading what is there. If that is the case the fix is easy, burn a new EPROM.
  2. Since this is the low 8 bits of address lines, it is multiplexed with the 8-bits of data. To demultiplex the address and data lines, a 74LS245 is used to control the direction of these 8 lines. It is possible that the ‘245 is driving the troublesome bit to zero even when it should be passing data from the ROM (or RAM) to the 8088. If this is the case, the ‘245 is likely bad.
  3. The RAM and ROM are both connected to the ‘245 and some glue logic to ensure only the RAM or ROM is enabled at any given moment. If the glue logic is wrong, both could be driving the ‘245 at the same time which would be bad.
  4. Finally, there is an 8-bit latch attached to the ‘245 to hold the data written to any 8088 i/o port whose bit 0 is connected to an led. Since this is used as output only, it is bad wiring if this is driving the ‘245.

Debugging the stuck bit is a matter of incrementally testing the potential issues above. Testing the values in the EPROM was easy, I just plopped the EPROM in the USB programmer, read the bits back out and dumped them. They all looked correct.

Testing a bad ‘245 was easiest by replacing it with a different one since I had plenty of backups. I tried two different replacements which behaved similar to the first. Seems likely that it would be a circuit problem not something wrong with the chip itself.

Next, I decided to verify the EPROM was working properly in-circuit by disconnecting the wire connecting the EPROM D2 bit to the ‘245 and monitored the 8-bit outputs of the EPROM. The value read as expected (E6 was E6, not E2). While the EPROM was disconnected, I used another channel of the LogicPort to monitor the B3 (pin 16) of the ‘245 to validate the fact that it was continually driven low — this would confirm that the EPROM was not the issue. Yup pin 16 was stuck low.

So someone else connected to pin 16 of the ‘245 must be driving it low. I disconnected the RAM’s output data bit 2 at the ‘245 and repeated the test. Still driven low. Wha? That implies that the 8-bit output port is driving the ‘245 low? That would be odd. I followed pin 16 to the output port latch … and it was connected to the bit 2 output (Q2) instead of the bit 2 input. Whoops.

The funny thing is that the first thing I did when I saw the “E2” value is that I double and triple checked all of the connections between the 8088, ‘245, ‘373 address latches, memory glue logic, RAM, and EPROM. I ignored the ‘output port’ many times in the process.

In the end, I managed to get a good boot sequence and I feel pretty confident that the breadboard 8088 is running!

x86 boot sequence that lights an led.  You can see the code coming from the ROM and the write to the IO port in the sequence.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s