View Single Post
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,885
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, 115 views)
File Type: zip scmp_serial_interrupt.zip (1.6 KB, 92 views)
dominicbeesley is offline