Bitchin100 DocGarden - User contributions [en]

Model 200 serial interface

2009-03-22T21:19:10Z

78.69.53.223:

== Overview ==

The BASIC ROM provides access to the serial port. BASIC ROM support is well documented elsewhere. This article covers direct use of the [[80C52]] on the Tandy 200.

== Configuration ==

Before the serial port can be used, it must be configured both for serial word format (data bits, stop bits, and parity) and baud rate.

=== Select RS232 Port ===

At any given time, either the internal modem or the external RS232 connector may be connected to the UART. This is controllable through software.

For RS232 access, 8155 port B <code>$B2</code>, bit #3 must be set to 0.

For Modem access, 8155 port B <code>$B2</code>, bit #3 must be set to 1.

Note that <code>$B2</code> is shared with other functions, including power control.

=== Serial Word Format ===

Port <code>$C0</code> controls the mode configuration and command register.

Mode configuration (Asyncronous)
{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
|Bit || Function || Settings
|-
|0-1 || Baud rate devisor || 00=* 01=1x 10=16x 11=64x
|-
|2-3 || Character Length Select || Bits: 00 → 5 01 → 6 10 → 7 11 → 8
|-
|4-5 || Parity Inhibit || 00 → No Parity 01 → Odd parity 10 → No Parity 11 → Even parity
|-
|6-7 || Stop Bits || 00 → Inhibit 01 → 1 10 → 1.5 11 → 2
|}

Mode configuration (Syncronous)
{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
|Bit || Function || Settings
|-
|0-1 || Not used || 00
|-
|2-3 || Character Length Select || Bits: 00 → 5 01 → 6 10 → 7 11 → 8
|-
|4-5 || Parity Inhibit || 00 → No Parity 01 → Odd parity 10 → No Parity 11 → Even parity
|-
|6 || Sync mode || 0 → Internal 1 → External
|-
|7 || No. of Sync chars || 0 → 2 Bytes 1 → 1 Byte
|}

Command register
{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
|Bit || Function || Settings
|-
|0 || /TXE || 0 → Disable 1 → Enable
|-
|1 || DTR || 0 → 1 1 → 0
|-
|2 || RXE || 0 → 0 1 → 1
|-
|3 || SBRK || 0 → Normal Operation 1 → Send BRK char
|-
|4 || ER || 0 → Normal Operation 1 → Reset error flag
|-
|5 || /RTS || 0 → 1 1 → 0
|-
|6 || IR || 0 → Normal Operation 1 → Internal Reset
|-
|7 || EH || 0 → Normal Operation 1 → *
|}
=== Baud Rate ===
--uptohere--
CPU selection of baud rate is accomplished by loading a divisor into the PIO register through output ports <code>$BC</code> or <code>$B4</code> and <code>$BD</code> or <code>$B5</code>.

The baud rate selection must be committed by writing <code>$C3</code> to register <code>$B8</code>.

Here is a table of some baud rates that may be of interest:

{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
| Baud Rate || PIO Divisor || Port <code>$BD</code> || Port <code>$BC</code>
|-
| 75 || 2048 || 72 || 0
|-
| 110 || 1396 || 69 || 116
|-
| 300 || 512 || 66 || 0
|-
| 600 || 256 || 65 || 0
|-
| 1200 || 128 || 64 || 128
|-
| 2400 || 64 || 64 || 64
|-
| 4800 || 32 || 64 || 32
|-
| 9600 || 16 || 64 || 16
|-
| 19200 || 8 || 64 || 8
|-
| 38400 || 4 || 64 || 4
|-
| 76800 || 4 || 64 || 2
|-
| 153600 || 4 || 64 || 1
|}

I include 76800 and 153600 since they are the highest baud rates that the M100 is capable of. Certainly they are usable for communicating with another Model 100. However since they are not a "known" baud rate, they are less useful for communicating with PCs or other devices.

That said, you may be able to find a device or bitbang GPIO lines to communicate at these rates. I have read that some USB->Serial adapters are capable of communicating at many more baud rates than the typical built-in serial ports, so there is definitely room for further exploration.

Here is a practical example of using 38400bps using only BASIC code. This program dumps all RAM contents to the serial port.

<pre>
1 DEFINTA-Z:
OPEN"COM:98N1D"FOROUTPUTAS1:
D$="":
A=FRE("0"):
L=VARPTR(D$)+1:
M=L+1:
POKEL-1,128:
OUT180,4:
OUT181,64:
OUT184,195:
FORI=0TO255:
POKEM,128+I/2:
POKEL,(IMOD2)*128:
PRINT#1,D$;:
NEXT
</pre>

Unfortunately this BASIC code does not transmit the 32K of data any faster than the 19200bps code. Both take about 33 seconds to transmit the image.

So, here's an assembly language version of the same program. It transfers your Model 100's 32K RAM to a serial connection in about 8.5 seconds!

Note that this code obeys the "clear to send" signal from the PC, so given hardware flow control enabled and properly configured on the PC, we should not overrun the remote UART.

Not that if the PC is busy doing something else (like printing to the screen) it might flow control us, and you may not achieve the maximum speed.

<pre>
.org 64704

; select RS232 port
MVI A, $25
OUT $BA

; set up 8N1
MVI A, 28
OUT $D8

