So I'm slowly making my little 65uino into a very basic terminal - and so far it has some basic IO, scrolls, has a serial buffer and most recently it got a feel for flow control:
https://youtu.be/pdloxXDJejM
But.. The more I implement, the more I realize making just a 90% VT100 compatible, is quite an undertaking (Dunning-Kruger in full effect here).
I did a search and see some VT100 use but I've missed it if someone's already made a VT100 terminal from a 6502 system on here. It's a rabbit hole I'm not sure I want to follow too far but if I can cheat and use someone else's code I'd like to wrap it up .. but I can't seem to find any
It might be a nonsense idea to make a VT100 out of a minimal 6502 with a screen, but I appreciate any help I can get.
Interesting stuff.. Is it nonsense? Well, you're not doing anything new - we did this on Apple IIs and BBC Micros and everything else we used back in the day - even if you look at older terminals, they often had am early CPU in them like the 6800 or 8080 - and a genuine DEC VT100 has an 8080A inside it ... So ...
What you're doing isn't new by a long way... Writing serial drivers and so on has long been the bane of my life and today? I find that a lot of adapters and softwares, etc. just don't bother to even check (or enable) flow control (be it hardware, cts/rts or software xon/xoff...) and some USB adapters don't support hardware flow control either. It's a dying art.
Software - Xon/off isn't always as obvious as it may appear either - remember the wires are full duplex and you may have a full output buffer when your input buffer become full, so where can you inject the Xoff character in the output stream? And remember that in the time it takes to get to the sender, the sender may have sent another 2 characters (one in-flight and another starting before the in-flight Xoff lands on the remote end.. And modern UARTs have FIFOs in them, so they may have the next 16 characters ready to be clocked out - the receiver can get the Xoff and stop sending, but those bytes in the output FIFO are still there, still being clocked out... (unless that UART hardware can recognise them rather than pass them through)
So you need high-water marks and low water marks - and a means to bypass the output buffer to inject the Xoff even if the output buffer is full. So don't wait until the input buffer is full to send the stop, but maybe 75-80% full to give you some wiggle room. And it works both ways. Don't send the Xon when empty, but almost empty (low water mark), so you never run out with gaps in the transmissions...
The same applies for hardware handshaking although that ought to stop within one character being sent, but remember that when you say stop to the remote there may still be a byte in-flight on the wire...
Simple terminals would probably never have a full output buffer (no-one can type that fast) but one day you may be transferring files... If you want an example of just how horrible that can get the look at the Kermit protocol...
Cheers,
-Gordon
