• Please review our updated Terms and Rules here

ZX-81 RS232 option?

You could certainly run a BBS under Linux, though to highlight the obvious, Linux systems tended to be their own "Internet" service, so anything from UUCP to a full Internet connection, with IP protocols, and dial up ranging from a shell (eg, BASH) to SLIP or PPP were all supported very early on, and all of that replaces BBS's entirely - so I wouldn't expect anyone to have written BBS software under Linux. It doesn't make sense to run a BBS under Linux, but it does make sense to run an Internet service via Linux, which is like a next generation BBS.

Besides, if you're already building circuitry to the level of the photo you provided, you're sufficiently skilled to just add a 16c750 uart to the connector bus of the zx81 and talk to it in BASIC and use it's 64 byte FIFO buffers and hardware handshaking. I'd suggest doing it that way.

There's a level of "obviousness" to your overall application that comes in well below that level, so I'm guessing you may not have tried playing with modems before, which seems to be the missing element of what you're asking. On the surface though, based on your previous experience I'm guessing the optimal path will be something like;

* Make up a new, custom, PCB to interface a FIFO capable UART to the zx81.
* Add a model to the zx81 and RPi, or just use a null-modem instead ( null-model recommended ).
* Write some simple terminal software in anything ( BASIC, Assembly etc )
* Have your RPi provide a "Dial Up" connection that delivers a terminal shell over Modem.
* Interconnect the two systems.
* Have the zx81 connect to the serial terminal shell via the null-modem and access the RPi services via the zx81.

This seems to be the direction you're heading in? Or I might have misunderstood something -

I did once write something *like* a BBS back in the day for Linux - but it was only so customers of my internet service could connect via BBS access software and download the Internet service software, and create a Linux account automatically to allow them to connect to the Internet service via SLIP.
 
You could certainly run a BBS under Linux, though to highlight the obvious, Linux systems tended to be their own "Internet" service, so anything from UUCP to a full Internet connection, with IP protocols, and dial up ranging from a shell (eg, BASH) to SLIP or PPP were all supported very early on, and all of that replaces BBS's entirely - so I wouldn't expect anyone to have written BBS software under Linux. It doesn't make sense to run a BBS under Linux, but it does make sense to run an Internet service via Linux, which is like a next generation BBS.

Besides, if you're already building circuitry to the level of the photo you provided, you're sufficiently skilled to just add a 16c750 uart to the connector bus of the zx81 and talk to it in BASIC and use it's 64 byte FIFO buffers and hardware handshaking. I'd suggest doing it that way.

There's a level of "obviousness" to your overall application that comes in well below that level, so I'm guessing you may not have tried playing with modems before, which seems to be the missing element of what you're asking. On the surface though, based on your previous experience I'm guessing the optimal path will be something like;

* Make up a new, custom, PCB to interface a FIFO capable UART to the zx81.
* Add a model to the zx81 and RPi, or just use a null-modem instead ( null-model recommended ).
* Write some simple terminal software in anything ( BASIC, Assembly etc )
* Have your RPi provide a "Dial Up" connection that delivers a terminal shell over Modem.
* Interconnect the two systems.
* Have the zx81 connect to the serial terminal shell via the null-modem and access the RPi services via the zx81.

This seems to be the direction you're heading in? Or I might have misunderstood something -

I did once write something *like* a BBS back in the day for Linux - but it was only so customers of my internet service could connect via BBS access software and download the Internet service software, and create a Linux account automatically to allow them to connect to the Internet service via SLIP.
Hence why I chose a raspy, also since I don't wanna use any of my own computers
 
Just to avert some possible level of confusion, I (SiriusHardware) am not the OP (Divarin) and I'm not sure what the original reason for his interest in a ZX81 serial interface was. He hasn't really come back to the thread since starting it. My interest in serial comms on the ZX81 was triggered by the unexpected acquisition of a 1980s 'Cirkit' ZX81 serial interface kit which I built and have posted a couple of photos of here.