; set up 38400 bps
MVI A, 64
OUT $BD
MVI A, 4
OUT $BC
MVI A, $C3
OUT $B8

LXI H,32768

WAITEMPTY: IN $D8
ANI $10
JZ WAITEMPTY

WAITCTS: IN $BB
CMA
ANI $10
JZ WAITCTS

MOV A,M
OUT $C8

INX H
MOV A,H
ORA L

JNZ WAITEMPTY

RET

.END
</pre>

== Data Transmission ==

Once configured, sending a character is simply

MVI 'A'
OUT $C8

or, in BASIC,

OUT 200,ASC("A")

In the UART, there is room for two characters: the character currently be transmitted, and the next one. This permits you to ensure there is always one character waiting in the wings.

You should never overflow the transmission buffers. Either do some other work during the "downtime" and/or wait until there is room by polling bit 4 (0x10) of register $D8. The code that follows just does a "busy wait."

WAITEMPTY: IN $D8
ANI $10
JZ WAITEMPTY

When deciding whether the other device is ready to receive you should also consider the Clear To Send (CTS) flow control line described later in this document.

== Data Reception ==

=== BASIC ROM Interrupt 6.5 Handling ===

Whenever the UART receives another character, Interrupt 6.5 is signalled. Then, if interrupts are enabled, the CPU stops what it is doing and CALLs location 0x0034 in the BASIC ROM. This code disables further interrupts and jumps to the location 0x6DAC.

The ISR then jumps to vector 0xFE5C (0xF5FC?) in RAM. Normally this is just a return instruction, but you could hook the interrupt here. [ stack manipulation to avoid/ or include default processing + re-enable interrupts? - TBD ]

=== Polling Interrupt 6.5 ===

Accepting the BASIC ROM's handling imposes significant overhead. With each interrupt, the instruction pointer must be placed on the stack and a jump performed at minimum. If the BASIC ROM (as opposed to an Option ROM) is switched in, then you will have the overhead of disabling interrupts, a jump to the DR vector, a return instruction, and then the default processing of reading and enqueing the new character. All that, and at this point no useful work has been performed other than to relieve the UART.

For maximum efficiency you may wish to poll Interrupt 6.5 pin rather than accept the overhead of an interrupt. This is made possible by the 8085's SIM and RIM instructions.

Using the SIM instruction, you can set the interrupt mask such that UART DR (data ready), bit 1, will not trigger an interrupt. Then, you can poll this bit using the RIM instruction ANDing with 0x20 to see if DR is set.

Alternatively, you could disable interrupt processing altogether during your polled routine, but still use RIM to poll. This has the disadvantage of disabling the background ISR. But to achieve higher baud rates, you may not want the background ISR running anyway.

== Flow Control ==

The Model T has full support in hardware for the CTS and RTS flow control lines. In the BASIC ROM, however, it is not implemented. Instead the BASIC ROM relies on slow, kludgy XON/XOFF character escapes. This makes it difficult to transmit or receive binary files since the XON/XOFF characters are reserved for flow control.

Since we are discussing direct control of the UART, we can do better and implement full flow control.

=== Detect Clear to Send (CTS) ===

The CTS line is an input to the Model 100. It indicates whether the device attached to the serial port (or the remote equipment behind it) has room to accept new characters. The device can "flow off" the Model T when its receive buffers are full.

Implementing CTS is easy. The following code performs a busy wait on CTS:

<pre>
WAITCTS: IN $BB
CMA
ANI $10
JZ WAITCTS
</pre>

CTS line is read from bit #5 of I/O address 0xBB. Note that it is inverted; if it is 0, the device is signalling "clear to send." If 1, the device is attempting to flow us off from transmitting.

=== Request Peer to Send (RTS) ===

The RTS line is an output from the Model 100 to the device connected on the serial port. It is a signal "requesting" the device to send (or not to send). From the other point of view, the device should transmit if and only if RTS is high. Note that from the device perspective, it sees our RTS as its CTS.

If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.

The RTS and DTR lines are located on I/O register 0xBA (186).

(IN PROGRESS)

== Handling Communication Errors ==

(IN PROGRESS)

== I/O Map ==

Here, for reference, is the serial I/O map:

<table border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;">
<tr><td>Name</td><td>Direction</td><td>Port</td></tr>
<tr><td>TX</td> <td>Output</td> <td>$C8 (200)</td></tr>
<tr><td>RX</td> <td>Input</td> <td>$C8 (200)</td></tr>
<tr><td>RTS</td> <td>Output</td> <td>$BA (186), bit 7</td></tr>
<tr><td>CTS</td> <td>Input</td> <td>$BB (187), bit 4</td></tr>
<tr><td>DSR</td> <td>Input</td> <td>$BB (187), bit 5</td></tr>
<tr><td>DTR</td> <td>Output</td> <td>$BA (186), bit 6</td></tr>
</table>

nb: sense on DSR, CTS seem to be inverted. So CTS ==0 means that it is OK to transmit. A '1' means the device is flowing the Model T off.

nb: Port <code>$BA</code> is called "Port B" in the Model 100 Technical Reference. It has other functions than UART control, including the critical Power On/Off line. See [[Model 100 Port B]] for the breakdown.

Direction indicates both data flow, and whether to use an <code>IN</code> or <code>OUT</code> instruction to read/write to the given pin.

