UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 29th Jun 2020, 11:46 pm   #1
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 605
Default Orton's rant on serial connection of NIBL computers to modern terminal emulations

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?
__________________
Karen O

Does Dr Who use Old New Stock parts for his/her Tardis?
Karen O is offline   Reply With Quote
Old 30th Jun 2020, 1:00 am   #2
Mark1960
Triode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 22
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

Hi Karen
Did you consider using a PIC18F14K50?

Usb interface from the pc then a slow serial interface to the sc/mp.

The evaluation kit has example code, but not sure if it included 110 baud.

Mark
Mark1960 is offline   Reply With Quote
Old 30th Jun 2020, 1:50 am   #3
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 4,220
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

I've used a microchip 23LCV512 (SPI interface SRAM) as a big serial receive buffer on a recent (non PIC) project. Although a current part, it is happy to run on either 3V3 or more importantly for our usual purposes, 5V.

It can be accessed at speeds approaching 20MHz so in theory you can always stuff a received byte into it in less time than it takes to fully receive the next serial byte even at fairly high baud rates.
SiriusHardware is online now   Reply With Quote
Old 30th Jun 2020, 1:54 am   #4
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 605
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

What are you're thoughts about use of XON/XOFF flow control?

I suspect that this is a feature handled in the serial port driver, and therefore less affected by dodgy hardware...?
__________________
Karen O

Does Dr Who use Old New Stock parts for his/her Tardis?
Karen O is offline   Reply With Quote
Old 30th Jun 2020, 4:46 am   #5
TonyDuell
Dekatron
 
Join Date: Jun 2015
Location: Biggin Hill, London, UK.
Posts: 3,761
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

That's one reason I have real vintage terminals here, including a DEC VT100 (actually a VT105). Although I am surprised by the number of vintage-ish devices that can't handle 110 baud.

However, strictly RTS/CTS (or DTR/DSR) are not flow control lines. Remember that originally the RS232 interface was used between a terminal and a (dumb) modem. The latter could not do any form of buffering, and therefore there was no flow control between the terminal and the modem. Flow control is between the terminal and the computer/terminal/whatever at the far side of the distant modem. Therefore any flow control has to be able to be transmitted down the telephone line. So Xon/Xoff or whatever. Yes, these signals are commonly _misused_ as flow control lines (I do it myself...) but you can't moan when they don't work.

That said, I'd probably go for the large buffer RAM on the interface PIC solution. It will work with anything, no matter if it correctly handles Xon/Xoff or not. And there are plenty of serial devices that don't (no matter what the documentation says!)
TonyDuell is offline   Reply With Quote
Old 30th Jun 2020, 10:21 am   #6
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,817
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

The joys of serial comms!

This is what I was hoping to do with my some Arduino setup but not quite managed yet. If I get it working I will report back I'm now starting to suspect the Arduino library for serial is doing something off with the slower baud rates I'm running at 4MHz .'. 220 baud. Maybe I should try 110. I may try a bare metal version if I get time.

My other option might well be to use a FT245 module....not authentic but then neither would be an Arduino, PIC or multi-terabyte PC.

Another thing you might consider is writing your own loader on the PC (or PIC or whatever). It seems the variable delay needs to be at the end of each line so wait for the > prompt before sending the next line.... you could even check the echoed characters?
dominicbeesley is offline   Reply With Quote
Old 2nd Jul 2020, 1:57 pm   #7
Slothie
Hexode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 368
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

I did in the past create a AVR based serial to parallel converter for a paper tape punch that used a 64 byte circular buffer to hold the incoming serial data until the punch was ready for it and used RTS flow control. After signalling the computer to stop often several characters would arrive before the flow stopped, hence the buffer. Something similar would be ideal for our NIBL computers and would probably not be to hard. I imagine using the hardware serial fior the computer link and a software serial fit the 110 baud link to the NIBL machine.
Slothie is online now   Reply With Quote
Old 2nd Jul 2020, 4:42 pm   #8
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 605
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

