6551 vs 6850 vs 8250 vs ?

[White Flame]

GARTHWILSON wrote:

I find it surprising that Commodore didn't put a UART in those machines. There was a topic a year ago about a 57kbps bit-bang on a 1MHz 6502 (without interrupts-- only carefully counting cycles in a loop) at viewtopic.php?f=2&t=2063. The fact that it could be done at all is impressive; but it still keeps the processor from being able to handle interrupts or do anything else at all.

When I did my 56k implementation back in 2003, I used 2 start bits to give time for a NMI to trigger and perform startup. It was hardcoded to use an explicit length byte + data + checksum packet format, but it was able to sit in the background and preempt the system when data needed to move, so at least the system could do other things while data wasn't actually moving.

[BigDumbDinosaur]

clockpulse wrote:

Here is a 40 pin 26C92 version if desired -->here

You can still buy in single quan. 'special at this time', but keep in mind they change the minimums at any time.

Both Mouser and Digikey sell the 26C92 in single piece quantities for little more than what Avnet is charging. My experiences with Avnet have been mixed (they occasionally engage in "bait and switch" pricing), whereas experiences have always been positive with Mouser and Digikey.

[BigDumbDinosaur]

White Flame wrote:

GARTHWILSON wrote:

I find it surprising that Commodore didn't put a UART in those machines. There was a topic a year ago about a 57kbps bit-bang on a 1MHz 6502 (without interrupts-- only carefully counting cycles in a loop) at viewtopic.php?f=2&t=2063. The fact that it could be done at all is impressive; but it still keeps the processor from being able to handle interrupts or do anything else at all.

When I did my 56k implementation back in 2003, I used 2 start bits to give time for a NMI to trigger and perform startup. It was hardcoded to use an explicit length byte + data + checksum packet format, but it was able to sit in the background and preempt the system when data needed to move, so at least the system could do other things while data wasn't actually moving.

Using NMIs for I/O is generally not considered to be good system design practice, especially with the 65xx family. NMI should be reserved for a single, high-priority interrupt that will not frequently occur ("frequently" is relative to processing speed). For example, some systems reserve NMI to announce incipient power failure. Or an NMI could be triggered by a recurring timer interrupt to maintain stable timekeeping, even when IRQs are disabled. In my POC unit, NMI is brought out to a jumper block so I can can use it to break a runaway program, making this source the only possible cause of an NMI. All other interrupt sources are wired to IRQ.

The problem with using NMIs for I/O is the risk of the MPU missing multiple occurrences because the first one has not been cleared before succeeding ones occur. This issue was identified as one of the causes of unreliable CBAT RS-232 in the Commodore 8 bit computers.

[BigDumbDinosaur]

GARTHWILSON wrote:

TIA-232 (RS-232, EIA-232, etc. over the years) has been around about 50 years and is still being used in industrial settings (and in my office!). Consumer computing things don't last nearly so long.

Yeppers. I have TIA-232 hardware here that gets used all the time.

Quote:

There's a difference between:

1. feature creap that advances faster than you can build and keeps you from completing a project, and
2. designing a system that can be expanded later if necessary, not painting you into a corner so you can't expand it without starting over or at least re-doing a lot of work.

It takes a lot of experience to identify the line that divides the two. It's not easy.

Item-A is one seen all too often when someone gets the bug to scratch-build a computer. My analogy is that of not learning to fly a single-engine plane before climbing into the cockpit of a jumbo jet. When I designed POC V1 I took the route described in item-B.

[White Flame]

BigDumbDinosaur wrote:

Using NMIs for I/O is generally not considered to be good system design practice, especially with the 65xx family. NMI should be reserved for a single, high-priority interrupt that will not frequently occur ("frequently" is relative to processing speed). For example, some systems reserve NMI to announce incipient power failure. Or an NMI could be triggered by a recurring timer interrupt to maintain stable timekeeping, even when IRQs are disabled. In my POC unit, NMI is brought out to a jumper block so I can can use it to break a runaway program, making this source the only possible cause of an NMI. All other interrupt sources are wired to IRQ.

The problem with using NMIs for I/O is the risk of the MPU missing multiple occurrences because the first one has not been cleared before succeeding ones occur. This issue was identified as one of the causes of unreliable CBAT RS-232 in the Commodore 8 bit computers.

