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: 653
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: 29
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,327
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: 653
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,821
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,832
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: 387
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 offline   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: 653
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,832
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: 653
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,832
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, 12 views)
File Type: zip scmp_serial_interrupt.zip (1.6 KB, 9 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: 653
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
Old 8th Jul 2020, 1:05 am   #13
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 653
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

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!
Attached Thumbnails
Click image for larger version

Name:	Orton ASR33 terminal.jpg
Views:	31
Size:	54.0 KB
ID:	210512  
__________________
Karen O

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

I was wondering if you had considered, as the 6402 does not require software initialisation, it could be set up with fairly simple hardware to bootstrap the processor on a ram only system.

Either by setting up the processor to read from the 6402 instead of memory, until a flag is set, then send it instructions to write to memory.

Or write all data received by the 6402 to memory and force nops on the processor to increment the address, but this might need a fixed data length counter.

Both of the above would use the 6402 rx data ready to hold the processor on each fetch until the data is available.

This would be a more retro version of my system of using an ft245 on a z80.
Mark1960 is offline   Reply With Quote
Old 8th Jul 2020, 11:00 pm   #15
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 653
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

Please disregard my last post to this thread.

I've got it all completely wrong.

My brain is becoming addled
__________________
Karen O

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

What went wrong? I'd be interested to know.

What have you used as your test program? Would you be able to post it up? I'd like something to test my break condition idea against.

Would a relay to stop the tape work - as used in the BBC Micro? I suppose a longer lead in would be required though...
dominicbeesley is offline   Reply With Quote
Old 9th Jul 2020, 8:31 pm   #17
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 653
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

Hi Dom,

A NIBL computer using a 4MHz SC/MP II and using 110 Baud serial routines requires 400 milliseconds to enter a new line into a program. How I came to believe that figure was 100 milliseconds, I don't know. Certainly, erasing Line Feeds is NOT going to liberate the time needed by the SC/MP to process new line entry.

To determine the 400 millisecond figure, I entered a NIBL program which creates a 400 line NIBL program in one of the other pages. It takes ages to run, but it works! Here's the program:

(Entered and run in Page 3)

10 P=#4002
20 FOR N=1 TO 400
30 @(P)=N/256
40 @(P+1)=N AND 255
50 @(P+2)=10
60 $(P+3)="ABCDEF"
70 P=P+10
80 NEXT N
90 @(P)=255
100 @(P+1)=255
__________________
Karen O

Does Dr Who use Old New Stock parts for his/her Tardis?
Karen O is offline   Reply With Quote
Old 9th Jul 2020, 11:41 pm   #18
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 4,327
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

To this day I still much prefer BASIC for knocking up little problem solvers like that, although I usually use QBASIC which a couple of my Win 98 machines have on.

Python should be the modern equivalent but it's just weird enough to send me running back into the soothing embrace of BASIC whenever I get stuck. I only persevere with Python if I'm writing something which someone else might need to be able to run.
SiriusHardware is online now   Reply With Quote
Old 18th Jul 2020, 7:41 am   #19
Karen O
Heptode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 653
Default Re: Orton's rant on serial connection of NIBL computers to modern terminal emulations

I've discovered something which I think should go into this thread:

Quote:
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).
It is true that NIBL can generate serial characters with bit 7 set, but the reason is nothing to do with how NIBL stores strings. All ECHOED characters have the top bit set! The relevant subroutine 'GECO' (get character and echo it) reads in a typed character and echoes it bit at a time. In other words, it samples each bit of serial input and immediately echoes the bit without waiting for the whole character to come in. This is probably to eliminate annoying delay on an already slow comms system (10 characters per second)

It seems that the GECO subroutine is so eager to get back to processing that it begins the stop bit just as soon as bit 7 has been sampled. The result is echoed characters with bit 7 set. This premature bit 7 cum stop bit is completed by a delay at the beginning of GECO - a funny way of doing it but probably with reason behind it.

ASR 33 teletypes were upper case only machines and doubtless ignored bit 7 but our modern terminal emulators often need to be told to ignore bit 7 ('7 bit ASCII').
__________________
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 2:33 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.