Rather than start a new thread about it I decided just to extend Divarin's thread, since it was at least partly about the existence (or not) of serial interfaces for the ZX81.

As built, and with the 'companion' software which was provided in the contruction article, it functions as a dedicated, although rather crude, ASCII terminal. It operates in 'simplex' mode - it is either in transmit mode or receive mode, never both. This IMO makes it too crude to use as a terminal for any modern purpose (that you might use Hyperterminal or Teraterm for), but you have to remember that at that time a 'real' terminal console complete with keyboard and CRT display cost a lot of money, so if you needed a terminal for something and you could instead use a little computer you already had, plus this software / hardware, that was definitely something worth trying.

What I'm more likely to do with it myself is

a) Use it to control one or two gizmos I have which can be communicated with via short ASCII commands over RS232.

b) Use it as a way of downloading machine code which has been written off-machine into the memory of the ZX81.

For the second purpose I have an Intel Hex code receiving routine about 90 percent written in Z80 assembly language, I just need some time to debug it and then convert it into a form in which it can be loaded into a real ZX81 (i,e, cassette audio file).

If I were starting off building from scratch I would have included a baud rate generator capable of generating the widest possible range of common baud rates, I would have used a UART with an integral buffer, I would also have ensured that the interface was 8-bit and capable of sending and receiving 8-bit characters and could also do hardware handshaking - however it is what it is, this interface fell into my life and so I am looking at ways to play with it without modifying it too much.

MiaM mentioned the possibility of the pins used on the 4060 baud clock generator spreading the contacts on the CTC socket - I considered this at the time and used the thinnest possible 'pins' - actually cutoff component leads - which were stiff enough to withstand the insertion force, they are barely any thicker than IC pins, but in any case it is a mostly single sided PCB and it would be trivial to replace the socket should that need arise. I'm not actually a great fan of turned-pin sockets, in my experience they soon lose their initial 'tightness' once an IC has been inserted and removed a few times.
 
Last edited:
I saw that the other day, too expensive for my taste but it does give me a thing to look out for: "Byte-Back RS232"
I wonder what rs232 communication software is available for the ZX-81.
I wonder what it's use would be for, if you want I can try to purchase it, it also comes with a printer which i assume it's for. Though shipping is free so you could purchase it for 100 which is a steal in my opinion for all of that
 
Interesting. What in the design makes it only half duplex?

If you were to connect it as a "modem" to a "terminal", you might be able to use RTS/CTS to force the "terminal" to not send while you are sending.
 
Interesting. What in the design makes it only half duplex?

Was that a question for me? If so the answer is mainly the (machine code) software which accompanies the project. It should be possible to make it work in a more expected terminal-like fashion, which broadly speaking should be:-

--Characters which are typed on the ZX81 keyboard are converted to ASCII, transmitted via RS232 and also, if the user chooses, echoed locally to the ZX81 screen.

--ASCII Characters which are received via RS232 are converted to equivalent ZX81 characters - the ZX81 only has upper case alphabetic characters - and displayed on the ZX81 screen.

As written, the software behaves in a more 'walkie talkie' like fashion and defaults to RX mode, but to send anything you have to go into TX mode while you type whatever it is you want to send. While in TX mode, anything received by the UART is ignored and lost.

With a rewrite of the software it should be possible to make it work more as outlined above, but the main obstacles there are that there is no hardware provision for any RS232 signals other than RX and TX (in particular, no handshaking) and there is no provision for the UART receiver or transmitter to be able to generate interrupts so any characters received by the (unbuffered) UART would have to be detected by frequent polling of the 'received character available' flag.

I don't really have enough of an incentive to want to do this rewrite of the terminal software myself, although I am interested in using the interface in other ways, as mentioned earlier.
 
divarin said:
I wonder what rs232 communication software is available for the ZX-81.

I think because there was no de facto 'standard' manufacturer provided RS232 interface or widely adopted third party RS232 interface, what you will mostly find is that interfaces and any associated software were provided together as a 'matched set'.