[[Category:Model T Developer Reference]]

Model 200 serial interface

2009-03-22T21:17:09Z

78.69.53.223:

== Overview ==

The BASIC ROM provides access to the serial port. BASIC ROM support is well documented elsewhere. This article covers direct use of the [[80C52]] on the Tandy 200.

== Configuration ==

Before the serial port can be used, it must be configured both for serial word format (data bits, stop bits, and parity) and baud rate.

=== Select RS232 Port ===

At any given time, either the internal modem or the external RS232 connector may be connected to the UART. This is controllable through software.

For RS232 access, 8155 port B <code>$B2</code>, bit #3 must be set to 0.

For Modem access, 8155 port B <code>$B2</code>, bit #3 must be set to 1.

Note that <code>$B2</code> is shared with other functions, including power control.

=== Serial Word Format ===

Port <code>$C0</code> controls the mode configuration, bit configuration and command register.

Mode configuration
{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
|Bit || Function || Settings
|-
|0-1 || Baud rate devisor || 00=* 01=1x 10=16x 11=64x
|-
|2-3 || Character Length Select || Bits: 00 → 5 01 → 6 10 → 7 11 → 8
|-
|4-5 || Parity Inhibit || 00 → No Parity 01 → Odd parity 10 → No Parity 11 → Even parity
|-
|6-7 || Stop Bits || 00 → Inhibit 01 → 1 10 → 1.5 11 → 2
|}

Bit configuration
{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
|Bit || Function || Settings
|-
|0-1 || Not used || 00
|-
|2-3 || Character Length Select || Bits: 00 → 5 01 → 6 10 → 7 11 → 8
|-
|4-5 || Parity Inhibit || 00 → No Parity 01 → Odd parity 10 → No Parity 11 → Even parity
|-
|6 || Sync mode || 0 → Internal 1 → External
|-
|7 || No. of Sync chars || 0 → 2 Bytes 1 → 1 Byte
|}

Command register
{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
|Bit || Function || Settings
|-
|0 || /TXE || 0 → Disable 1 → Enable
|-
|1 || DTR || 0 → 1 1 → 0
|-
|2 || RXE || 0 → 0 1 → 1
|-
|3 || SBRK || 0 → Normal Operation 1 → Send BRK char
|-
|4 || ER || 0 → Normal Operation 1 → Reset error flag
|-
|5 || /RTS || 0 → 1 1 → 0
|-
|6 || IR || 0 → Normal Operation 1 → Internal Reset
|-
|7 || EH || 0 → Normal Operation 1 → *
|}
=== Baud Rate ===
--uptohere--
CPU selection of baud rate is accomplished by loading a divisor into the PIO register through output ports <code>$BC</code> or <code>$B4</code> and <code>$BD</code> or <code>$B5</code>.

The baud rate selection must be committed by writing <code>$C3</code> to register <code>$B8</code>.

Here is a table of some baud rates that may be of interest:

{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
| Baud Rate || PIO Divisor || Port <code>$BD</code> || Port <code>$BC</code>
|-
| 75 || 2048 || 72 || 0
|-
| 110 || 1396 || 69 || 116
|-
| 300 || 512 || 66 || 0
|-
| 600 || 256 || 65 || 0
|-
| 1200 || 128 || 64 || 128
|-
| 2400 || 64 || 64 || 64
|-
| 4800 || 32 || 64 || 32
|-
| 9600 || 16 || 64 || 16
|-
| 19200 || 8 || 64 || 8
|-
| 38400 || 4 || 64 || 4
|-
| 76800 || 4 || 64 || 2
|-
| 153600 || 4 || 64 || 1
|}

I include 76800 and 153600 since they are the highest baud rates that the M100 is capable of. Certainly they are usable for communicating with another Model 100. However since they are not a "known" baud rate, they are less useful for communicating with PCs or other devices.

That said, you may be able to find a device or bitbang GPIO lines to communicate at these rates. I have read that some USB->Serial adapters are capable of communicating at many more baud rates than the typical built-in serial ports, so there is definitely room for further exploration.

Here is a practical example of using 38400bps using only BASIC code. This program dumps all RAM contents to the serial port.

<pre>
1 DEFINTA-Z:
OPEN"COM:98N1D"FOROUTPUTAS1:
D$="":
A=FRE("0"):
L=VARPTR(D$)+1:
M=L+1:
POKEL-1,128:
OUT180,4:
OUT181,64:
OUT184,195:
FORI=0TO255:
POKEM,128+I/2:
POKEL,(IMOD2)*128:
PRINT#1,D$;:
NEXT
</pre>

Unfortunately this BASIC code does not transmit the 32K of data any faster than the 19200bps code. Both take about 33 seconds to transmit the image.

So, here's an assembly language version of the same program. It transfers your Model 100's 32K RAM to a serial connection in about 8.5 seconds!

Note that this code obeys the "clear to send" signal from the PC, so given hardware flow control enabled and properly configured on the PC, we should not overrun the remote UART.

Not that if the PC is busy doing something else (like printing to the screen) it might flow control us, and you may not achieve the maximum speed.

<pre>
.org 64704

; select RS232 port
MVI A, $25
OUT $BA

; set up 8N1
MVI A, 28
OUT $D8

