I'm trying to hook up a UART to my VIC-20 and while I have transmit working perfectly receive seems to be misbehaving. Depending on the character received I either get a single (correct) character or a repeated stream of junk. A specific character always results in the same output, baud rate doesn't affect this.

I've based my breadboard layout on Andre's circuit http://www.6502.org/users/andre/csa/duart/index.html. My first suspect is the clock is unreliable but surely that would affect transmit as well? I'm trying to use the FIFOs in a poll mode (not interrupts) so I could be misunderstanding how the Line Status register works.

Any suggestions to narrow down the cause?

Your problem sounds software-related. I'm not familiar with the 16550 to the extent André is, but I think there is a status bit you need to check before reading the receive FIFO to determine if in fact it has a datum ready. Otherwise, you may be getting garbage left over from previous reception.

This being a VIC-20 and having TTL hardware, as well as the NOMS 6502, there's a slight chance that the hardware interface isn't pristine. You don't indicate how you are selecting the UART, so I can't comment anymore on that. Can you post a schematic and your timing analysis?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Here's the schematic, I've created it quickly from my rough notes.



I think there's a problem with timing during reads, if I write to the scratch register then read the value back I get sporadic mismatches. I'll look over the datasheet tonight and see if I can spot anything amiss.

I'm not convinced about hooking the CS to Φ2 or putting the address decode into the 138 enable.

The schematic has them the other way around.



I'm going to give that a try.

Can you post that in black and white? There obviously are lines in a color (blue) that I can't see.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That looks like a reasonable interface. It ought to work.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

How's this?

My quick hack using the 138 in place of the NAND gates didn't seem to improve matters. I still think this is the root cause though. Bit tired now so I'll stare at the timing diagrams tomorrow.

Yup. Besides, haven't you already tested whether you can successfully write and read the registers on the 16550A chip? If you can then your interface is OK. (I guess you know that reading an address that you've just written won't necessarily return the same data, because sometimes reads and writes access different registers. But address 0x01 is one of the ones that's good to test. Reads and writes of 0x01 both access the Interrupt Enable Register.)

Have you tried sending it just one character at a time, followed by lots of delay so your software running on VIC-20 has lots of time to do the poll then get the incoming character before another arrives? If that experiment is successful then next you can progress to short bursts of characters with no intervening delay. (I mean bursts short enough for the FIFO to contain.) If this is where things go sideways, then check that the FIFO's been enabled and that your poll is looking at the right bits.

HTH -- I've only recently started fooling around with 16550 (an SPI equivalent, actually) myself.

-- Jeff

http://anycpu.org/forum/viewtopic.php?f=16&t=271

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

I've been using the Scratch register for this (0x7). I think my read demultiplexing is wrong as I get occasional mismatches between what I write and what I read.



This is what isn't working. To test receive I'm using a conserver client and typing single keystrokes. On the VIC I've got a loop checking the LSR and then reading the receive FIFO and printing.



In the failure case I get a continuous (or large burst) of incorrect output for a single character. That implies to me that the LSR read is erroneously returning Data Ready = 1.

Or, when you attempt to read the LSR you're actually reading something else. If so, maybe "UARTBASE+LSREG" doesn't return the right value. You don't show the part of your code where those are defined. (The part you did show looks fine.) But a more likely explanation is that address lines A2, A1 and A0 have gotten shuffled around when the circuit was built.

Besides address lines, it's also worth checking that the data lines don't have any wires crossed. A good way to check is by having the VIC-20 transmit (you said transmit seems to work) 0x01, 0x02, 0x04, 0x08, 0x10 etc to see if they arrive intact at the other end. This is a better test than eyeballing the schematic and doc (which conceivably may have a typo).

This too could perhaps be the result of accessing a different register than intended (since, as noted, most have split personalities for read and write). I admit this part sounds unlikely. Instead might there be a flaky (intermittent) connection somewhere?

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

I'll check this when I get home but I would expect send not to work if this was the case. The initial setup of the UART needs to set the Divisor Access Latch, set the clock divisor, clear the latch and set number of bits etc. If either the address or data lines were transposed the wrong divisor would be used and I'd be receiving garbage on the console.



That's quite possible, it's a sizeable circuit for my limited skills. I'll go over the board with a meter again.

It depends on the values. Sometimes you get unlucky, and something that shouldn't work does!

True -- I agree this makes the transposed-wire theory less likely. But it still depends on the values. Have fun, good luck, and keep us posted.

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

BTW, have you considered the effects of attaching a CMOS device (the 16550) to the cartridge port of the VIC-20 in terms of logic levels? The VIC is all TTL and maybe the logic levels at the cartridge port are not quite in the CMOS wheelhouse.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Good call. A logic-level problem can give flaky results just as an intermittent connection can. (One can be checked via the datasheet; the other will often be revealed by some exploratory rapping on the board.)

"Wheelhouse"??

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