2020-04-25

Soldered on the simple 9995 board:

• U1 TMS9995 socket
• U2 ROM socket
• U3 32K RAM
• U4 74LS04
• U5 74LS32
• U6 MAX232 socket - omit because using FTDI cable
• U8 74LS138
• C10-14 omit because using FTDI cable
• U2 ROM socket
• U3 32K RAM
• U4 74LS04
• U5 74LS32
• U6 MAX232 socket - omit because using FTDI cable
• U8 74LS138
• C10-14 omit because using FTDI cable

2022

• U7 TMS9902 socket, other bits.
• C1,2 15p for crystal X1 12MHz (or maybe 11.0592 or 12.288 MHz)
• C3-C9 100n decouplers, I have plenty.
• C15 big decoupler, any big one will do.
• R6 10k for reset pull-up or use a reset chip.

2022-09-30

• R1-5 1k pull-up unused CPU lines.
• Modified MAX232 site for FTDI cable.

2022-10-15

• Program ROM with monitor and BASIC code.

2022-10-15

• Modify EPROM socket for 32K EEPROM

2022-11-21

TMS9902 fitted, but no serial I/O seen.

2022-11-24

EEPROM socket pin 27 changed from /WR to VCC. May have been corrupted, so I reprogrammed it. Got partly garbage characters with the common 9600-8-N-1 setting. Followed web page and set it to 9600-7-E-2 setting. Success, the sign-on message appeared.

2022-11-26

115200 is the highest baud rate. It copes with a low character rate, and accepted my typing

 10  PRINT "HELLO WORLD! "
 20  GOTO 10

but when I copied and pasted the same text, I got 

0 RT"EOWRD" 0GT 0

which shows it cannot process incoming text at that rate.

At 9600 baud, I got

10  PRT "HELO WORLD " 

which is a little better. At 4800 baud:

10  PRINT "HELLO WORLD! "
0  GOTO 0

At 1200 baud:

 10  PRINT "HELLO ORLD! "
2  GOTO 10

Even at 300 baud, characters are missed. It clearly needs flow control, but RTS and CTS are joined at the UART.

Stuart Conner said that most terminal programs let you set inter-character and inter-line transmit delays. However, the 300 baud rate slows the character rate to around 30 characters per second which is 33 ms each. That should be plenty of time.

Characters are missing in the middle of lines, when the CPU has nothing to do but put them in a buffer. It is not due to the CPU taking a long time to parse a line of BASIC.

The software solution would be to modify the firmware to have interrupt-driven serial input, so that characters would be buffered as fast as they came in, but it will take me a long time to modify code for a CPU I have no experience of. I'd have to add CTS/RTS handshaking but FTDI USB cables don't stop sending bytes until up to 3 bytes after being told to stop.

My favoured solution would be to get the CPU talking to an FTDI USB FIFO module. No baud rate hassles, not RS232 voltages and buffers, and dead easy to interface.