; set up 38400 bps
MVI A, 64
OUT $BD
MVI A, 4
OUT $BC
MVI A, $C3
OUT $B8

LXI H,32768

WAITEMPTY: IN $D8
ANI $10
JZ WAITEMPTY

WAITCTS: IN $BB
CMA
ANI $10
JZ WAITCTS

MOV A,M
OUT $C8

INX H
MOV A,H
ORA L

JNZ WAITEMPTY

RET

.END
</pre>

== Data Transmission ==

Once configured, sending a character is simply

MVI 'A'
OUT $C8

or, in BASIC,

OUT 200,ASC("A")

In the UART, there is room for two characters: the character currently be transmitted, and the next one. This permits you to ensure there is always one character waiting in the wings.

You should never overflow the transmission buffers. Either do some other work during the "downtime" and/or wait until there is room by polling bit 4 (0x10) of register $D8. The code that follows just does a "busy wait."

WAITEMPTY: IN $D8
ANI $10
JZ WAITEMPTY

When deciding whether the other device is ready to receive you should also consider the Clear To Send (CTS) flow control line described later in this document.

== Data Reception ==

=== BASIC ROM Interrupt 6.5 Handling ===

Whenever the UART receives another character, Interrupt 6.5 is signalled. Then, if interrupts are enabled, the CPU stops what it is doing and CALLs location 0x0034 in the BASIC ROM. This code disables further interrupts and jumps to the location 0x6DAC.

The ISR then jumps to vector 0xFE5C (0xF5FC?) in RAM. Normally this is just a return instruction, but you could hook the interrupt here. [ stack manipulation to avoid/ or include default processing + re-enable interrupts? - TBD ]

=== Polling Interrupt 6.5 ===

Accepting the BASIC ROM's handling imposes significant overhead. With each interrupt, the instruction pointer must be placed on the stack and a jump performed at minimum. If the BASIC ROM (as opposed to an Option ROM) is switched in, then you will have the overhead of disabling interrupts, a jump to the DR vector, a return instruction, and then the default processing of reading and enqueing the new character. All that, and at this point no useful work has been performed other than to relieve the UART.

For maximum efficiency you may wish to poll Interrupt 6.5 pin rather than accept the overhead of an interrupt. This is made possible by the 8085's SIM and RIM instructions.

Using the SIM instruction, you can set the interrupt mask such that UART DR (data ready), bit 1, will not trigger an interrupt. Then, you can poll this bit using the RIM instruction ANDing with 0x20 to see if DR is set.

Alternatively, you could disable interrupt processing altogether during your polled routine, but still use RIM to poll. This has the disadvantage of disabling the background ISR. But to achieve higher baud rates, you may not want the background ISR running anyway.

== Flow Control ==

The Model T has full support in hardware for the CTS and RTS flow control lines. In the BASIC ROM, however, it is not implemented. Instead the BASIC ROM relies on slow, kludgy XON/XOFF character escapes. This makes it difficult to transmit or receive binary files since the XON/XOFF characters are reserved for flow control.

Since we are discussing direct control of the UART, we can do better and implement full flow control.

=== Detect Clear to Send (CTS) ===

The CTS line is an input to the Model 100. It indicates whether the device attached to the serial port (or the remote equipment behind it) has room to accept new characters. The device can "flow off" the Model T when its receive buffers are full.

Implementing CTS is easy. The following code performs a busy wait on CTS:

<pre>
WAITCTS: IN $BB
CMA
ANI $10
JZ WAITCTS
</pre>

CTS line is read from bit #5 of I/O address 0xBB. Note that it is inverted; if it is 0, the device is signalling "clear to send." If 1, the device is attempting to flow us off from transmitting.

=== Request Peer to Send (RTS) ===

The RTS line is an output from the Model 100 to the device connected on the serial port. It is a signal "requesting" the device to send (or not to send). From the other point of view, the device should transmit if and only if RTS is high. Note that from the device perspective, it sees our RTS as its CTS.

If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.

The RTS and DTR lines are located on I/O register 0xBA (186).

(IN PROGRESS)

== Handling Communication Errors ==

(IN PROGRESS)

== I/O Map ==

Here, for reference, is the serial I/O map:

<table border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;">
<tr><td>Name</td><td>Direction</td><td>Port</td></tr>
<tr><td>TX</td> <td>Output</td> <td>$C8 (200)</td></tr>
<tr><td>RX</td> <td>Input</td> <td>$C8 (200)</td></tr>
<tr><td>RTS</td> <td>Output</td> <td>$BA (186), bit 7</td></tr>
<tr><td>CTS</td> <td>Input</td> <td>$BB (187), bit 4</td></tr>
<tr><td>DSR</td> <td>Input</td> <td>$BB (187), bit 5</td></tr>
<tr><td>DTR</td> <td>Output</td> <td>$BA (186), bit 6</td></tr>
</table>

nb: sense on DSR, CTS seem to be inverted. So CTS ==0 means that it is OK to transmit. A '1' means the device is flowing the Model T off.

nb: Port <code>$BA</code> is called "Port B" in the Model 100 Technical Reference. It has other functions than UART control, including the critical Power On/Off line. See [[Model 100 Port B]] for the breakdown.

