WTERM: Difference between revisions

From Alnwlsn - Projects Repository
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
'''WTERM''' is my own TRS-80 terminal emulator (written in Z80 Assembly), for use with my recently completed RS232 adapter. Although the RS232 board I wired up is 100% compatible with the true Radio Shack offering, and works as such, the software was a bit lacking. I tried out a couple programs for using the RS232 port (Omniterm and Matrix ALgorithim), and found a few problems for the things I wanted to do (connect to a Linux box and work with the command line):
'''WTERM''' is my own TRS-80 terminal emulator (written in Z80 Assembly), for use with my recently completed RS232 adapter. Although the RS232 board I wired up is 100% compatible with the true Radio Shack offering, and works as such, the software was a bit lacking. I tried out a couple programs for using the RS232 port (Omniterm and Matrix ALgorithim), and found a few problems for the things I wanted to do (connect to a Linux box and work with the command line):


* No cursor control. I want an ability to put the cursor anywhere on screen (Omniterm does have this, but it has other problems).
* No cursor control. I want an ability to put the cursor anywhere on screen (Ok, so Omniterm does have this, but it has its share of other problems).
* CR and LF are both the same. This is a big one - on pretty much any other terminal, these have 2 different purposes. CR makes the cursor move to the start of the line, and LF makes the cursor move one row/line down (and stays at the same column). The existing programs presumably use the TRS-80 ROM routines to drive the screen, and I don't think it has these features. Instead, either a LF or CR will make the cursor move to the start of the next line. This is a problem for Linux, which always sends CRLF. Even after editing the terminfo source to try to turn one of these signals off, it seems as though it's baked in. Some of the terminal programs like Omniterm try to suppress one or the other, but I found it doesn't work very well. Some Linux programs will send one or the other, fully expecting standard usage.
* CR and LF are both the same. This is a big one - on pretty much any other terminal, these have 2 different purposes. CR makes the cursor move to the start of the line, and LF makes the cursor move one row/line down (and stays at the same column). The existing programs presumably use the TRS-80 ROM routines to drive the screen, and I don't think it has these features. Instead, both an LF or CR will make the cursor move to the start of the next line. This is a problem for Linux, which always sends CRLF. Even after editing the terminfo source to try to turn one of these signals off, it seems as though it's baked in. Some of the terminal programs like Omniterm try to suppress LF in a CRLF, but I found it doesn't work very well. Some Linux programs will send one or the other, fully expecting standard usage.
* Too slow. The TRS-80 is only 1.77 mhz, and the RS232 does not use interrupts. So, anything that happens which is not reading the RS232 data stream in means that things can be easily missed. In particular, scrolling the screen upwards in most existing programs seems to use the ROM routines, during which time the UART cannot be read. Therefore, most terminal programs can only do 600 baud maximum, because any faster and some data will be lost during the time it takes the screen to scroll upwards.  
* Too slow. The TRS-80 is only 1.77 mhz, and the RS232 does not use interrupts. So, anything that happens which is not reading the RS232 data stream in means that bytes can be missed from the data stream. In particular, scrolling the screen upwards in most existing programs seems to use the ROM routines, during which time the UART cannot be read, and we might clip a few letters from a word. Therefore, most terminal programs can only do 600 baud maximum, because any faster and some data will be lost during the time it takes the screen to scroll upwards.  
* No handshaking. RTS/CTS are not used for anything. In most programs they are toggleable for general purpose, but not for handshaking. Omniterm is supposed to support XON/XOFF though.
* No handshaking. RTS/CTS are not used for anything. In most programs they are toggleable for general purpose, but not for handshaking. Omniterm is supposed to support XON/XOFF though.


My version roughly emulates a DEC VT-52 (the predecessor to the VT-100). It uses ESC codes which are shorter, and there are less of them, making implementation easier. I implemented the ESC codes for moving the cursor around, homing, and clearing stuff, which is most of them. There's no need to do alternate fonts or inverted colors; the TRS-80 character generator is fixed in a ROM. The rest is just improvements (especially on the issues discussed previously):
==WTERM==
My version roughly emulates a DEC VT-52 (the predecessor to the VT-100). I implemented the ESC codes for moving the cursor around, homing, and clearing stuff, which is most of them. There's no need to do alternate fonts or inverted colors; the TRS-80 character generator is fixed in a ROM. The rest is just fixing the issues discussed previously:


