@BigDumbDinosaur

Thanks for a very detailed and easy to understand explanation! I've read about that bug for a while but I admit I never fully understood it. The only reason I have a 65C51 is because I thought that's what most SBC builders were using. All I really want for my SBC is a serial port. I just used the Apple as a development platform for testing the '51 because I thought it would be fun.

But it sounds like I may not want to go down that avenue. The only "vintage" IC's that are a *MUST* for my SBC is a 65C02 (and later a 65C816) and a 65C22. The rest is just glue logic and I/O as far as I'm concerned.

I hadn't planned on going PLCC-44 at the moment but I'm not against it. I think my old eyes could still solder sockets that size so I could use the NXP chips, perhaps. Then, of course, if I went PLCC-44 for that chip I might as well for the CPU and VIA too.

Anyway, do you recommend I try my design with the NXP instead of the '51?

The purpose of my SBC is mainly learning. But I need a simple way to interact with it while I'm learning. But it sounds like the '51 has too many issues that I have to kludge.

Thanks!

_________________
Cat; the other white meat.

The 68B50 is pretty simple.. and used in several projects (cheap too, on ebay at least).

I have a Zilog part I want to test on a breadboard with a 65c02, somewhen when I get the time. When that time becomes available I'm not so sure about though.

I was hoping to only use still manufactured parts with the exception of the AY-3-8910 and maybe the TMS 9918.

_________________
Cat; the other white meat.

I don't have any WDC 65c51's, but with the other brands I've used, I have never had any problem with them (except when I failed to put the recommended capacitor on the XTAL input pin). My software for them has always worked right on first try. The only minor complaint I have is that a couple of the functions should have been given each its own bit in the command register instead of put on the same bit. I suppose the designers didn't want to add another register to get the extra bit.

A major problem with the 6850 IMO is that it does not have an internal baud-rate generator. Major, major deficiency!

I plan to use the MAX3100 in the future though. I've exercised it in the past but have not really put it to actual service yet. You talk to it through SPI or Microwire, but I'll have SPI for plenty of other things anyway. It's available in a 14-pin DIP (so it takes less board space), can work at 2.7V to 5.5V, and is IrDA-capable. It does not have DSR, DTR, or DCD, but those are usually for modems anyway, and if you want them, you could put them on VIA bits. Outside of that, the MAX3100 has 8-byte buffers and higher speeds (300bps to 230kbps, software-controlled). The MAX3110 is the same thing plus onboard line drivers and receivers.

_________________
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?

My thinking when I designed the POC units was the same.


POC V2 has three PLCC-44 devices and one PLCC-52 device, all in sockets. PLCC socket pins are laid out in a .100 × .100 inch grid, which simplifies connection to the board. I wouldn't think you'd have any trouble soldering a PLCC-44 socket to a PCB. There are PLCC-44 wire-wrap sockets available if you are going the wire-wrap route.


That's up to you. The hardware interface is a little more involved than with the 65C51, mainly because the NXP UARTs have no understanding of the 65xx bus. The UARTs I've used to date, the 26C92, 28L92 and 28C94 can operate with either an Intel x86 bus or a Motorola 68K bus. In POC V1.1 and POC V2, the UART is set up to operate in x86 mode, as I found that mode was actually simpler to adapt to the 65C816.

Summarized, the key interface differences for the two modes are:

• In 68K mode, a single pin acts as the read/write strobe, same as on the 65C51. In x86 mode, there is an active-low read strobe and an active-low write strobe, similar to the /OE and /WE inputs found on many SRAMs.
  
  
• In 68K mode, the UART's reset input is active low and can be directly connected to the MPU's reset line. In x86 mode, the reset input is active high and requires that the MPU's reset line be inverted.
  
  
• In 68K mode, general purpose input number 6 (GPI6) acts as "interrupt acknowledge." In x86 mode, GPI6 is a general purpose input.

In adapting the UART to the 65C02, either 68K or x86 mode can be used, and I'm inclined to think that 68K mode would be a little more economical with the glue logic. The UART, of course, doesn't know anything about how the 65C02 operates, which means some simple glue logic is required to condition the MPU's RWB output. If operating the UART in 68K mode the read/write logic is very simple:


In the above circuit, R/W can never go low if Ø2 is low, which prevents the UART from being written during the part of the bus cycle when D0-D7 may not be stable. The above circuit will also work with the 65C816, but will result in bus contention during Ø2 low of a read cycle, as that is when the '816 will be driving D0-D7 with the bank bits. A bus transceiver gated by Ø2 would have to be used to isolate the UART from the '816 during Ø2 low to fix this problem.

The alternative is to operate the UART in x86 mode and use a read/write circuit such as the following:


With the above circuit, there is no need for a bus transceiver, as /RD will not go low unless Ø2 is high, thus preventing bus contention. The circuit also takes care of qualifying writes with Ø2.


Aside from the stuck TxD ready bit, the 65C51 represents the state of the art in 1976. UARTs have greatly advanced since those days.

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

It's also pretty lame. As Garth noted, the 6850 and 68B50 don't have an on-chip baud rate generator, which is very inconvenient. Furthermore, the 68B50 has slow bus timings, limiting its use to low Ø2 rates, unless one is prepared to generate multiple wait-states when talking to the UART. Other than supporting a 38.4Kbps data rate and not having a stuck TxD status bit, the 68B50 is in the same league as the 65C51 . As I earlier noted, UARTs have greatly advanced since the 1970s, which is where the 68B50 and 65C51 are both stuck.


True enough, although the non-WDC versions have the slow bus timing characteristics typical of the 1970s. If WDC were to fix their 65C51 it would be viable in a modern 65xx implementation, although the lack of FIFOs would produce an interrupt storm during CBAT at high data rates.


This has always been my principle beef with the 6551 design. It reflects 1970s-era thinking, when silicon fabrication was expensive and a primary goal was to minimize the complexity in order to minimize the cost. Modern UARTs are so much better in every respect.

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

Trouble for me, that is, is that I'm not experienced enough to get a different UART working with the 65C02. The '51 has at least some example code online that is pretty easy to follow.

I imagine I could take example code for other UART's and convert (such as C to asm).

So, is there a "hello world" for some of these with regards to the '02?

Thanks

_________________
Cat; the other white meat.

I posted something here a while ago, although the code is for the 65C816. Some massaging would be required to make it work with the 65C02. My NXP white paper, when finished, will address both processors.

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