Direction indicates both data flow, and whether to use an <code>IN</code> or <code>OUT</code> instruction to read/write to the given pin.

[[Category:Model T Developer Reference]]

Model 200 serial interface

2009-03-22T17:07:39Z

78.69.53.223:

== Overview ==

The BASIC ROM provides access to the serial port. BASIC ROM support is well documented elsewhere. This article covers direct use of the [[80C52]] on the Tandy 200.

== Configuration ==

Before the serial port can be used, it must be configured both for serial word format (data bits, stop bits, and parity) and baud rate.

=== Select RS232 Port ===

At any given time, either the internal modem or the external RS232 connector may be connected to the UART. This is controllable through software.

For RS232 access, 8155 port B <code>$B2</code>, bit #3 must be set to 0.

For Modem access, 8155 port B <code>$B2</code>, bit #3 must be set to 1.

Note that <code>$B2</code> is shared with other functions, including power control.

=== Serial Word Format ===

Port <code>$C0</code> controls the serial word format.

{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
|Bit || Function || Settings
|-
|0-1 || Baud rate devisor || 00=* 01=1x 10=16x 11=64x
|-
|2-3 || Character Length Select || Bits: 00 → 5 01 → 6 10 → 7 11 → 8
|-
|4-5 || Parity Inhibit || 00 → No Parity 01 → Odd parity 10 → No Parity 11 → Even parity
|-
|6-7 || Character Length Select || Bits: 00 → 5 01 → 6 10 → 7 11 → 8
|-
|7-5 || Stop Bits || 00 → Inhibit 01 → 1 10 → 1.5 11 → 2
|}

=== Baud Rate ===
--uptohere--
CPU selection of baud rate is accomplished by loading a divisor into the PIO register through output ports <code>$BC</code> or <code>$B4</code> and <code>$BD</code> or <code>$B5</code>.

The baud rate selection must be committed by writing <code>$C3</code> to register <code>$B8</code>.

Here is a table of some baud rates that may be of interest:

{| border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;"
| Baud Rate || PIO Divisor || Port <code>$BD</code> || Port <code>$BC</code>
|-
| 75 || 2048 || 72 || 0
|-
| 110 || 1396 || 69 || 116
|-
| 300 || 512 || 66 || 0
|-
| 600 || 256 || 65 || 0
|-
| 1200 || 128 || 64 || 128
|-
| 2400 || 64 || 64 || 64
|-
| 4800 || 32 || 64 || 32
|-
| 9600 || 16 || 64 || 16
|-
| 19200 || 8 || 64 || 8
|-
| 38400 || 4 || 64 || 4
|-
| 76800 || 4 || 64 || 2
|-
| 153600 || 4 || 64 || 1
|}

I include 76800 and 153600 since they are the highest baud rates that the M100 is capable of. Certainly they are usable for communicating with another Model 100. However since they are not a "known" baud rate, they are less useful for communicating with PCs or other devices.

That said, you may be able to find a device or bitbang GPIO lines to communicate at these rates. I have read that some USB->Serial adapters are capable of communicating at many more baud rates than the typical built-in serial ports, so there is definitely room for further exploration.

Here is a practical example of using 38400bps using only BASIC code. This program dumps all RAM contents to the serial port.

<pre>
1 DEFINTA-Z:
OPEN"COM:98N1D"FOROUTPUTAS1:
D$="":
A=FRE("0"):
L=VARPTR(D$)+1:
M=L+1:
POKEL-1,128:
OUT180,4:
OUT181,64:
OUT184,195:
FORI=0TO255:
POKEM,128+I/2:
POKEL,(IMOD2)*128:
PRINT#1,D$;:
NEXT
</pre>

Unfortunately this BASIC code does not transmit the 32K of data any faster than the 19200bps code. Both take about 33 seconds to transmit the image.

So, here's an assembly language version of the same program. It transfers your Model 100's 32K RAM to a serial connection in about 8.5 seconds!

Note that this code obeys the "clear to send" signal from the PC, so given hardware flow control enabled and properly configured on the PC, we should not overrun the remote UART.

Not that if the PC is busy doing something else (like printing to the screen) it might flow control us, and you may not achieve the maximum speed.

<pre>
.org 64704

; select RS232 port
MVI A, $25
OUT $BA

; set up 8N1
MVI A, 28
OUT $D8

; set up 38400 bps
MVI A, 64
OUT $BD
MVI A, 4
OUT $BC
MVI A, $C3
OUT $B8

LXI H,32768

WAITEMPTY: IN $D8
ANI $10
JZ WAITEMPTY

WAITCTS: IN $BB
CMA
ANI $10
JZ WAITCTS

MOV A,M
OUT $C8

INX H
MOV A,H
ORA L

JNZ WAITEMPTY

RET

.END
</pre>

== Data Transmission ==

Once configured, sending a character is simply

MVI 'A'
OUT $C8

or, in BASIC,

OUT 200,ASC("A")

In the UART, there is room for two characters: the character currently be transmitted, and the next one. This permits you to ensure there is always one character waiting in the wings.

You should never overflow the transmission buffers. Either do some other work during the "downtime" and/or wait until there is room by polling bit 4 (0x10) of register $D8. The code that follows just does a "busy wait."

WAITEMPTY: IN $D8
ANI $10
JZ WAITEMPTY

