[Karen O]

You've just finished your beautiful, faithful reproduction of an SC/MP computer running NIBL BASIC!

Fine - now to interface it to your PC so that you can converse with it. An RS232 level driver and receiver on the F0 and SB flags should do the trick. Bish bash bosh, job's a good'un! But it don't work. Your PC terminal emulation is flooded with NULs due to a permanent 'break' condition on the serial line going from NIBL computer to PC. It turns out that the serial stream emerging from F0 is inverted by modern standards. It is quiescent low rather than high. A simple inverter made from a spare gate or transistor is all that's needed to rectify the problem. But it still don't work.

After much wailing and gnashing of teeth you deduce that your USB-to-serial dongle doesn't support 110 Baud. There's no error message when you select this Baud rate; the dongle or whatever quietly substitutes another Baud rate hoping that you don't notice(!) You are faced with a choice: obtain a vintage PC with a real serial port, or modify your NIBL binary so that NIBL converses at a higher Baud rate (say: 1200 Baud). I think most of us would choose the latter, but it is annoying because you put so much effort into making your NIBL computer authentic, and now you're using a non-original Baud rate.

There is another drawback of upping NIBL's Baud rate too, which will become apparent when trying to use NIBL. NIBL monitors the serial line from the terminal (PC) while LISTing so that you can break from listing (e.g. to stop it scrolling off your terminal's screen). At 110 Baud this is quite responsive but at 1200 Baud, NIBL is less likely to notice you jabbing at the keyboard because the serial line is active for a much shorter time. Oh well, we'll just have to hammer furiously on a key to break from LISTing.

Modifying NIBL for different Baud rates can be done by a few edits of the binary (possibly through an EPROM programmer's keyboard interface). Ronald Dekker provides a table of the changes required on his 'dos4ever' web site.

Great! You are conversing at last! You enter a NIBL program, then capture it to a file on your PC by setting NIBL up for LISTing then capturing the listing using the terminal emulator's text capture facility. You have to edit the text file because it contains an extra prompt '>' at the end, but by and large getting a program from NIBL computer to PC text file is trouble-free.

Not so going the other way - when you ask the terminal emulator to send a program text file for the purpose of reloading it into the NIBL computer, NIBL is quickly overwhelmed. Characters are lost or corrupted leading to complaints of 'SNTX ERROR' as NIBL tries to parse nonsense. Fortunately, your terminal emulator includes features to slow down text sending to avoid such overrun. The terminal can arrange to insert user-specified delays after both individual characters and line end (carriage return). The per-character delay can be set to something like 80 millisec so as to bring the overall character throughput back to 110 Baud levels. A delay of 100 milliseconds after each carriage return provides time for NIBL to process each program line as it comes in. This works - for now.

One day you enter a particularly large program. You save it to text file on your PC, and then later reload it. All seems fine - until you run the program, when a syntax error is revealed in one of the higher-numbered program lines. Clearly, NIBL was overrun while loading, but not to an extent that it revealed itself during the loading process. It is at this point that you realise that NIBL does NOT check syntax of programs as they are entered. You can enter nonsense program lines, and NIBL will still accept them provided they have valid line numbers. This means that an apparently successful load is not necessarily corruption-free.

You are getting annoyed by this overrun hazard and start looking into methods of flow control to prevent the problem entirely. You learn that the F1 flag acts as a hardware flow control signal of sorts: the original conception of NIBL is that it works in conjunction with a teletype (ASR 33 being particularly popular). When loading from paper tape, the F1 flag should be wired to a 'reader relay' which starts and stops the paper tape reader so that NIBL can 'throttle' the reader and prevent itself from being over-whelmed. This worked extremely well. So, why can't we apply the same principle to loading from a PC terminal emulation program?

As it happens, the F1 flag changes state in much the same way as an RTS flow control signal on a serial port. In theory, we would just need another RS232 driver to return F1 as RTS on a serial link with RTS/CTS flow control, and our overrun problem is solved! Trouble is, it doesn't work. Some USB serial dongles don't implement hardware flow control properly and lose characters. Others respond but far too slowly leading to characters being sent when NIBL isn't ready. You may find that legacy 'COM' ports work more reliably, but may still take up to 16 characters to respond to RTS due to FIFO memories within the serial interface chip. In short: NIBL requires flow control which responds INSTANTANEOUSLY but most (all?) serial ports have some latency which means that they can't meet this stringent requirement.

It is at this point that we revisit those per-character and per-carriage return delay settings in the terminal emulator. My study of the NIBL code suggests that NIBL is pretty quick to respond to individual key strokes, but requires a very significant time to add a complete line to the program. Accordingly, we double the end-of-line delay, and accept that loading of shorter programs is going to take much longer than strictly necessary, all in the interests of loading larger programs reliably. This then is a condensation of my experience with driving NIBL over the years.

PROPER SOLUTION

I propose a PIC-based interface which accepts SC/MP F0, F1, and SB flags on one side and presents standard serial I/O on the other. The latter would use an RS232 interface chip, such as the MAX232 and connect to a standard DTE 9 way connector for easy connection to a PC. The PIC would perform Baud rate translation (110 Baud to the NIBL computer, 1200 Baud to the serial connector). It would also perform the critical flow control in conjunction with the F1 'reader relay' signal.

The method of flow control between PIC and PC would be either XON/XOFF in-band flow control or by use of a humungous buffer memory. Hardware flow control would NOT be used between PIC and computer because I have not found this to be reliable enough. A large buffer memory is a practical solution, because the largest NIBL program you can load at one time is 4096 characters (this is due to the SC/MP's paging of memory). A buffer of 8kbyte would be guaranteed to feed all characters through to the NIBL computer without loss. This has the advantage of requiring no flow control at all between PC and PIC, but would need an additional memory chip.

Wa'd'ya think, guys?