I don’t think interrupt is quite that important. It is certainly possible to run an operating system without any interrupt ; CP/M comes to mind immediately. A CP/M clone in the 6502 world is DOS/65 and it, too, can work just fine without any interrupt. In fact, bit-bang transmitter works very well along with foreground polling of the receiver in DOS/65; the serial I/O routines are not complicated even with high data rate serial port.
Bill

I think we're all in agreement on that point, BDD. Neil (barnacle) is already aware, as too is Grant Searle. But let's bear in mind the context, as Neil suggested. If the context is a 65xx system running MS Basic then we can expect the system to finish processing any previous user/host input before any new input can be processed.

It's true that decoupling would allow an entire burst of new input to get queued up, ready for instant processing once the previous burst got digested. But the delay thereby avoided wouldn't have been noticeable unless the transmission rate is very slow and the new burst of input is lengthy.

Come right down to it, I guess “sneaky trick” and "crude hack" are actually synonymous... but in this case I lean toward the former. I wasn't aware of Grant's Sneaky Trick until Neil described it. But I gather that it allows supremely simple generation of the CTS signal at the expense of a delay that'll typically be unnoticeable, and that's an easily justified tradeoff for his minimalist design.

-- Jeff

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

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

I fear we are fiercely agreeing with each other here, but coming from different viewpoints. As an example, I've developed systems with (literally) dozens of small processors all talking to each other over a number of serial busses to pass asynchronous data between themselves. I've also developed systems with effectively one big processor managing everything, but again handling serial data from a number of sources - user interfaces, debugging, radio interfaces, network interfaces - and in both those cases I have used interrupt handling without a second thought.

In those applications to do anything else would have been silly, excruciatingly difficult to manage, and as you say, inefficient in program time.

But consider Grant's application: he was trying to build a simple minimum part count processor intended to run Basic. The interrupt signal could have been carried to the processor, certainly, but managing CTS (if necessary) would probably have required an extra chip. It wouldn't have made much difference to the software, which polls be default; after all, a character based Basic is either waiting for keys or executing something and if it needs to know if a key has been pressed then it's going to ask in the middle of a loop of some kind. It doesn't really matter whether the key press arrives buffered or not.

A big advantage to Grant's method is that there is no need to write and debug an interrupt routine before you can start using the thing. A single write configures the 68B50 and you're hot to either transmit or receive (or indeed both).

I note that at the default 115200 baud which is derived from the system clock divided by sixteen, a single byte requires 87us to receive so 192 clock cycles. As individual keyboard presses that's absolutely no problem but getting bulk data at this speed without some flow control - either through buffering and direct control of CTS or through Grant's method - is going to be possible but tricky.

Horses for courses?

Neil

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

That is indeed a consideration - particularly when using USB-serial adaptors which have a habit of queueing data and sending it in short bursts. That said, using a terminal program I haven't noticed any dropped characters.

I can't find anywhere in the 68B50 datasheet that indicates the response time of the interrupt signal, and nor have I yet found a timing reference referring in general to RTS timing - for example, if the signal is received partway through a character transmission, one might perhaps expect the character to be retried.

Of course, a buffer with high and low water marks controlling the RTS (and driven under interrupts for preference) solves the issue.

Neil

The latency from handshake negates to transmitter stop sending is a real life problem. In case of USB-serial adapters, different brand of adapter can have different latency. Recently I was debugging a barebone SBC with bitbang transmit and receive where bit timings are critical (no interrupt in the routines). The original design works with FT232 USB-serial adapter but does not work with CP2102 adapter. Eventually I observed that CP2102 can have a latency up to 5uS from handshake negating to transmitter stops, so I need to continue polling the receiver for 5uS after negation of handshake.

https://groups.google.com/g/retro-comp/c/MB3vODaBSMs

Bill

I bought an Arduino and it came in yesterday. Been playing around with the TX line a bit, and, well, I got it to work on the Acolyte without any extra hardware!

First, I read Garth's RS-232 primer (here http://wilsonminesco.com/RS-232/RS-232primer.html) for the 3rd time. I then found some examples on how to use Serial.X on the Arduino (which was SUPER easy to set up in Linux). Today I did a bit of code to see if I could read 9600 baud, and yep, *eventually* it worked. My biggest problem was finding how much delay I needed between readings. I need to fine-tune it still.

I'm connecting it directly to the SPI-MISO line, which is connected to the /SO pin on the 6502. So, this is NOT using interrupts, NOT using a VIA, it is only polling the overflow flag. But, no extra hardware, and that's a bonus. If I really wanted to do this in the future, I would need a transistor because the Arduino is constantly driving the MISO line, not allowing my SDcard to read.