When deciding whether the other device is ready to receive you should also consider the Clear To Send (CTS) flow control line described later in this document.

== Data Reception ==

=== BASIC ROM Interrupt 6.5 Handling ===

Whenever the UART receives another character, Interrupt 6.5 is signalled. Then, if interrupts are enabled, the CPU stops what it is doing and CALLs location 0x0034 in the BASIC ROM. This code disables further interrupts and jumps to the location 0x6DAC.

The ISR then jumps to vector 0xFE5C (0xF5FC?) in RAM. Normally this is just a return instruction, but you could hook the interrupt here. [ stack manipulation to avoid/ or include default processing + re-enable interrupts? - TBD ]

=== Polling Interrupt 6.5 ===

Accepting the BASIC ROM's handling imposes significant overhead. With each interrupt, the instruction pointer must be placed on the stack and a jump performed at minimum. If the BASIC ROM (as opposed to an Option ROM) is switched in, then you will have the overhead of disabling interrupts, a jump to the DR vector, a return instruction, and then the default processing of reading and enqueing the new character. All that, and at this point no useful work has been performed other than to relieve the UART.

For maximum efficiency you may wish to poll Interrupt 6.5 pin rather than accept the overhead of an interrupt. This is made possible by the 8085's SIM and RIM instructions.

Using the SIM instruction, you can set the interrupt mask such that UART DR (data ready), bit 1, will not trigger an interrupt. Then, you can poll this bit using the RIM instruction ANDing with 0x20 to see if DR is set.

Alternatively, you could disable interrupt processing altogether during your polled routine, but still use RIM to poll. This has the disadvantage of disabling the background ISR. But to achieve higher baud rates, you may not want the background ISR running anyway.

== Flow Control ==

The Model T has full support in hardware for the CTS and RTS flow control lines. In the BASIC ROM, however, it is not implemented. Instead the BASIC ROM relies on slow, kludgy XON/XOFF character escapes. This makes it difficult to transmit or receive binary files since the XON/XOFF characters are reserved for flow control.

Since we are discussing direct control of the UART, we can do better and implement full flow control.

=== Detect Clear to Send (CTS) ===

The CTS line is an input to the Model 100. It indicates whether the device attached to the serial port (or the remote equipment behind it) has room to accept new characters. The device can "flow off" the Model T when its receive buffers are full.

Implementing CTS is easy. The following code performs a busy wait on CTS:

<pre>
WAITCTS: IN $BB
CMA
ANI $10
JZ WAITCTS
</pre>

CTS line is read from bit #5 of I/O address 0xBB. Note that it is inverted; if it is 0, the device is signalling "clear to send." If 1, the device is attempting to flow us off from transmitting.

=== Request Peer to Send (RTS) ===

The RTS line is an output from the Model 100 to the device connected on the serial port. It is a signal "requesting" the device to send (or not to send). From the other point of view, the device should transmit if and only if RTS is high. Note that from the device perspective, it sees our RTS as its CTS.

If the device implements hardware flow control, it will not send if our RTS (and probably DTR) signals are low. So, at least we will want to set these two bits.

The RTS and DTR lines are located on I/O register 0xBA (186).

(IN PROGRESS)

== Handling Communication Errors ==

(IN PROGRESS)

== I/O Map ==

Here, for reference, is the serial I/O map:

<table border="1" cellpadding="5" cellspacing="0" style="border-width: thin; border-style: solid; border-color: blue; border-collapse: collapse;">
<tr><td>Name</td><td>Direction</td><td>Port</td></tr>
<tr><td>TX</td> <td>Output</td> <td>$C8 (200)</td></tr>
<tr><td>RX</td> <td>Input</td> <td>$C8 (200)</td></tr>
<tr><td>RTS</td> <td>Output</td> <td>$BA (186), bit 7</td></tr>
<tr><td>CTS</td> <td>Input</td> <td>$BB (187), bit 4</td></tr>
<tr><td>DSR</td> <td>Input</td> <td>$BB (187), bit 5</td></tr>
<tr><td>DTR</td> <td>Output</td> <td>$BA (186), bit 6</td></tr>
</table>

nb: sense on DSR, CTS seem to be inverted. So CTS ==0 means that it is OK to transmit. A '1' means the device is flowing the Model T off.

nb: Port <code>$BA</code> is called "Port B" in the Model 100 Technical Reference. It has other functions than UART control, including the critical Power On/Off line. See [[Model 100 Port B]] for the breakdown.

Direction indicates both data flow, and whether to use an <code>IN</code> or <code>OUT</code> instruction to read/write to the given pin.

[[Category:Model T Developer Reference]]

Model 200 serial interface

2009-03-22T16:13:42Z

78.69.53.223: New page: 82c51

82c51

MTHD

2009-02-22T17:48:51Z

78.69.53.223: New page: This project it still under development. The basic idea for this project is to add a harddrive via the System bus on the 100/102/200

This project it still under development.

The basic idea for this project is to add a harddrive via the [[System bus]] on the 100/102/200

Model T DocGarden

2009-02-22T17:45:49Z

78.69.53.223:

These pages are devoted to the Model T:

TRS-80 Model 100, Tandy Model 102, KC-85, NEC 8201A, NEC 8300, Olivetti M10, Tandy Model 200, and the WP-2

