• Please review our updated Terms and Rules here

ZX-81 RS232 option?

D

Divarin

Veteran Member
Joined
Mar 9, 2019
Messages
631
Location
Cleveland, OH
I've posted about this once before but never got a response so I thought I'd ping the community once again.

Is anyone aware of a rs232 interface for the ZX-81 (or Timex Sinclair 1000, same thing).
Or any modern wifi "modem" options?

I have found an old article describing such a device (https://www.worldradiohistory.com/Archive-Hands-On-Electronics/Hands-On-1985-Spring.pdf, page 65)
However it looks to me like it might be a bigger project than I'm able to take on right now, so I'm looking around for other alternatives.
 
I've never heard of such an interface and I'm a long time Sinclair fan, but that doesn't mean they didn't exist - a lot of stuff was lost to history around the zx80 and 81.

It's not difficult to connect something like an 8251 to the zx80 and use it as a serial transceiver, but the ROM won't support it, and there's nothing like the Interface 1 for the zx81.

That means either programming the chip directly from machine code, or via IN and OUT from basic. That's doable, though would require you to wire up an interface still.

You have enough port pins at the edge connector to wire up a serial chip, and then all you need is some basic port decoding, maybe a QUAD OR gate would do it, and a hex inverter, and that's enough to build an oscillator too, for the clock input to the serial chip - so the whole thing is about 3 chips to get to TTL serial, and four chips ( add a MAX232 ) if you want to connect to a printer rather than a PC serial interface with TTL signals. A lot simpler than the provided schematic.

There were also some modems - I think that the Prism worked with the Spectrum or the zx81 ( I could be wrong ) but if you wanted a ready made circuit, then this would be another path - Just intercept the data from the serial chip directly and disconnect the analog modem circuit. Any modems for the zx81 would include all of the necessary serial port interface already made.

The final option is to wire something up from the Spectrum - eg, Find a serial port for the spectrum and cut down the connector. It's mostly higher address likes at the edge, but it should be relatively simple to adapt a Spectrum serial port to the zx81 and find some suitable I/O port mappings that likely won't be any more difficult than remapping some wires - Maybe not even that much given how much a Spectrum shares with the zx81 port-wise.

Hand wiring such a project is realistic also - it's not too complex. A few hours with a soldering iron and some prototyping PCB. It was the older serial chips that were more complex as they often omitted a baud rate generator while the newer 8251s had that built in, and if you go for something like an 80c750, you can get a 64 byte FIFO buffer as well, which will help a lot talking to a zx81.

Something like this is very likely to be adaptable to the zx81 with minimal rewiring: https://www.computinghistory.org.uk/det/42243/Indescomp-Parallel-Serial-Interface/

It may not even use any different pins - and simply cutting the interface down might be all you need?
 
The ZX81 BASIC lacks In/Out which always makes these things a hassle in BASIC - and it would probably need machine code anyway to cope with any speed whatsoever.

Back in 1981/82/83, there was practically nothing to connect the ZX81 too with a serial port - no modems or printers were available or at least any that could be afforded by me or my peers - and so I never saw any interfaces. Maybe some HAM folks used them for RTTY?
 
If I can ask, what is the actual aim of this project?

Funnily enough I was briefly pondering this question because I had my original ZX81 out for a run last night. I was wondering if I could make a project which, when connected to the keyboard matrix, could 'type in' a BASIC program - more reliably and at maybe 4-5 times human speed and then run it - it would be a nice demo illustrating the manual process of entering a program via the keyboard and then running it.

I was wondering how I could get the program, having typed it in initially, out of the machine and into the form of a file which the auto-typer would then recover the program from in order to type it back in, and my first thought was maybe to use a serial interface to send the tokenised BASIC out to something which would 'record' it, but then, duh, I realised I could just save it out in the traditional way to an audio file and possibly use an already existing conversion utility to covert that to file form and then pick the program out of the file.

But anyway, a serial interface for the ZX81 would be an interesting project - as others have said you'd probably need to do the send byte out / read byte in via small machine code routines called by USR from Basic. Depending on what you want to do I would suggest adding a 6402 UART + MAX232 level shifter (and an address decoder). Many of the standard parameters like number of bits, number of stop bits, etc can be set by hard wiring some of the 6402's pins in a set state so it requires very little setup from the host making it simpler to use than some contemporary UARTs.

Edit: I see from Divarin's link that the intention was to try to connect it to a WiModem - in that case your serial handling routines would have to be pretty sophisticated with provision to buffer the input and output data and handle hardware and / or XON/XOFF handshaking, where necessary.
 
Trying to automate the entry of BASIC would be nice: but problematic. As anyone who went to the trouble of adding a new external "real" keyboard can attest, the ZX81's keyboard scanning and processing of the entered commands is itself dog-slow. The ZX81's "quirky" keyboard membrane did an excellent job hiding this fact. By far better to use something like the ZXPand interface (one on Tindie now) that can blast code into memory, either from SD card or on the new version, over a high-speed serial link.

Using the '81 as a serial terminal would be something that only someone in 1981 would spend a lot of time trying to make work, IMHO :-D but of course, that's not a reason to try. Or else what's the point of this hobby?
 
About 20 years ago, there was a board that could connect to the ZX-81 and provide RS-232 ports. Admittedly, when one gets done with the project, there is a strange computer in a group of boxes with the ZX-81 in the center. Not sure how one could find those now but I spent a little time tracking down an Internet Archive link for those that are bored.

 
GrantMeStrength, yes, there are more practical fast loading solutions now, SD based or otherwise, for most computers, but I thought it would be interesting for onlookers to be able to see a machine 'typing in' the code itself, much like watching a player-piano play. I already did something like this for an earlier Sinclair system (MK14) which types the code in the same way a human types it in, much faster than the 4 CPS that the cassette interface loads at. But then the user interface / keyscan routine on that machine is very fast.

One of the worst obstacles to doing this on a ZX81 is the increasingly longer time it takes for each new entered line to be added to the program listing as the length of the program grows. Without any form of feedback the autotyper would have to try to calculate, based on the number of lines already entered, how long to wait between pressing Newline to enter one line and then starting to enter the next line. - Each time you hit 'Newline' to enter a new line of BASIC code the display briefly goes off - the machine goes into 'Fast' mode, and then when the line has been added to the listing the display comes back on. This would be something the autotyper could exploit, by sensing the absence, then presence of a video signal it would be able to start entering a new line of code as soon as the machine was ready to do so.

Anyway, we digress: It's hard to believe that there was not at least one widely known and owned serial interface for the ZX81 as there was such a huge third-party cottage industry around the machine. Surprising that Memotech or Stonechip, purveyors of third party memory expansions, never produced a serial interface.
 
According to TIMEXSINCLAIR (.) COM, there were 3 advertised RS-232 adapters for the TS/1000. I expect there were some for the ZX-80 and 81 but I don't know the British market enough to know what other terms should be used for searching.
 
Divarin said:
Okay so they do exist (or did "back-in-the-day") and I guess I can start an ebay watch for something like that but I was hoping to find a modern solution, something readily available.
Click to expand...

It's not that difficult to wire up a PC style UART to a port on the spectrum/zx81 expansion bus. Just pick a couple of unused address lines. You only need a single OR gate to mix IORQ and the address line you want to use to select the chip, move the address lines 2 pins up and to be honest, if you don't mind using 255 as a port, you don't even need glue logic - you can just connect IORQ to !CS2 and connect A0 to CS0 and A1 to CS1, A2(zx81) to A0 (Chip), A3 to A1(chip) and A4 to A2 (chip). Connect D0-D0...D7-D7, !RD to !RD, !WR to !WR and RD and WR on the chip to vcc. Then you just need two resistors and a crystal to make it work and you have instant TTL RS232. That's not a lot of wires to handwire.

This would place your 8 serial chip register addresses at $04, $08, $0C, $10, $14, $18, $1C and $FF respectively.

Get something with a decent buffer ( eg, 16c550 ) and then you have 16 character periods to respond.


You can even program it in BASIC with IN and OUT and set automatic flow control, so it won't overrun when you connect it to something else.

Modern and Readily Available just mean "Someone else builds it" but this is as simple as DIY interfaces get.
 
daver2 said:
The Eagle PCB and parts list is there that I can see. I can't see any software though.
Click to expand...

There is no real need for software on a zx81 or spectrum unless it does exactly what you want - there was no concept of drivers on those early systems and the bios interrupts were all ROM based in the OS.

Only the Interface 1 RS232 was an exception as it hooked the BIOS, but that was a hardware/firmware change.

The DUART mentioned in the project is the 16c850 which is a very upgraded version of the 16c550 - and certainly never existed during the zx81 era. But it's also got 128 byte FIFO's which would lend themselves to being used from BASIC with IN and OUT commands.

That would work quite well.
 
Reviving this thread because by sheer fluke, I ended up being offered an unbuilt 1980s 'Cirkit' kit for the ZX81 RS232 serial interface described in this issue of the UK electronics magazine 'Radio and Electronics World', from PDF page 76 / magazine page 74 onwards.


The kit is now built up (see image) and the interface works as designed, but it has the fairly serious limitation of being hardware limited to 7-bit characters - this was not considered to be a problem for the original application where the hardware and software combined turned the ZX81 into an ASCII terminal.

The project uses an I/O mapped Z80-CTC as a baud rate generator for the memory-mappped GIM AY-3-1015 UART which, functionally and pinout wise, is very similar to the better known 6402 UART. ZX81 BASIC doesn't have the IN and OUT commands which would have allowed access to the CTC from BASIC so it is unfortunately necessary to call a small machine code routine to write setup values to the CTC before it will start generating a clock for the UART. The UART can be PEEKed from and POKEd to so it is usable from BASIC after a fashion once the CTC has been set up once. Of course for high speed serial reception it would probably also be necessary to use machine code to access and distribute or buffer any data being received over serial.

Unfortunately the accompanying software as written is barely usable but I have enough information now about how the hardware is mapped onto the ZX81 to attempt to write my own software for it if it comes to it. My main interest in the interface was to make it possible to create code off - machine on a PC and then download it to ZX81 RAM through a (relatively) fast serial connection, I also have a couple of projects which can be communicated / commanded with via ASCII commands sent to them over RS232 serial so I may explore that as well.

Cirkit_ZX81_Serial_Interface_1983.JPG
 
Nice.

So, 7-bit ASCII and 8-bit code smacks of dowloading using Intel HEX or Motorola SREC format would be the easiest/most 'standard' option...

Dave
 
Last edited:
Yes, exactly my thought - Intel Hex that is - both Intel Hex and Motorola 'S' do have the advantage that they inform the receiving device where the received code should go, so the user doesn't need to input a manual offset / destination as would usually be the case with a raw .bin file. Of course it takes a lot longer to send the same number of bytes as Intel Hex or Motorola 'S' than it would to send them as raw 8-bit data.

I already have some Z80 IH receiving code which I wrote some time ago for another system which used a different UART (8251, in that particular case), I might even be able to find it.
 
The advantage of both formats is that they are readable by a human but, as you say, it takes additional time.

You could come up with a really 'perverse' way of transmitting 8-bit binary as compactly as possible by knowing that 7-bits are transmitted per byte, so you need an extra bit from the next byte to complete the 8-bits. Worst case (in a block of binary) would be one additional byte at the end of a consecutive block of bits.

You could still encode start address and length information into the stream.

Unfortunately, it would not be human readable - but you would get used to it :)...

