6502.org

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

And the TeleVideo 9xx series terminals were 6502-based terminals.

The Picocomputer I sent you has a VT-like terminal in it. It's not that bad looking back but getting started was hard. The deepest part of the hole is CSI with multiple arguments. I haven't filled out every command yet, but the state machine logic is complete.

Excitedly waiting for that to arrive. Written in 6502 ASM, python or c/++?
Source available for those by any chance?

You might find ROM dumps on e.g. bitsavers if you're lucky - but given the hardware is a raft of TTL then who knows just how much use it might be.

Another thought I just had - as well as DEC/ANSI codes, Acorn/BBC Micro codes are handy - much simpler too and can cater for graphics so the small but seemingly up and coming folks trying to get BBC Basic going might find that handy - I actually do the reverse in my Ruby system in that the host MCU translates Acorn codes into ANSI codes to code running on the 6502 can output to an ANSI terminal without any changes...

Just don't write/rewrite termcap... That's above & beyond!

-Gordon

I think they put it on the wrong truck because it took an unnecessary tour of the USA. Seems back on track now.

It's C that should port well to CC65. I'm planning on renaming the file, so here's a long permalink...
https://github.com/picocomputer/rp6502/ ... erm/term.c

While VT52 is a lot less capable, it is also simpler, with all but one control codes ESC plus one character ... if not supporting the graphics & keypad functions, 8 single character functions, plus the single three character command for setting cursor position. It's far from as common as VT-100/ANSI, but it does have some support -- eg, xterm can be opened in vt52 mode, for instance.

ESC A - cursor up
ESC B - cursor down
ESC C - cursor right
ESC D - cursor left
ESC H - cursor home
ESC I - reverse line feed ... cursor up one line, unless at home row, in which case scroll display down one line
ESC J - clear to end of screen
ESC K - clear to end of line
ESC Y r c - set cursor to row r, column c

If it's supposed to be useful as a quick and dirty terminal to hook up to anything spitting out VT100, I guess it only has to know its own limitations.

And maybe handle as many of these as possible: http://www.braun-home.net/michael/info/ ... mmands.htm

The VT 100 used an Intel 8080 as its processor, so it's within the capability of a 6502 to emulate a VT 100. Back in the day I used one on my Atari 800 XL to do my CS homework on my college's time sharing system.

So it's just a simple matter of programming. Which in practice is never simple.

I think it's interesting that you're essential doing the opposite of what most people do - so rather than having a VT100-compatible terminal connected to your computer for input and output, you're allowing other devices to use your 6502 based computer as an output terminal. I'm curious what these other devices are, did you have anything in mind? It is fairly easy to get a Linux computer to accept logins over a serial port, so that could be one thing.

Another benefit you'll get is that you can use VT100 sequences even from local programs, and have a standardised method for moving the cursor around regardless of whether the output is going to the LCD or to an external terminal.

This is the really interesting side of it to me ... for instance, in Forth, implementing a cursor down display word by printing a string starting with ESC [ is a nice and tidy approach.

In my last three videos I’ve been using a Raspberry Pi Zero as the “mainframe” I connect to and have been using that as starting point for what’s missing - so first I got it to login, then I got it to scroll and then I (almost) got it to respect flow control during boot.

Who knows - maybe I’ll get my hands on a minicomputer one day

Can a 6502 computer control a Raspberry Pi?
https://youtu.be/QYN7VGy-H6Y

Scrolling OLED on a 6502 Single Board Computer
https://youtu.be/Cexdm8K4kW0

Serial Flow Control. What's CTS RTS XOFF XON and why should you care?
https://youtu.be/pdloxXDJejM

And if you want PDP11 code that translates BBC VDU sequences to ANSI sequences.... or C code....

Sounds cool but all the links on your site seem dead?