I'll try the Arduino's RX line soon too, and then I'd have a 'working' serial connection, no extra hardware.

Did I mention without any extra hardware?!

Just an update on this topic, since it kind of spurred me into this direction. Thanks everyone!

Chad

A basic bitbang serial port is an isolation resistor (5-10K) between serial input and your data bus and a latch for serial output. At 9600 bps and depending on your application, you may not need hardware handshake. So a resistor and a latch for hardware; software is just timing loop and shift, no interrupt needed.
Bill

I'm not familiar with isolation resistors, Bill. Does that effectively act like a pull-up/down resistor, to whichever level the serial line is at? It doesn't affect the main bus during normal operation but is pulled-up/down when the bus is floating?

Update: I got minicom to work with it too now. A very simple "read then print" loop on the Arduino, connect the Arduino to minicom at 9600, and then just start typing. Presto, I can type from my PC keyboard onto the Acolyte's screen!

Now, just to receive data back from the Acolyte to minicom...

Thanks everyone!

Chad

Wait.. I'm sort of losing track here... And I might well be missing something...

You have an Arduino connected to your SBC - using a digital output on the Arduino to the /SO input pin on the 6502, then a software routine on the 6502 to receive serial data via /SO, so it's :

PC -> USB -> Arduino -> SBC

Maybe I'm missing something but if this is the case, then the Arduino is just acting as a USB serial adapter. (Using hardware serial on the input pins and softSerial on the output pin?) So why not just use a USB serial adapter directly from the PC to the SO pin? without the Arduino?

I've been using USB serial adapters for years without any issues - something like this:

https://www.amazon.co.uk/DUBEUYEW-FT232 ... B0B4DXY4H9

Your Arduino even has one built into it (depending on the model).

The challenge isn't the USB serial side it's getting serial in/out of the SBC - Then a UART chip or something else - 2 pins on the 6522 to implement software serial or Talk SPI to the Arduino (3 wires from the 6522 to the Arduino + Gnd) and have the Arduino act as the UART - that needs software on the Arduino side. I think I'd use a W65C51 and implement a software timing loop though. (Then just connect the TTL output of that to the USB Serial adapter).

Polling the /SO pin (or any other soft of software serial on the 65xx side) is going to be problematic with interrupts going off...

But unless you have another use for the Arduino it's just not needed and will only complicate things.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Like a pull up/down resistor, isolation resistor is a weak resistor connecting two active circuits. When circuits are active, the weak resistor has no effects on either circuit but when one of the circuits is tri-stated, the state of other circuit is manifested on the tri-stated circuit. For the serial input example, the isolation resistor connects between TTL output of USB-serial adapter and data x of W65C02 data bus. This allows W65C02 to read the value of serial input without the serial input affecting normal operations of W65C02. It is a poor man's tri-state input buffer. There are better ways of doing it, but we are talking about a bare minimal approach.
Bill

Edit, in case of W65C02, connecting serial input to SO is a better solution. For Z80, an isolation resistor is a simple way of reading serial input.

(Sinclair's ZXSpectrum used such resistors on the address and data busses.)

And was not alone; it was a common way of interfacing video ram.

Neil

But to get back on track for UARTs: there's a robust way of driving UART signals without a UART chip if you have an input pin, an output pin, and a timer that can trigger an interrupt at four times the baud rate. Effectively you build a software state machine that replicates the hardware in the UART.

• Start in the idle state. On each tick, check to see whether the input has gone low and if so, go to start state.
• on the second tick in start state, check that the input is still low; if it isn't, flag a glitch and go back to idle; otherwise to to receive state
• every fourth tick in receive state, read the input and shift the bit into an rx byte
• after eight bits are shifted (assuming 8-1-n which is a pretty safe bet!) change to end state; stuff the newly received byte into a buffer
• after four ticks in end state, check that the input - the stop bit - is high. If it is alert the main program that a byte has been received; if not flag an overrun error

Transmission is obvious; just shift a tx byte through every four ticks, not forgetting the start and stop bits! This approach ensures that the sampling for the rx level occurs somewhere close to the middle of the bit period, based on the timing of the start bit.

I've used this method on an older AVR that had only one serial port when I needed two (and the other one had to run at some very odd baud rates from 5 baud to 7812.5 baud) and both used interrupts to manage a small buffer; the program polled by comparing head and tail pointers, at speeds of 4800 baud on an 8MHz AVR. It ought to be within the reach of a 6502/6522.

Neil