WTERM - Revision history

Alnwlsn: Alnwlsn moved page TRS-80 - WTERM to WTERM: better title

2020-05-20T12:35:26Z

Alnwlsn moved page TRS-80 - WTERM to WTERM: better title

← Older revision	Revision as of 08:35, 20 May 2020
(No difference)

Alnwlsn: /* Files */

2020-05-20T03:45:42Z

Files

← Older revision		Revision as of 23:45, 19 May 2020
Line 21:		Line 21:
	==Files==		==Files==
	[[File:Wterm.zip]] - source and binary. Note that in here it's called "a". I use this to quickly compile and test my program:		[[File:Wterm.zip]] - source and binary. Note that in here it's called "a". I use this to quickly compile and test my program:
	1. Compile with yaza z80 compiler		# Compile with yaza z80 compiler
	2. Convert binary to Intel hex with a Python bin2hex program (I didn't write it, it comes as an example for the bin2hex module)		# Convert binary to Intel hex with a Python bin2hex program (I didn't write it, it comes as an example for the bin2hex module)
	3. Modify Intel Hex with the correct entry point		# Modify Intel Hex with the correct entry point
	4. Convert to CMD file using George Phillips's trld converter program		# Convert to CMD file using George Phillips's trld converter program
	5. Import the file onto a DOS disk image, already pre-configured to execute "a.cmd" on startup		# Import the file onto a DOS disk image, already pre-configured to execute "a.cmd" on startup
	6. Start trs80gp emulator with the disk in drive 0.		# Start trs80gp emulator with the disk in drive 0.

	The included batch file does all of this within about 3 seconds, making it a very quick way to test my programs after making minor changes. Note that you will need the above programs to do it, though.		The included batch file does all of this within about 3 seconds, making it a very quick way to test my programs after making minor changes. Note that you will need the above programs to do it, though.

Alnwlsn at 03:45, 20 May 2020

2020-05-20T03:45:05Z

← Older revision		Revision as of 23:45, 19 May 2020
Line 18:		Line 18:

	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.		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.

			==Files==
			[[File:Wterm.zip]] - source and binary. Note that in here it's called "a". I use this to quickly compile and test my program:
			1. Compile with yaza z80 compiler
			2. Convert binary to Intel hex with a Python bin2hex program (I didn't write it, it comes as an example for the bin2hex module)
			3. Modify Intel Hex with the correct entry point
			4. Convert to CMD file using George Phillips's trld converter program
			5. Import the file onto a DOS disk image, already pre-configured to execute "a.cmd" on startup
			6. Start trs80gp emulator with the disk in drive 0.

			The included batch file does all of this within about 3 seconds, making it a very quick way to test my programs after making minor changes. Note that you will need the above programs to do it, though.

Alnwlsn at 04:48, 13 April 2020

2020-04-13T04:48:39Z

Alnwlsn at 04:36, 13 April 2020

2020-04-13T04:36:40Z

← Older revision		Revision as of 00:36, 13 April 2020
Line 5:		Line 5:
	* 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 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.
	* 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):

			* 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.
			* 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 very usable.

Alnwlsn: Created page with "'''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% compati..."

2020-04-13T04:12:31Z

Created page with "'''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% compati..."

New page

'''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).
* 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.
* 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.
* 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.

← Older revision		Revision as of 00:48, 13 April 2020
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.