I don't know whether writing 65duino VT100 escape codes would be harder or easier than to get the linux in the RPi0 to use VT52 codes in its tty, but if you could the RPi0 to use VT52, VT52 escape codes would be a lot easier to program in the 65duino. ESC A ESC B ESC C ESC D for the for cursor directions, ESC H to home to the top left corner, ESC I to reverse linefeed, ESC J to clear to the end of screen, ESC K to clear to the end of line, and ESC Y r c to set the cursor to the "r" row and "c" column.
Sadly it looks like VT100 codes are mostly baked in, in a lot of Linux things by now. I wonder if @Usagielectric's Centurion minicomputer, for instance, has some way of switching between the two. VT52 sure looks a lot more friendly - but the world moved on too soon I guess.
@@AndersNielsenAA It's linux, so they shouldn't be, programs should use ncurses and the defined termcap. Look in /lib/terminfo/ to see if there is a vt52. If there is, TERM=vt52 would shift from the default to VT52.
@@AndersNielsenAA The baked in problem would be more on the Builder side than the OS side, with a lot of people doing things by tinkering not knowing about terminfo and ncurses and hard-coding VT100 (or VT220). But if a VT52 entry is added to the terminfo library, the operating system should talk VT52 just fine.
I’ll have to take a look what’s available in Raspbian. Easier to flip a switch and handle VT52 for sure. By the look of it it’ll also make VT100 look better than no handling at all. It didn’t look too carefully but it doesn’t look like the kernel outputs many control codes.. if any.
So what did you think of this video? Post a comment below so I know you came from this video and then join me over on the free Discord server! Discord invite link: discord.gg/kmhbxAjQc3
Nice video, thanks. Clear screen used to use the form feed char (0x0C) on many pre VT100 terminals. It effectively throws a new page so starting again with a clear screen. Ctl C indicates end of transmission (ETX) so not really a good choice as you probably want to read the transmission before clearing it. You could drop the baud rate to 1200 baud or even slower to help with the buffer overruns.
You are absolutely right - I rushed on instead of picking an appropriate character. I'll fix it so CTRL+L(FF) does the clear screen in the future. I would also like to add a way to drop the baud rate on the fly. Dropping it all the way to 1200b might be enough that we can just print the character during the stop bit - which might mean we don't need the buffer.
Watching this you can definitely see how nice it would be to emulate a ROM with a Pico or something until final ROM programming is completed :-) Pins falling off.. lots of swapping.. I've broken a couple of ROMs doing this myself. Looks like a lot of fun playing with these I2C devices
I have done the opposite process : A raspberry PI controls an old Atari 2600 :)
That might be slightly more useful too :)
I don't know whether writing 65duino VT100 escape codes would be harder or easier than to get the linux in the RPi0 to use VT52 codes in its tty, but if you could the RPi0 to use VT52, VT52 escape codes would be a lot easier to program in the 65duino. ESC A ESC B ESC C ESC D for the for cursor directions, ESC H to home to the top left corner, ESC I to reverse linefeed, ESC J to clear to the end of screen, ESC K to clear to the end of line, and ESC Y r c to set the cursor to the "r" row and "c" column.
Sadly it looks like VT100 codes are mostly baked in, in a lot of Linux things by now. I wonder if @Usagielectric's Centurion minicomputer, for instance, has some way of switching between the two. VT52 sure looks a lot more friendly - but the world moved on too soon I guess.
@@AndersNielsenAA It's linux, so they shouldn't be, programs should use ncurses and the defined termcap. Look in /lib/terminfo/ to see if there is a vt52. If there is, TERM=vt52 would shift from the default to VT52.
@@AndersNielsenAA The baked in problem would be more on the Builder side than the OS side, with a lot of people doing things by tinkering not knowing about terminfo and ncurses and hard-coding VT100 (or VT220). But if a VT52 entry is added to the terminfo library, the operating system should talk VT52 just fine.
I’ll have to take a look what’s available in Raspbian. Easier to flip a switch and handle VT52 for sure.
By the look of it it’ll also make VT100 look better than no handling at all.
It didn’t look too carefully but it doesn’t look like the kernel outputs many control codes.. if any.
So what did you think of this video? Post a comment below so I know you came from this video and then join me over on the free Discord server!
Discord invite link: discord.gg/kmhbxAjQc3
Nice video, thanks. Clear screen used to use the form feed char (0x0C) on many pre VT100 terminals. It effectively throws a new page so starting again with a clear screen. Ctl C indicates end of transmission (ETX) so not really a good choice as you probably want to read the transmission before clearing it. You could drop the baud rate to 1200 baud or even slower to help with the buffer overruns.
You are absolutely right - I rushed on instead of picking an appropriate character. I'll fix it so CTRL+L(FF) does the clear screen in the future. I would also like to add a way to drop the baud rate on the fly. Dropping it all the way to 1200b might be enough that we can just print the character during the stop bit - which might mean we don't need the buffer.
On my Mac, stty -a shows the onlcr setting configured like yours. I've never done anything to change these settings.
Thank you. I think I had myself confused - but not enough to test it out on another Mac or Linux VM.
Watching this you can definitely see how nice it would be to emulate a ROM with a Pico or something until final ROM programming is completed :-) Pins falling off.. lots of swapping.. I've broken a couple of ROMs doing this myself. Looks like a lot of fun playing with these I2C devices
It's absolutely on the to try list :)