NSC800 Conversion

Work in progress!

File:NSC800.png

What is this all about?

External serial bidirectional communication on the Model 100 today is limited to (1) the RS-232 port and (2) the modem port, both of which use the single UART in the computer.

This hack enables the BCR port to send and receive half duplex serial TTL signals. The BCR port is already set up for TTL receive function as this is used for the Bar Code Reader function. So this hack provides facility to transmit as well. In addition I provide some software routines that demonstrate the capability.

BCR port serial TTL is supported in Model 100 CP/M as well as with the VT100 Driver, for use with VT100 Terminal or other VT100 CRT solution.

Get in touch with me at Twospruces at --the google mail service.

Acknowledgements

I would like to acknowledge and thank those that have contributed to the project:

Philip Avery - for efforts with CP/M and attached Video using the VT100 Adapter

Supported Models

• TRS-80 Model 100
• a hardware hack for T102 is likely however not explored at this time
• a similar hack should be possible for all ModelT versions.

The Hardware Modification

UDPATE: an improved implementation is being tested, which is more universal. SOD pin is available on 80C85 but not Z80. As such, there is a change where we can utilize /Y1 signal...making this hack accessible with both NSC800 and 80C85.

The core of the modification is to connect pin 3 of the BCR port to the SOD output of the CPU. This is accomplished by adding a single wire to the PCB.

  This page details the hardware change required to transmit at 57600 baud with minimal changes.
  It can be demonstrated that, in the M100, both serial Tx and Rx is possible at 57600 over the BCR port.

  Tx and Rx at higher speeds is more challenging.  Tx speeds of up to 128000 baud have been demonstrated.
  Transmission at this rate requires disconnection of the cassette port Tx filter at C63.
  If you remove C63 you get better signal quality for TTL serial, but the cassette port is no longer usable.
  If, like me, you never use the cassette port they it may not be a big deal.

The following image shows the modification to the M100 Cassette/BCR port circuitry.

Here we see a strap added from pin 12 of M34 to pin 3 of the BCR port, defining this pin as Tx data.

The following image shows the placement of the strap on the secondary side of the M100 PCB.

The Software

As mentioned, the use of the BCR port to send TTL data to the external CRT is supported in Model 100 CP/M, as well as by using the VT100 Driver, which integrates the external CRT with BASIC, based on Microsoft Disk BASIC for the Model 100.

Additionally, I include some code here as examples.

57600 Baud Routines

Currently both CP/M and my own VT100 driver user 57600, using the modification posted here.

The following code can be compiled, and run in Model 100 to demonstrate transmission between 2 machines at 57600.

Tx routine:

   keysnd_57600.asm

Rx routine:

   bcrx_57600.asm

I may have done the M100 <--> M100 testing using an improved circuit (IE remove C63). I'm not sure; if you do try this experiment keep it in mind that the Tx signal quality is better if you pull C63. This of course makes the cassette port useless.

Higher speed Tx Routines

Faster transmission is possible; both 115600 and 128000 baud have been demonstrated. The core Tx routines are provided here.

for Tx at 57600 baud:

   bcrtx_57600.asm

for Tx at 115600 baud:

   bcrtx_115600.asm

for Tx at 128000 baud:

   bcrtx_128000.asm

Timing for 57600 Baud

Since the processor is 100% busy reading in bits during Rx functions, the requirement for the BCR port receiver is to read and place the byte into memory before the stop bit is completed. The faster the Rx can process the received byte, the faster the link rate can be. At 57600 baud that is about 17 microseconds. Typical processor instruction time is between 1.2 and 1.6 microseconds, so this is about 10-12 instructions max (42.65 clock cycles). I think that is enough time to write to memory and increment a counter or a parity, and a jump or 2. 57600 baud then looks feasible, even for large memory transfers so long as the buffer can be continuously written to without interruption while the PC is sending data. It also means that the RS-232 port could run flat-out at 5.7 kBytes/sec in the Rx direction. In the Tx direction it similar, but it takes a small amount of time to prepare the data before sending the start bit and following data bits. I think it is probably better than 5.5 kbytes/sec.

For CP/M and REXCPM backup/restore this means

  4MB backup restore time could be about 12 minutes @57600 baud
   -- assuming "large packet support" on LaddieAlpha, and direct writes to block RAM.

What about 115600 or 128000 baud? While the Tx side has been shown to work, the Rx side is the challenge. Challenge 1. The M100 ROM requires an initial interrupt and then 3 jumps to get to the RST6.5 hook. The M100 has to make it to the RX code before the data arrives. This places a practical limit of 57600 on the rate. 76800 is too fast. However if an option ROM was used this could potentially be sped up.

A quick look at BCRX.ASM above suggests the RX bit reception time could be reduced to 29 clock cycles, supporting ~85000 baud.