If all else fails, scoping the cartridge port's outputs might offer some insight on logic levels.


Well, I am ex-Navy.

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

If all else fails, sure -- it might turn up something unforseen. But it won't tell us whether that 16550 accepts TTL voltage levels. OTOH the datasheet will tell us; that's what I tried to say earlier and didn't do a good job.

I looked at one manufacturer's DS and their 16550 does accept TTL levels. Maybe the chip in srowe's project is different in that respect, but we don't know -- he didn't mention what brand his is. (Hint.)


Is that why in that thread last week you were trying to convince us that during VPA=VDA=0 those '816 control signals were FLOATING ? <groan>

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

Sorry, that is a major omission. I'm using a Nat Semi PC16550DN. I've also been referring to the TI datasheet which might be a mistake, I'll get the proper one.

Well, nothing I tried last night seemed to improve matters. I think I'll tear down the board and rebuild it with the minimum to be able to read and write to the registers. Until that works there's not much point with the other parts of the circuit.

I'm still unclear about how to acquire the CS and RD & WR signals properly. When tying /ADS low it looks like the chip wants the RD & WR signals only to be valid when Φ2 is high but the CS must be valid past the point Φ2 goes low. I'll try again to work out the correct logic myself but are there any other schematics I can look at that interface chips with demultiplexed RD & WR to a 6502?

My rebuild behaves exactly the same. I'm still convinced that there's something wrong with the read operation. Here's the timing diagram from the datasheet



The /RD signal is only low when R/W and Φ2 are high, CS0 is also high with Φ2. I think I need some way of stretching CS out.

I've also attached the complete source of my test harness.

I think you have a timing problem. The select signals and address signals must be stable before RD or WR is asserted. In fact the 16C550 expects select signals and address signals to be stable at least 60ns before an active RD or WR signal. I suppose ADS is tied to GND in your case, so they must be stable throughout the complete cycle. RD and WR must be gated with PHI2 but the select and address signals must not be gated with PHI2 and must be generated as fast as possible i.e. only combinatorial logic from the address bits and if you like VDA and/or VPA of you want to hook a 16C550 to a 6502 bus. You can think of the select signals (CS0..2) as some special address bits that must have the correct value for the chip to be addressed.

Hmm, the select is taken from the VIC-20 expansion port. Does the VIC internally gate that signal with PHI2 before it's sent out on the port? I'd expect not, but that assumption is definitely worth checking. srowe, what are you using as a reference for the VIC-20 signals?

Here's the Nat Semi datasheet, btw. It does accept TTL levels.

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

I think the problem is that the VIC-20 gates the address lines on to the expansion bus only when Φ2 = 0. Because the 6502 shares the bus with the VIC there is a pair of 75LS245s that arbitrate access to memory between the two.

I'll have to see if I can work out how to latch the address bus correctly using /ADS.

Or slap a couple of inverters on phi2 leading to the RD/WR logic to get some delay in there so that the address lines to the UART can settle?

Latching /ADS from /IO2 and Φ2 ORed together gives me reliable register reads. I'll wire up the Maxim chip and retest Tx and Rx.

So both Tx and Rx now work as expected.

One final question, my clock comes from an 18.432 MHz crystal and a pair of 22pF capacitors. Some clock circuits I've seen have a series and parallel resistor as well. Why are there different layouts and how do you choose which to use?

One little suggestion for the future. Take a look at the NXP UARTs, specifically the 26C92 and 28L92. They are easier to interface to 65xx hardware, plus they offer two channels for the price of one chip. The 16550 and derivatives are old, old technology.


Garth may be able to answer that for you. Also in the future, consider using a TTL can oscillator instead of a roll-you-own oscillator circuit. The cost difference is trivial and you don't have to use extra components.

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

Thanks for the pointer. The 16550 may well be old but it's positively bleeding edge compared with the VIC.



I was (and still am) rather ignorant about clocks. I used a plain oscillator when I built an Atmega board so assumed the same setup was good in this case.

The resistor is to give the input the DC bias it needs to get in a somewhat linear region so it'll work right. Regarding the capacitors and other things, the crystal may be cut for getting the desired frequency in a series-resonant mode or a parallel-resonant mode, giving a slightly different frequency for each mode, and also be made for a certain load capacitance. I, too, would recommend the oscillator can. The following is from the clock generation page of the 6502 primer:

There are lots of ap notes and articles on the web about making crystal oscillators (and there's the circuit above), but the most productive path is to just use one of the off-the-shelf oscillator cans that take the space of an 8- or 14-pin DIP and require no external parts, so they take less board space. Going this route will make sure the oscillator will always work correctly for the entire voltage and temperature range, and it's easy to change. The whole oscillator doesn't cost much more than a lone crystal. Here's an enlarged picture of one that fits in an 8-pin IC socket:

Good oscillator design is rather math-intensive (S-plane anyone?). You might get one going but find out months later when the weather heats up that it doesn't want to work anymore; or you might not have the crystal resonating in the right mode, evidenced by the frequency proving to not be what you thought. If you use the can, the details of making an oscillator that's stable and dependable under all conditions have already been figured out for you. If you're attracted to the fun of making your own, look at it this way: plugging in an oscillator can leaves you more time to work on other parts to make your computer do more.

If you still insist on making a crystal oscillator yourself, a couple of Fairchild ap notes I might recommend are:
HCMOS crystal oscillators (.pdf)
CMOS oscillators (.pdf)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

OK, so I'm liable to end up with a clock that's unstable and may be off from the expected frequency. I think this isn't too much of an issue in this circuit? Because this is async I only need to have 10 or so cycles to clock in each single byte. Certainly there seems to be scope to handle some error. I believe there's a misprint in the 16550 datasheet for the divisor for 1200 baud (the rate I was testing with), it reads '920' but dividing the 2400 baud divisor by two gives 960. That's an error of 4%. Both work on the short test runs I've done.

This seemingly simple project has turned into quite a learning exercise. Thanks for your help.

Well, not really. The 16550 is a descendant of the old 8250 UART, which dates back to the days of the Intel 8088. That was around the time of the VIC-20's release. The 16550 could be thought of as an 8250 with more lockwashers and thicker paint, to use an automotive analogy. In fact, other than the availability of FIFOs, it is an 8250 for all intents and purposes.

The NXP (Philips) UARTs are "clean sheet" designs that addressed issues with the 8250 and derivatives. NXP retained the Intel bus interface but everything inside was new. The NXP 28L92 I am currently using in POC V1.1 can be configured for either an Intel or Motorola bus interface. Ironically, the Intel interface proved to be less a hassle to adapt to the 65C816. POC V2 will be using the NXP 28C94, which has four independent channels. It helps that NXP decided to use an active-low interrupt output, which can directly drive IRQB on the 65C816.


I quit using discrete crystals in clock circuits many years ago. Can oscillators are far more convenient and as Garth noted, dependable under a wide variety of operating conditions.


Actually, it would be an issue, as the whole TIA-232 model depends on strict timing between bits (or more correctly, marks and spaces). If the transmitter clock is too fast or too slow relative to the receiver clock, the arrival of marks and spaces at the receiver will not coincide with receiver timing, causing intractable errors. In the case of the 16550 you are using, your baud rate clock should be either 1.8432 MHz or 18.432 MHz. The former is what I would recommend, as it will give you all of the standard speeds up to and including 38,400.

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