== Classic Article Repubs ==

We hope to republish one or more articles from the Golden Era of the Model T every month:

[[:Category:Model 100 Classics]]

== One-Liners ==

This is a collection of Microsoft BASIC programs that
* Do something interesting or useful
* With only a single line of code

One-liners are bite-sized computer programs on a human scale. You are encouraged to type them in manually (by hand) and study their operation.

[[Model 100/102 Compatible One-Liners]]

== Tandy Disk Drive and Emulators ==

TPDD emulators, in concert with a compatible disk clients like
TS-DOS, TEENY, POWR-DOS, FLOPPY.CO, the Booster Pak, or the
WP-2 built-in Diskette client are the most "advanced" way to
accurately and quickly transfer all file types including binary
files to and from your Model T laptop. There are different
options for the server side on modern operating systems and
devices:

=== Servers ===

The [[:Category:TPDD Service|TPDD Services]] implement the "disk drive" end of the TPDD protocol.

=== Clients ===

[[:Category:TPDD Client|TPDD Clients]] are software that runs on your Model T laptop. The communicate with a disk drive or other [[:Category:TPDD Service|TPDD Service]] to save and load files.

=== Real TPDD and TPDD-2 ===

[[Differences]] between TPDD-1 and TPDD-2

== Simple Text File Transfer (No Client) ==

You can use any "terminal program" to transfer text files to
and from your Model T laptop. Here are some tutorials:

[[Text File Transfer using Hyperterminal]]

