Had another bash at it today.

I have determined that the DLL and DLM registers (which are where the baud rate is set) are never being read or written. Further, the bit responsible for allowing access to these registers (Bit 7 of LCR) seems to be stuck high. Which doesn't make sense, as if it were stuck high I would be able to write to the DLL / DLM registers (and, more importantly, not the THR register responsible for transmitting data, which I know to be working correctly).

This is very puzzling. I cannot seem to modify the relevant bit, but the bit itself constantly says I am in DLL/DLM mode, even though observed behaviour says I'm not.

Unfortunately the new chip was a non-starter as I apparently ordered the wrong package. I shall have to place another order, which hopefully won't take 6 months again...

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

When you suggest it's "stuck high," do you mean the UART pin actually drives d7 of the CPU data bus high when LCR is read? Certainly that could be true, and maybe this is something you already checked. Anyway, I'm wondering whether perhaps the pin is actually floating (high impedance) when LCR is read. (Indeed, maybe it's floating when any of the UART's registers is read). But even a floating line on the CPU data bus will read as high (or low) if that's the previous state to which it was driven. (Capacitance at work. ) And this could be misleading.

d7 of the CPU data bus could be floating due to a failed bond wire inside the UART chip... or due to a bad connection externally between the UART and the CPU. Measuring from the CPU end, I suggest you somehow verify that actual current is delivered. You could attach a pulldown resistor at the CPU end and use a scope to watch the voltage on the pulldown when LCR gets read. Or, stop the CPU clock (or pull RDY low) when LCR gets read; then just use a VOM or DMM from the CPU's d7 to ground to verify actual current flow.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hmm. The address of the LCR register is $C403. That means the relevant LDA would come by the CPU as $AD $03 $C4... followed by the read. $C4 has bit 7 high, so that would be the most recent state of the bus before the read. Could be on to something there. I have checked continuity between the UART and the CPU, but obviously I cannot check the internal bond wires. This failure would not immediately manifest itself in any other terrible manner, since there's no other Bit 7 that I need to read or write for standard operation - with one exception, that being the actual transmit and receive registers. Transmission is happening correctly (albiet at the wrong baud rate), though I have never tried to transmit a character with bit 7 set. However, now you mention it, I recall the received characters all having their MSb set as well (it didn't jump at me at the time because I had it reporting them in Hex). The read operation again will have $C4 on the bus just before, so that bit will already have been high.

I think an easy method of testing it would be to try reading and writing from the Scratchpad Register (SPR) on the UART. It serves no function other than being a spare byte of RAM, and I can read and write arbitrary values. If I find that one's Bit 7 is "stuck" too, then that's strong circumstancial evidence.

All this would also explain why I can never get access to the divisor latches - the high bit on D7 is never actually getting through the busted bond wire to the chip internals, and by pure coincidence the floating internal input has been read as zero.

If all this bears true then it is, as I have long suspected, a busted chip in need of replacement. Woe is me for not having the right size of replacements

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Hmm, okay. Still not proof, but it certainly supports the theory.

Good idea!

Is the chip socketed? The continuity check needs to be from the actual UART pin (not from a socket that accommodates the pin). Just a reminder! Sometimes an IC pin gets curled up underneath instead of inserting properly in the socket. It's a fault that's very hard to see. Lotsa folks have had this happen -- you wouldn't be the first.
Edit: I notice GaBuZoMeu already mentioned this possibility.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

No, its a horrible tiny SMD part. Literally needed a microscope to put it on. However I did the continuity tests from the raised metal part of the pins, not from the pads, so it should be good. We also double-checked that they all look properly soldered under the microscope.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

What about reading and writing from the Scratchpad Register? Did you try that?

As a matter of curiosity, I'd be interested in whether we can confirm that data line d7 *is* indeed floating (rather than stuck).

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

No, not yet. I will do, but the thing takes a while to setup for testing and I did not have a lot of lab time today, and what little I did was spent on something else (been modding a zx spectrum). I have however ordered the correct replacement UART, from a different supplier. They'll be useful to have even if it turns out not to be a defective part.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Yup, C4 means bit7 high, so that'll be the most recent state. Were you gonna try flipping that bit -- I mean arranging for a value other than C4 to appear at that time?

If you notice the bit then reads as if stuck low then I'd say that confirms an open circuit. And you tested continuity right to the metal of the pin itself, so the fault would have to be internal.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Still results in $C3 being the last byte on the bus before the read, unless I'm missing something

I don't think any of the LDA instructions will give us what we want, as they'll all ultimately result in $Cx being read before the register.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Oops. You're not missing anything. I had a little brain fart and modified bit7 of the second-last program byte before the read rather than the last .

Right. Theoretically speaking, if you were willing to map the UART to an address in zero-page then you could avoid $Cx being the last byte on the bus before the read. But I'm not seriously proposing that.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Try connecting a resistor (maybe around 1KOhms) from bus D7 to ground. This should cause D7 to float down to ground when it isn't driven. Verify this is working by reading an address >=$8000 that doesn't enable anything - D7 should read low.
Then try reading the UART again & see what D7 reads as.

Replaced the UART. Problem solved.

On removing the old one, discovered that the soldering on the D7 pin was.... not great. It is possible that it was only making a connection when I had my tester probes on it, due to the pressure, but otherwise had a bad connection. So... could be a hardware fault in the chip, could be bad soldering on that pad. Either way, its working now.

Finally.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.