[Karen O]

Hi Guys,

Confession: I have a longstanding obsession with microcomputers that are serially coupled to a separate terminal, such as National Semiconductor's conception of a NIBL computer as a board that you connect to a teletype. I'm not sure why this aspect of early microcomputing fascinates me. Perhaps it is me trying to re-connect with very early machines like the MITS Altair 8800...?

Another (connected) subject which fascinates me is the implementation of a cassette interface as a serial peripheral, rather like a modem. The pursuit of these ideas culminated in the construction of my 'Orton ASR33 terminal' a year or two ago (photo attached). This terminal has a cassette mechanism that is able to record and play back 110 Baud serial data in a manner similar to the paper tape punch and reader on a real ASR33. My plan was to use this set up in conjunction with my emulation of a 4MHz SC/MP running NIBL BASIC.

Since my terminal uses tape to record and retreave programs, loading a program is done by exposing the NIBL computer to its own LISTing output, which is replayed verbatim. In other words, inter-character gaps that would be eliminated by a PC terminal emulation are preserved by tape playback. The big obstacle of course is the likelihood of over-run on playback, due to the time NIBL needs to enter a new line into the program text. My solution thus far: a great big FIFO buffer! It works but is unattractive to me because it has no parallel with the early microcomputer era (this FIFO probably has more memory than your typical microcomputer of the mid- to late- seventies!)

A thought occurred to me recently that allows for a conceptually simpler solution. I did a careful study of the NIBL 'PUTC' routine (that which serialises characters for sending to the serial terminal). I discovered that it imposes something like 2.5 stop bits on the serial output! This generous spacing of characters really does ensure that NIBL can keep up on a character-by-character basis when being exposed to its own LISTing output. No trouble there then. The remaining problem is the time required for complete line entry, and that is where my attention is drawn to the line feed (LF) characters NIBL generates at the end of each listed line.

NIBL has to append LFs when listing, otherwise the displayed lines would be over-printed on top of one another. But when LISTings are replayed for program loading purposes, these LFs are not needed. In fact, NIBL ignores them. So how about we delete them during or after recording? This won't affect program loading but has the benefit of inserting 100 milliseconds of serial silence at the end of each program line. I did a careful study of my NIBL emulation: I wrote a NIBL program which plants a 400 line NIBL 'program' in one of the other NIBL pages. I then observed how long NIBL took to add another line to this 'extreme program' by monitoring the 'reader relay' output on flag F1 on my 'scope. I conclude that, for a 4MHz SC/MP, 100 milliseconds is enough time for NIBL to load an additional program line onto an already humungous program.

So that is my new tack and I'm modifying my 'ASR33 terminal' accordingly. I'm installing a line feed deleter in the record path of the cassette interface! I like this solution because it could have been implemented (at moderate complexity) in the early microcomputer era. I have already put together a design based on the HD6402 CMOS UART chip!