In the days since the ZX81's heyday the community have done some amazing things so I would not say it is impossible that someone may have written a competent, useful terminal program for the ZX81, but it would have to be highly configurable in order to work with the apparently diverse range of little-known third-party 'legacy' ZX81 RS232 interfaces.

I think if such software did currently exist, it, like all the others, would 'come with' a matching serial interface circuit, possibly with gerbers from which to have the PCB for the interface made.

But - I am not aware that any such 'modern' terminal program and companion RS232 interface have ever been made. Would be happy to know otherwise.

If designing a serial interface for the ZX81 now - then rather than taking the 'legacy' hardcore approach of using a 'proper' UART, address decoder, etc, it might be easier just to programme a Raspberry Pi Pico to 'be' a serial interface, particularly as the Pico has a comparatively huge onboard RAM which could be used to buffer incoming characters so the the '81 wouldn't need to care about that. It could also facilitate the ZX81 character > ASCII > ZX81 character conversion to relieve the ZX81 of that load as well, although that would limit it strictly to ASCII traffic whereas you might prefer the ability to send and receive raw binary.

As usual, the main difficulty is the difference in logic levels between the ZX81 (5V) and Pico (3Vx), so you'd need logic-level converters between the '81 and the Pico, in addition to the need for something like a MAX3232 RS232 level converter between the Pico and the RS232 connection.
 
Krebizfan, good find, especially interesting to see that it offers up to 80 column text. The range of interfaces supported, including the Byte-Back one mentioned a few posts ago, is good but unsurprisingly my obscure 'magazine project' example is not included in the supported interfaces list. Even if the author knew of it he may have considered it too limited / primitive to be practically usable, especially with the lack of hardware handshaking.

I do also note though that it needs / expects to find extra RAM mapped into the 8K 'hole' between the end of the ROM and the beginning of standard RAM.
 
The best possible program even with extra memory would be very limited in comparison to what was available on other platforms.

While true, we often forget why it was that people would be trying to use a ZX81 for this purpose:-

A) It was the only computer they could afford.
B) Therefore, it was the only computer they had.
 
While true, we often forget why it was that people would be trying to use a ZX81 for this purpose:-

A) It was the only computer they could afford.
B) Therefore, it was the only computer they had.
When computers didn't exist for the masses, the zx80 even was incredible. The Spectrum was on a whole new level. the zx81 was right in the middle. Much better than the zx80, but people now have no idea how valuable any computer was back then to learn to program.
 
Memotech did in fact create the Memopak RS232 Interface which was based on the SY6551 ACIA and had resident software to use in BASIC or as a terminal. These are, I think, rare as hens' teeth but because of the legit-ness of the Memotech name I'd be keen to get my hands on any kind of "clone" board: I'm sure the ROM is copyright but just a board that exposed the ACIA at the same address (0x2F08 I believe) - if I had the skills to design/build - I could convince myself I was able to write software that would work with the original.

Meanwhile I have been asking similar questions on another board (assume it's impolite to link to) and some kind people have taken an existing 74xx bit-bang design and added RTS/CTS to it - something I hope to try soon although of course it would only work in FAST mode: not great if you are in fact trying to write terminal software :)
 
The rs232 adaptor does exist, I'm gonna try to find another one and document it.
 
The rs232 adaptor does exist, I'm gonna try to find another one and document it.

There are always options - the question then comes down to use. You can control an IC based serial port via BASIC on a zx81. You can't control bit banging via a zx81's BASIC.

The application a user has in mind will affect the outcome.
 
There are always options - the question then comes down to use. You can control an IC based serial port via BASIC on a zx81. You can't control bit banging via a zx81's BASIC.

The application a user has in mind will affect the outcome.
Alrighty.
 
If the chip is a 6402 clone the 7 bit limitation is just a case of changing the hardwired CLS inputs (37,38) I had mine switched for ASCII / Baudot :)
sorry if I missed something, speed-reading... :)
 
Back
Top