Quote:
I imagine using the hardware serial fior the computer link and a software serial fit the 110 baud link to the NIBL machine.
You read my mind, Slothie!

I've developed some PIC code to use the on-chip serial port for 1200 Baud PC comms and a software serial port for 110 Baud NIBL comms. I'll report back when I've got some results.
__________________
Karen O

Does Dr Who use Old New Stock parts for his/her Tardis?
Karen O is offline   Reply With Quote
Old 3rd Jul 2020, 4:34 pm   #9
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,817
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

I got something working the other day - I've not tested it fully in anger for want of a long BASIC program listing to try it out on but it does seem to work. If there's interest I'll post it up this weekend?
dominicbeesley is offline   Reply With Quote
Old 3rd Jul 2020, 6:06 pm   #10
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 605
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

Hi Dom,

Interesting!

How've you handled flow control?
__________________
Karen O

Does Dr Who use Old New Stock parts for his/her Tardis?
Karen O is offline   Reply With Quote
Old 3rd Jul 2020, 10:21 pm   #11
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,817
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

Sorry, it seems I'd started discussing this on the wrong thread - there's some more stuff on my timing thread.

Attached are two Arduino sketches. The PC end of the connection relies on the Arduino's built in USB serial port, which can either be accessed with the Arduino serial monitor or your favourite terminal program - I tend to us PUTTY or when loading a program just copy to the COM: in command prompt.

The arduino_serial_brk sketch needs a board with two hardware UARTS and includes a simple inverter so that the inverted TX signal from the SC/MP can optionally be fed in without an inverter. It seems to work well enough the only "clever" bit is that if you send a CTRL-C it will continually send 0's until the SC/MP activates the reader relay (to avoid having to bash away at the keyboard). The flow control is dead simple as it just waits for the relay unless the character is CTRL-C. I'm sure there probably needs to be something more complicated to allow for unlocking and I've not checked that this works in all cases - it probably doesn't but has at least allowed loading/saving simple programs but I've not tested on anything large. The flow control relies on a delay after sending a character of ~100ms (probably longer than it needs to be) so we don't queue another character until NIBL has had a chance to do its thing with the RELAY signal. I'm sure this could easily get stuck but so far I've not encountered any problems.

The other, unfinished, sketch is for a board with a single UART (at the USB end) the other one is an interrupt driven bit-bang port. I've not added flow-control to this yet but it would work very mutch like the other one. It took me a while to work out that I needed this interrupt driven approach as NIBL echoes each bit as it is read during input!

I'm sure this a bit naive and you could do much better but it got me a bit further in my testing. The interrupt driven version should be easy enough to assert a proper break condition on the line which seems as good a way of stopping NIBL when its running - or am I missing something?

I've got work to do this weekend but I hope to be back to looking at the timing of the SC/MP next week and hopefully progress a bit with the Verilog emulation. I'll no doubt be back with daft questions about the bus arbitration and control signals - I'm not sure how to test these on my simple breadboard computer.

D
Attached Files
File Type: zip scmp_serial_brk.zip (1.2 KB, 1 views)
File Type: zip scmp_serial_interrupt.zip (1.6 KB, 1 views)
dominicbeesley is offline   Reply With Quote
Old 5th Jul 2020, 8:48 pm   #12
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 605
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

Don't worry, Dom.

I think that there are more topics than threads going on here at the moment

But, by and large, we're managing to stay on topic. I broke this topic off as a separate thread so as not to pollute any of the others.

Another 'feature' of NIBL is its internal trick of setting the top bit of a byte to denote the end of a string (its more memory efficient than using a terminating CR or NULL).

Only trouble is, these set top bits are of a habit of getting out onto the serial line, and this can confuse your terminal emulator. So, if you're getting back a mixture of correct text and strange characters, you need to set your terminal emulator to ignore the top bit (i.e. select 7 bit ASCII).

Yet another hazard of comms with NIBL BASIC!
__________________
Karen O

Does Dr Who use Old New Stock parts for his/her Tardis?
Karen O is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 1:32 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Copyright ©2002 - 2020, Paul Stenning.