This would be slightly less 'perverse' than the DEC PDP-8 'HELP' loader!

Dave
 
Last edited:
So seven 8-bit bytes 'packed' into every eight 7-bit RS232 characters sent, like this?

| 0123456 | 7012345 | 6701234 | 5670123 | 4567012 | 3456701 | 2345670 | 1234567 |

Not a bad idea and with this and even with raw binary, there could be a gentlemen's agreement between both parties that the first two bytes are to be considered to be the high byte and low byte of the load / ORG address (and maybe bytes 3 and 4 the 'number of bytes in file' to count down).

It's certainly worth considering, although for an easy life I may just go the Intel Hex route because assemblers, or certainly the ones I have anyway, can natively output the assembled code as Intel Hex and so it would be oven-ready as far as any on-ZX81 Intel Hex downloader routine was concerned.

'Packing' the code as suggested would obvously require an extra conversion / translation step between assembler output and transmission to the ZX81, but it is certainly doable.
 
>>> So seven 8-bit bytes 'packed' into every eight 7-bit RS232 characters sent, like this?

7 bytes of 8 bits = 56 bits = 8 bytes of 7 bits.

Correct.

Agreed with the load address and byte count.

You may also want to consider a 'synchronising' sequence of bytes (e.g. "ZX") as the first two bytes of the block and a 16-bit checksum at the end (just to complicate things - but this will ensure that what it thought had been loaded is what was loaded).

Not a 100% guarantee that we 'lock on' to the correct start of the block of data - but it should be a good check nonetheless.

I would write a simple communications program at the PC end to take a HEX file and convert it on-the-fly for downloading. This would avoid creating yet another set of files.

But, yes, go with the HEX file format first - at least that way you get something working first and can then make an informed decision about whether to improve it.

Dave
 
You must log in or register to reply here.
Back
Top