Off the shelf: RESET pickup again, and a UART that reads ones as zeros

I took DINO back off the shelf. PROG_isa still reads 0xB4 and PROG_isasoak still reads 0x00, the monitor loads hello and runs it, and bigxfer (2233 bytes in through the monitor’s L command) fails within the first few rows. That’s about where I left it. The plan for coming back was interrupts. They’re designed and the chips are sitting on the bench, but nothing got built tonight, because I spent the night on the serial problem instead. By the end of it there were two separate faults on the table. One is fixed and one isn’t, and it feels close enough that I’m going to keep chasing it before I start on interrupts.

The interrupt plan got simpler, but nothing’s built

Before touching the bench I went back over the interrupt plan. It was split into three build stages that never made sense to me, and none of them depended on the others, so it’s one build now. I didn’t have a ‘32 for the four OR gates. I found a 74F32, so that’s what goes in, with a note on what to swap if an F-series edge ever causes trouble.

The bigger change is the test source. The plan had a pushbutton on ~IRQ, and a 555 at about 1 kHz for the flags test. Both are gone. The 16550’s transmit-empty interrupt does the job, and each test image arms it itself: write a byte or four into the XMIT FIFO, set IER bit 1, and INTR rises when the FIFO drains. Every run is repeatable, nothing bounces, and the ‘05 open-collector gate on the serial card is now required instead of optional. None of it is built or burned yet. The ICs are on the bench waiting.

I half expected interrupts to fix the serial problem below. They won’t. An interrupt changes when RBR gets read, and the bad bytes turned out to be wrong in RBR itself.

The UART was being hardware-reset mid-load

Every so often the load died with the monitor echoing 0xFF and then only garbage (ba 1d) when the loader tried to get a prompt back. I sent one A (0x41) at it afterwards and got a1 ff back. That’s what 8N1 at the host sees when the 16550 is sending 5-bit characters. The low 5 bits of A, then the UART’s stop bit, then the start bit and first data bit of the ? that follows. So LCR had gone to 0x00.

LCR gets to 0x00 two ways, a master reset or a stray write, so I set a witness. W 4804,0C sets OUT1 and OUT2 in MCR, which pulls pin 34 low. A reset clears MCR and a stray write to LCR doesn’t touch it.

That was a master reset. The scope, triggered on a rising edge at 1.6 V (the idle hash on that net reaches about 1.2 V), caught it:

The pulse is only a few ns wide and it’s on U75.8 before it’s at the card. U75 is a ‘32 whose third gate just passes RESET through to RESET_B, so either the gate was making it or it was coming in on RESET. A probe on U75.9, the input, made the fault go away. I took that probe off and it came straight back.

This is the same fault as 09-06. That time pulling the RESET wire out of the bundle fixed it. This time the wire was already flying over everything, nowhere near a bundle, and still picking something up. I twisted a ground wire around the whole run, grounded at both ends. Two loads after that went past 0x8300 with no runt on the scope and no 5-bit failure. Two runs isn’t a soak.

If your 16550 suddenly talks 5-bit garbage at random and you never wrote LCR, set MCR bits and see if they survive. If they don’t, something is pulsing MR.

One thing about it I can’t explain yet. Every reset landed at byte 25 of one of the loader’s 32-byte rows: 0x8119, 0x8139 four times, 0x81B9 and 0x82B9. The monitor has no idea the host sends in rows, so whatever couples into RESET is probably timed from the host side.

The other fault: ones read back as zeros

The second fault was there the whole time underneath the first. The monitor echoes each character it reads, and some come back wrong.

Bits only ever go from 1 to 0, in no fixed position. Here’s what it isn’t, as far as I’ve got:

• CPU timing. It fails the same at 500 kHz as at 1.024 MHz.
• A glitch on SIN. A negative-pulse trigger under 40 µs at 2.5 V on U103.10 never fired during failing loads.
• The receive clock. RCLK on U103.9 is a clean 153.6 kHz, 543 ns low per period, and a trigger for short lows never fired.
• The read path. I wrote 0xFF to the 16550’s scratch register and read it back 300 times through the monitor. 294 parsed and every one was 0xFF. 0xFF is the value contention would show up in first, since on LS the low side wins a fight.

So the byte is already wrong in RBR, or the bits arrive on SIN as whole wrong bits, which a short-glitch trigger can’t see.

Along the way I found the card’s ~RD wired to U75.12 instead of U75.11, one hole off, the same slip as the ~WR wire on 09-04. Pin 12 is the gate’s input, the ~IO_RD strobe before it’s qualified with CLK. On the scope the read strobe at the UART was 933 ns wide, a whole T-state, with extra 30-40 ns lows around it that could count as reads. I moved it to U75.11 where the drawing has it. It didn’t change the ones-to-zeros fault at all.

Still open

• Ones-to-zeros on received bytes. Next is to capture SIN for the exact character that fails and decode the bits, to split “arrived wrong” from “sampled wrong”.
• Why the RESET pickup lines up with byte 25 of the loader’s rows.
• The ground wrap needs more than two runs before I call RESET done.
• About ±1 V of fast hash on every net I probed. Some of that is probably the probe’s ground lead, and I don’t have ground springs.
• Interrupts, once the serial problem is settled. The design is done and the ICs are on the bench, but nothing is built and the new microcode isn’t burned.