[http://web.mac.com/lorddoomicus/Doomd/Blog/Entries/2006/9/10_Connecting_a_Tandy_102_Computer_to_a_Mac.html Text File Transfer to Mac using Z-Term]

== File Storage using MP3 Player ==

[[File storage with mp3 player]]

== Model T Software ==

[[VirtualT]] Model 100/102, T200, NEC 8201A, M10 emulator

[[mtcpm]] CP/M for the Tandy 100/102/200

[[RAM4TH]]

== Model T Hardware Hacks and Troubleshooting ==

[[Splitting the Model 100/102/200 case]]

[[Recovering an Unresponsive Laptop]]

[[International Keyboard Support]]

[[Repairing Problem Keys]]

== Model T Hardware Projects ==

[[Remem]] is the ultimate Model T memory upgrade

:[http://lists.bitchin100.com/listinfo.cgi/remem-users-bitchin100.com remem-users mailing list] This is a support list for remem users.
:[[Remem Software HOWTO's]]

[[REX]] is a flash OptROM emulator/switcher

[[REX2]] is a upcoming flash OptROM emulator/switcher with support for a 64K all-RAM mode. This permits running with a patched main ROM, or the upcoming [[mtcpm]] (Model T CP/M)

[[NADSBox]] is a stand-alone TPDD emulation device that uses SD cards

[[Mikrokolor]] Is a Color Graphics interface for the Model 100. Allows for 40x80 character graphics/text

[[MTHD]] Is a how to add a Harddrive to your Model T

== Model T Developer Reference ==

[[:Category:Model T Developer Reference]], articles on Model T programming topics

== Other Topics ==

== Model T Links ==

[http://club100.org Rick Hanson's Club 100]

[http://www.istop.com/%7Esadolph/remem_home.html Steve Adolph's Remem Site]

[http://sliderule.mraiow.com/wiki/Portable_Computer_Index#T Chris Osburn's Calculating Instruments]

[http://kenpettit.com/projects.html Ken Pettit's Model T Projects]

Model T System bus

2009-02-21T18:25:10Z

78.69.53.223:

The system bus differs on the different models but are very close electrical wise.

The M100 has a 40-pin DIP socket while M102 and T200 have a 20x2 (2.54mm/0.1") pin array.

The differnet pin arangements cause the pins of the 100 to be numbered differently to the 102/200.

<table border="1">
<tr><td></td><td>100</td><td>102</td><td>200</td></tr>
<tr><td>1</td><td>VDD</td><td>VDD</td><td>VDD</td></tr>
<tr><td>2</td><td>GND</td><td>VDD</td><td>VDD</td></tr>
<tr><td>3</td><td>AD0</td><td>GND</td><td>GND</td></tr>
<tr><td>4</td><td>AD2</td><td>GND</td><td>GND</td></tr>
<tr><td>5</td><td>AD4</td><td>AD0</td><td>AD0</td></tr>
<tr><td>6</td><td>AD6</td><td>AD1</td><td>AD1</td></tr>
<tr><td>7</td><td>A8</td><td>AD2</td><td>AD2</td></tr>
<tr><td>8</td><td>A10</td><td>AD3</td><td>AD3</td></tr>
<tr><td>9</td><td>A12</td><td>AD4</td><td>AD4</td></tr>
<tr><td>10</td><td>A14</td><td>AD5</td><td>AD5</td></tr>
<tr><td>11</td><td>GND</td><td>AD6</td><td>AD6</td></tr>
<tr><td>12</td><td>/RD</td><td>AD7</td><td>AD7</td></tr>
<tr><td>13</td><td>IO/M</td><td>A8</td><td>A8</td></tr>
<tr><td>14</td><td>ALE</td><td>A9</td><td>A9</td></tr>
<tr><td>15</td><td>CLK</td><td>A10</td><td>A10</td></tr>
<tr><td>16</td><td>/A</td><td>A11</td><td>A11</td></tr>
<tr><td>17</td><td>INTR</td><td>A12</td><td>A12</td></tr>
<tr><td>18</td><td>GND</td><td>A13</td><td>A13</td></tr>
<tr><td>19</td><td>RAMRST</td><td>A14</td><td>A14</td></tr>
<tr><td>20</td><td>NC</td><td>A15</td><td>A15</td></tr>
<tr><td>21</td><td>NC</td><td>GND</td><td>GND</td></tr>
<tr><td>22</td><td>NC</td><td>GND</td><td>GND</td></tr>
<tr><td>23</td><td>GND</td><td>/RD</td><td>/RD</td></tr>
<tr><td>24</td><td>INTA</td><td>/WR</td><td>/WR</td></tr>
<tr><td>25</td><td>/RST</td><td>IO/M</td><td>IO/M</td></tr>
<tr><td>26</td><td>/YO</td><td>S0</td><td>S0</td></tr>
<tr><td>27</td><td>S1</td><td>/ALE</td><td>ALE</td></tr>
<tr><td>28</td><td>S0</td><td>S1</td><td>S1</td></tr>
<tr><td>29</td><td>/WR</td><td>CLK</td><td>CLK</td></tr>
<tr><td>30</td><td>GND</td><td>Y0</td><td>/IOCONT</td></tr>
<tr><td>31</td><td>A15</td><td>/A</td><td>E</td></tr>
<tr><td>32</td><td>A13</td><td>/RESET</td><td>RESET</td></tr>
<tr><td>33</td><td>A11</td><td>INTR</td><td>INTR</td></tr>
<tr><td>34</td><td>A9</td><td>INTA</td><td>/INTA</td></tr>
<tr><td>35</td><td>DA7</td><td>GND</td><td>GND</td></tr>
<tr><td>36</td><td>DA5</td><td>GND</td><td>GND</td></tr>
<tr><td>37</td><td>DA3</td><td>/RAMRST</td><td>/RAMRST</td></tr>
<tr><td>38</td><td>DA1</td><td>NC</td><td>NC</td></tr>
<tr><td>39</td><td>GND</td><td>NC</td><td>NC</td></tr>
<tr><td>40</td><td>VCC</td><td>NC</td><td>NC</td></tr>
</table>

[[Category:Model T Developer Reference]]

Model T System bus

2009-02-21T17:36:46Z

78.69.53.223: New page: The system bus differs on the different models but are very close on electrical signals <table> <tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr> </table>

The system bus differs on the different models but are very close on electrical signals

<table>
<tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
</table>

MTCPM Project HOWTOs

2009-02-20T19:48:47Z

78.69.53.223:

Here is a list of how to set up all ram mode.

1) start VT 1.3

2) emulate M100 or T102, whatever

3) turn on ReMem emulation -
Emulation --> Memory options: select ReMem, click ok

4) configure ReMem : tools --> remem configuration:
- first, click Default Map - this will do an initial set up
- next, on the left column, select MAP0
- on the second left column, sleect 100-13F OPT
- on the right, de-check sector lock, De-check RAM CS, check Flash 1
and check flash 2
- map data should be unchanged, and read 0x020
- select copy sequential
Now, you should see Map 0, 100-13F OPT with data 0x1820, 0x1821 etc

Finally, select Save Map on the left, and close the window.

5) loading a CP/M image into the "option rom"
- tools --> memory editor
- select region RAM
- File --> load from file
- enter the full path name for the binary CP/M image
- start address should be 0x008000
- select ok

Now, the binary image is loaded at offset 008000 in the RAM region.
You can check this by scrolling down.

6) activating the CP/M option rom
- enter BASIC
- type OUT 112,1
(this activates ReMem map 00)
- type CALL63012
(this will start the option ROM)

DONE! you are now running CP/M.

MTCPM

2009-02-17T20:21:21Z

78.69.53.223:

Mtcpm ( Model T CP/M ) is a project to create a working version of CP/M on the Model T.

If you want to help out join the [http://lists.bitchin100.com/listinfo.cgi/mtcpm-bitchin100.com Mtcpm mailing list]

Subversion source code [http://svn.bitchin100.com/mtcpm repository]

To download:
<code><pre>
svn co http://svn.bitchin100.com/mtcpm
</pre></code>
Ask on the mailing list if you need commit (check-in) privileges

{| border="1"
|+ Goals and Status
! Project !! Sub project !! Status !! Comments
|-
| Main system || BIOS || bgcolor="yellow" | Underway || Conout
|-
|
| CCP || bgcolor="yellow" | Underway || Waiting for Conin
|-
|
| BDOS || bgcolor="yellow" | Underway || Some functions
|-
|
| Filesystems || bgcolor="yellow" | Underway || Hardware required
|-
| Software || Text Editor || bgcolor="red" | Unknown
|-
|
| ASM || bgcolor="red" | Unknown
|}

== CP/M Resources ==

[http://www.retroarchive.org/cpm Retroarchive] Archived CP/M binaries and docs

[http://www.cpm.z80.de The Unofficial CP/M Page]

[http://www.seasip.demon.co.uk/Cpm CP/M Main Page]

[[Project HOWTOs]]