cbmeeks wrote:
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.
My thinking when I designed the POC units was the same.
Quote:
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.
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.
Quote:
Anyway, do you recommend I try my design with the NXP instead of the '51?
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:
Attachment:
File comment: MC68000-Compatible Read/Write Circuit
68k_read_write.gif [ 6.95 KiB | Viewed 903 times ]
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:
Attachment:
File comment: Intel x86-Compatible Read/Write Circuit
x86_read_write.gif [ 19.73 KiB | Viewed 903 times ]
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.
Quote:
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.
Aside from the stuck TxD ready bit, the 65C51 represents the state of the art in 1976. UARTs have greatly advanced since those days.