* Custom routines for drawing on the screen, and reading the keyboard. No ROM routines, I access the hardware directly. Not sure if these are any quicker, but by not being in ROM I can put extra stuff inside - between writes onto the screen, and between every keypress, I can read the UART to see if we got new data, meaning nothing gets missed. Also, thanks to these routines:
* Custom routines for drawing on the screen, and reading the keyboard. No ROM routines, I access the hardware directly. Not sure if these are any quicker, but by not being in ROM I can put extra stuff inside - between writes onto the screen, and between every keypress, I can read the UART to see if we got new data, meaning nothing gets missed. Also, thanks to these routines:
** Custom keyboard map. I use the CLEAR, SHIFT and BREAK keys as modifiers. It is possible you type every single ASCII code 0-127.  Enter is the only key handled separate (it just sends CR).
** Custom keyboard map. I use the CLEAR, SHIFT and BREAK keys as modifiers. It is possible you type every single ASCII code 0-127.  Enter is the only key handled separate (it just sends CR).
** CR and LF now do their standard functions, thanks to custom cursor control routines.  
** CR and LF now do their standard functions, thanks to custom cursor control routines.  
** It should be possible to operate WTERM without a TRS-80 ROM installed. (Why or how you would do this I'm not sure).
* Circular buffers on UART input and output. The keyboard probably doesn't need a buffer (nobody can type that fast), but the input buffer helps us collect the data quickly when we are doing something else like scrolling the screen or reading a key. Then, when we are not doing anything, we can work on the data we just collected.
* Circular buffers on UART input and output. The keyboard probably doesn't need a buffer (nobody can type that fast), but the input buffer helps us collect the data quickly when we are doing something else like scrolling the screen or reading a key. Then, when we are not doing anything, we can work on the data we just collected.
* Hardware flow control - When the buffer gets close to full, the RTS pin goes OFF. When it empties most of the way, it turns it back on. Simple and easy, but missing from existing programs. Why would I spend all that time building up a RS232 board if these signals are never used.
* Hardware flow control - When the buffer gets close to full, the RTS pin goes OFF. When it empties most of the way, it turns it back on. Simple and easy, but missing from existing programs. Why would I spend all that time building up a RS232 board if these signals are never used?
* Faster. Wterm can keep up with updating the screen at 1200 baud, which is fast enough to not feel excruciatingly slow, and makes things very usable.
* Faster. Wterm can keep up with updating the screen at 1200 baud, which is fast enough to not feel excruciatingly slow, and makes things pretty usable.
 
WTERM is probably not perfect (this is only the 2nd/3rd assembly program I have ever written!) but at least it makes the TRS-80 act like a more standard terminal.

Revision as of 00:48, 13 April 2020

WTERM is my own TRS-80 terminal emulator (written in Z80 Assembly), for use with my recently completed RS232 adapter. Although the RS232 board I wired up is 100% compatible with the true Radio Shack offering, and works as such, the software was a bit lacking. I tried out a couple programs for using the RS232 port (Omniterm and Matrix ALgorithim), and found a few problems for the things I wanted to do (connect to a Linux box and work with the command line):

  • No cursor control. I want an ability to put the cursor anywhere on screen (Ok, so Omniterm does have this, but it has its share of other problems).
  • CR and LF are both the same. This is a big one - on pretty much any other terminal, these have 2 different purposes. CR makes the cursor move to the start of the line, and LF makes the cursor move one row/line down (and stays at the same column). The existing programs presumably use the TRS-80 ROM routines to drive the screen, and I don't think it has these features. Instead, both an LF or CR will make the cursor move to the start of the next line. This is a problem for Linux, which always sends CRLF. Even after editing the terminfo source to try to turn one of these signals off, it seems as though it's baked in. Some of the terminal programs like Omniterm try to suppress LF in a CRLF, but I found it doesn't work very well. Some Linux programs will send one or the other, fully expecting standard usage.
  • Too slow. The TRS-80 is only 1.77 mhz, and the RS232 does not use interrupts. So, anything that happens which is not reading the RS232 data stream in means that bytes can be missed from the data stream. In particular, scrolling the screen upwards in most existing programs seems to use the ROM routines, during which time the UART cannot be read, and we might clip a few letters from a word. Therefore, most terminal programs can only do 600 baud maximum, because any faster and some data will be lost during the time it takes the screen to scroll upwards.
  • No handshaking. RTS/CTS are not used for anything. In most programs they are toggleable for general purpose, but not for handshaking. Omniterm is supposed to support XON/XOFF though.

WTERM

My version roughly emulates a DEC VT-52 (the predecessor to the VT-100). I implemented the ESC codes for moving the cursor around, homing, and clearing stuff, which is most of them. There's no need to do alternate fonts or inverted colors; the TRS-80 character generator is fixed in a ROM. The rest is just fixing the issues discussed previously:

  • Custom routines for drawing on the screen, and reading the keyboard. No ROM routines, I access the hardware directly. Not sure if these are any quicker, but by not being in ROM I can put extra stuff inside - between writes onto the screen, and between every keypress, I can read the UART to see if we got new data, meaning nothing gets missed. Also, thanks to these routines:
    • Custom keyboard map. I use the CLEAR, SHIFT and BREAK keys as modifiers. It is possible you type every single ASCII code 0-127. Enter is the only key handled separate (it just sends CR).
    • CR and LF now do their standard functions, thanks to custom cursor control routines.
    • It should be possible to operate WTERM without a TRS-80 ROM installed. (Why or how you would do this I'm not sure).
  • Circular buffers on UART input and output. The keyboard probably doesn't need a buffer (nobody can type that fast), but the input buffer helps us collect the data quickly when we are doing something else like scrolling the screen or reading a key. Then, when we are not doing anything, we can work on the data we just collected.
  • Hardware flow control - When the buffer gets close to full, the RTS pin goes OFF. When it empties most of the way, it turns it back on. Simple and easy, but missing from existing programs. Why would I spend all that time building up a RS232 board if these signals are never used?
  • Faster. Wterm can keep up with updating the screen at 1200 baud, which is fast enough to not feel excruciatingly slow, and makes things pretty usable.

WTERM is probably not perfect (this is only the 2nd/3rd assembly program I have ever written!) but at least it makes the TRS-80 act like a more standard terminal.