This was on the C64, so the wiring of sources to IRQ vs NMI was established. However, as the RS232 input line was coincident with the NMI triggering, and the CIA chip was in control of whether or not the I/O pins actually caused an interrupt, the NMI was disabled during the transfer. It only triggered at the point where normal code needed to be preempted into dedicated packet transfer mode, not for every bit or byte.

[BigDumbDinosaur]

White Flame wrote:

BigDumbDinosaur wrote:

Using NMIs for I/O is generally not considered to be good system design practice, especially with the 65xx family. NMI should be reserved for a single, high-priority interrupt that will not frequently occur ("frequently" is relative to processing speed). For example, some systems reserve NMI to announce incipient power failure. Or an NMI could be triggered by a recurring timer interrupt to maintain stable timekeeping, even when IRQs are disabled. In my POC unit, NMI is brought out to a jumper block so I can can use it to break a runaway program, making this source the only possible cause of an NMI. All other interrupt sources are wired to IRQ.

The problem with using NMIs for I/O is the risk of the MPU missing multiple occurrences because the first one has not been cleared before succeeding ones occur. This issue was identified as one of the causes of unreliable CBAT RS-232 in the Commodore 8 bit computers.

This was on the C64, so the wiring of sources to IRQ vs NMI was established. However, as the RS232 input line was coincident with the NMI triggering, and the CIA chip was in control of whether or not the I/O pins actually caused an interrupt, the NMI was disabled during the transfer. It only triggered at the point where normal code needed to be preempted into dedicated packet transfer mode, not for every bit or byte.

I'm familiar with the C-64 and C-128 circuitry and to this day, can't fathom why Commodore insisted on attaching CIA #2 to NMI. Granted, interrupt processing in general was slow on those machines (especially the C-128) what with having to poll each possible source on every IRQ. There's a limit to what an 8 bit processor running at a relatively slow clock rate can accomplish, and attaching yet another interrupt source to IRQ would have been burdensome in the kernel. The use of a real 6551 would have been a logical choice to off-load some of the work from the 6510/8502. However, Jack Tramiel was ruthless in paring cost to the bone so he could sell his machines through big box retailers. The omission of the 6551 (as well as earlier Commodore I/O features like GPIB) in such a case was inevitable.

POC V1 runs at 10 MHz with the SCSI host adapter installed (12.5 MHz without it) and doesn't even work up a sweat with both ports running at 115.2 Kbps (that's some 23,000 IRQs per second during CBAT loopback testing), despite the fact that the IRQ front end has more work to do than it would have in the C-64 or C-128—there's more MPU state to save on the stack when running the 65C816 in native mode. It merely points out that there is no substitute for MPU throughput when it comes to servicing IRQs. That the '816 can do it 16 bits at a time certainly helps.

[scotws]

I have a follow-up cable question regarding a serial connection I can't seem to find the answer to in the RS232 Primer (apols if I missed it).

The plan is to use a 65c51 (thanks, Mario) with a MAX232A and a DB-9 plug (somewhat surprisingly, I have three complete ribbon cables left over from my PC days). The MAX's output would go to a "pin connector", which the "box end" of the ribbon cable would fit on. The "business end" will connect via a null-modem cable to a USB-to-serial adapter connected to an old MacBook that will be the terminal.

Now, I'd like to use CTS/RTS, but not /DCD, /DSR or /DTR. This is what I think I should do with the three D's:

On the 65c51, I know to tie /DCD to ground. /DTR is an unused output pin, so I ignore it. /DSR should think the "modem" is always online, so it gets grounded, too.

On the DB9, I leave DCD (pin 1) unconnected -- no point. However, what do I do with DTR (pin 4) and DSR (pin 6)? I've seen a lot of schematics where these are fused on the plug (Grant Searle's Minimal Chip Count Computer, for instance). I could do that with the pin connectors, of course, but can I just leave them unconnected instead? Or would that risk getting the terminal (MacBook) confused?

Thanks for the help, and again for the RS232 Primer.

[GARTHWILSON]

The 51's DSR\ input can be read in the status register, but it does not affect operation of either the transmitter or receiver.  If you don't use it, tie it either way you like.  It doesn't matter which.

DTR\ is an output and you can leave it unconnected if you don't want to use it.

DSR and DTR could be connected to each other in the DB9 or DB25 connector.  I'm sure I've seen this done.

In all cases however, it would probably be good to do all six signals (TD, RD RTS, CTS, DSR, and DTR, but not DCD or RI which I think even most modems don't use) for the possibility that you decide to do things differently later, and have things like this selectable by way of jumpers on pin headers.  It does mean however that you'll need more than the two line drivers and two line receivers that a MAX232 has.  If you have the higher-voltage power supplies available, you can use the MC145406 which has three of each and requires no external capacitors.  There are other line driver & receiver ICs that have more also.

[BigDumbDinosaur]

GARTHWILSON wrote:

In all cases however, it would probably be good to do all six signals (TD, RD RTS, CTS, DSR, and DTR, but not DCD or RI which I think even most modems don't use)...

Most serial interface modems generate DCD and RI but few systems pay attention to those, as the required logic can offloaded to the modem.

CTS/RTS handshaking is the most reliable way to get high transfer rates. 65C51 primitives have to do in software what more advanced UARTs (e.g., the 26C92) do in hardware.

Quote:

It does mean however that you'll need more than the two line drivers and two line receivers that a MAX232 has.

The MAX-238 is tailor-made for this application, as it is essentially two MAX-232s in a single package.

[scotws]

Thanks for the advice, I think I actually have a MAX238 here, will look into that.

[and3rson]

I'm currently doing a project with 16550. I only need TX & RX, and it looks like 16550 has eight additional lines that can be used for general purpose, namely:

Inputs - /RI, /DCD, /DSR, /CTS
Outputs - /OUT1, /DTR, /RTS, /OUT2

I've seen some projects use them for LEDs & buttons, and I think I could utilize them for bit-banging the SPI bus. Are there any complications with doing that? Seems like 16550 should ignore them if model status interrupt flag is disabled?

[SamCoVT]

Edit - Sorry, accidentally replied to way-old post in this thread - can't see where to delete a post.

[Yuri]

and3rson wrote:

I'm currently doing a project with 16550. I only need TX & RX, and it looks like 16550 has eight additional lines that can be used for general purpose, namely:

Inputs - /RI, /DCD, /DSR, /CTS
Outputs - /OUT1, /DTR, /RTS, /OUT2

I've seen some projects use them for LEDs & buttons, and I think I could utilize them for bit-banging the SPI bus. Are there any complications with doing that? Seems like 16550 should ignore them if model status interrupt flag is disabled?

CTS, and RTS are used for hardware flow control. I've been using that with my 16C550C to get my windows PC to stop flooding my poor lil' 6502. XD

Been working like a champ, was able to dump a pretty good chunk of text to the system and got it back without error. My next goal to stress it will be to write an X-Modem protocol so I can upload programs to it without needing to swap out the ROM every time.

[bogrol]

Hello!

I have recently started building a 6502 SBC and want to have serial capabilities but only could acquire a WD8250 https://datasheetspdf.com/pdf-file/6061 ... l/WD8250/1. Unfortunately the datasheet is smokey for me but could deduce the following from it:
- Data lines TO data lines
- Receive clock TO Baudout
- Serial input TO TX
- Serial out TO RX
- The two active high CS-es (CS0, CS1) TO A12 (based on Garth Wilson's decoding scheme)
- The active low CS2 TO a NAND output
- XTAL1 TO an external 1,8432MHz clock
- XTAL2 N/C
- WR active low (pin 18) to 5V, active high (pin 19) to R/W
- RD active low (pin 21) to R/W, active high (pin 22) to GND
- Address lines to addresses
- Interrupt to IRQ (via NOT gate)

Please note that I have not used resistors in any case.
I am unsure about the following: Driver disable, Chip select out, Address strobe, RTS, DTR, CTS, DSR, Receiver line signal detect, Ring indicator
I would prefer not to use the four control lines (RTS CTS etc.). Is this possible? Do I need to tie them low throught a resistor?

Any help is greatly appreciated.

[BigDumbDinosaur]

bogrol wrote:

I have recently started building a 6502 SBC and want to have serial capabilities but only could acquire a WD8250...

I don’t want to discourage you, but the WD8250 is not a good fit to a 6502 system.  Although Western Digital claimed it was Motorola 6800 bus-compatible, which would seem to imply that it is 6502 bus-compatible, the reality is it isn’t quite there.  For a first effort, I’d suggest you find a 6551 (not the WDC 65C51, which has a serious defect) and work with that.  The bus interface will be much easier and there is plenty of example code you can use to build a driver.