I'm interested in the possibility of connecting two ZX Spectrum computers together using as simple an interface as possible.

The ZX Spectrum has two mono audio sockets at the back labelled EAR and MIC. To my knowledge these are labelled to match the labelling of the ports on a typical external tape player of the era. There is a single pin on the ULA labelled MIC/TAPE which connects to both of these sockets, meaning that it's a single bidirectional channel with respect to loading and saving.

If I were to write a simple multiplayer game and wanted to allow two Spectrums be connected together, it seems (at first) that it's possible to write a time dividing system where the two systems share the wire and establish a non-simultaneous, interleaved bidirectional link.

My understanding of the designed use of the two sockets is:

  • MIC is the 'data output' of the Spectrum, and the input to the tape deck. The MIC/TAPE pin on the ULA toggles between low and high logic levels, and is capacitively coupled. The result (combined with the load at the tape deck side) will be a 1V peak-to-peak signal around zero. Unloaded (well, lightly loaded?), it will be inspected as a 4V or 5V peak-to-peak signal around zero.

  • EAR is the output of the tape deck, and the 'data input' to the Spectrum. It is a 3V or 4V peak-to-peak signal (depending on volume) around zero designed to drive headphones correctly. In the Spectrum schematic, this is capacitively coupled, and the diode and 1K resistor network provide a system that biases the incoming AC signal a little higher so that the troughs are closer to zero and the peaks are raised above logic high, resulting in a signal that can be read by the ULA.

As far as I know there's no issue with using either EAR or MIC as the audio output. The Spectrum manual Chapter 19 suggests using EAR output for headphones or MIC output for amplifiers. I don't see any electrical dangers in connecting EAR to MIC on a single Spectrum (though it wouldn't be very useful - game instructions would explicitly suggest connecting EAR and disconnecting MIC when loading games (and vice versa), but I imagine for convenience having a four-headed EAR-MIC-MIC-EAR cable for loading and saving to a tape deck would be fine).

Therefore, it seems possible that EAR to EAR can be used to possibly transfer data from one Spectrum to another, if the timing of sharing the channel is established to prevent collisions and (as is normal for Spectrum tape loading) rapid waveforms are sent to represent the data rather than logic levels.

Is my understanding of the electrical properties of the two sockets correct? and Can EAR to EAR be connected between two systems or would this fail? (in terms of damage or just not work)

An example of a possible detrimental or even damaging effect would be ground loop hum for example. Is that a risk?

Here is the relevant portion of the Spectrum schematic, which is common to all the different Issues.

enter image description here

  • The unloaded MIC output is likely more around 200-300mV than 1V in practice.
    – tofro
    Commented Aug 15, 2023 at 10:45
  • Is that because of the surrounding network for ear, or something else?
    – knol
    Commented Aug 15, 2023 at 10:59
  • 2
    Likely. Didn't think about the because so far, just what my oscilloscope was telling me ;)
    – tofro
    Commented Aug 15, 2023 at 11:45

3 Answers 3


I'm revising this answer to suggest that yes, EAR to EAR communication should be possible without amplification. Read the edit history for my previous working.

There's a large document on World of Spectrum that summarises and paraphrases other sources relating to the ZX Spectrum's hardware interfaces. I've since read the original document by Pera Putnik from which the information about the MIC and EAR sockets on WoS was paraphrased and some details about the ULA's MIC/TAPE pin have become clearer:

  • The ULA does have some analogue behaviour, particularly on its output, and
  • The threshold voltage for reading the input state (at the pin) of the ULA is 0.7V.

The pair of MIC and EAR output bits in the ULA output port can be set separately and provide different contributions to output voltage. This table shows the voltage on the MIC/TAPE pin when different values are written to the ULA port for an Issue 3 Spectrum. (Issue 2 has 0.1V higher voltages but that is not important for this question.) The values are from Pera's site.

1 1 3.70 1
1 0 3.56 1
0 1 0.66 0 (borderline)
0 0 0.34 0

The relevant rows are:

  • BIT4 EAR is toggled to provide a large 3V voltage peak-to-peak signal for writing to tape. BIT3 MIC is immaterial during this process.
  • BIT3 MIC high with BIT4 EAR low provides a voltage of roughly 0.7V. Pera notes that the threshold for reading the state of ULA pin 28 as a high or low level (listed here as BIT6 IN READ) is 0.7V. I believe this means that when BIT3 MIC is set high and BIT4 EAR is set low, the MIC/TAPE pin is in a highly sensitive state where it will be toggled by an AC coupled signal of any size (obviously, the larger the better).

Bit 3 is mostly used for setting correct voltage level on this pin by loading from tape.


I tested on which level on pin 28 input bit 6 changes from 0 to 1 or reverse. This is exactly 0.7 Volts by Issue 2 and same by Issue 3 , and no inverting, no hysterezis:

input bit 6 is 1 if voltage on pin 28 is over 0.7 Volt, else is 0 - by both Issues.

This schematic shows an EAR-EAR electrical connection between two ZX Spectrums:

enter image description here

I initially thought that the effect of the potential divider formed by 600R in series of the TX EAR signal and the pair of 1K||1K to ground as the signal exits the TX Spectrum and enters the RX Spectrum would reduce even a hypothetical very clean logic-level-sized MIC/TAPE signal from the TX Spectrum to something that wouldn't be recognised by the MIC/TAPE input on the RX Spectrum.

However, if the MIC/TAPE pin at the RX Spectrum is biased to its transition point, then the 3V output swing reduced to perhaps 1V by the network would still be adequate to trigger transitions at the RX Spectrum's MIC/TAPE pin.

Therefore it seems that it ought to work at least for some frequencies!

Here is a highly scientific Falstad Circuit example.

enter image description here

To test it, you'd need two Spectrums back to back, and have the TX Spectrum constantly emit square waves of some period and have the RX Spectrum reading its MIC/TAPE and counting the period of the transitions it receives and perhaps changes the border colour to report it. If something as simple as that can work, the system is proved. :)

I feel foolish for not thinking of this earlier, but the EAR-to-EAR connection could be tested without any special software with the following BASIC commands:

  • RX Spectrum
  • TX Spectrum
10 PRINT "hi"
SAVE "hiprog" LINE 10

The PRINT might be optional if an empty program can be saved.

I'm very surprised I hadn't come across any documentation or blogs referring to this kind of 'live save loading' between two Spectrums - surely someone must have tried this.

It would place a lower bound on the frequency as the pilot square might be too low to survive the journey.

One possible way the time multiplexed within-frame system could be used reliably would be in a non-realtime game with two players face-to-face so they can't see each other's screens. Say, a Chaos type game, or something with simultaneous moves (like Frozen Synapse). One or both players could navigate the map and input their moves and then when both players have indicated their turn is complete, the designated Host spectrum could send the state to the Guest spectrum, then vice versa.

For a very stodgy but nonetheless functional assembly-free alternative, if the BASIC approach worked, I believe (+2a at least) BASIC supported loading and saving of variables to tape. So, with a turn-taking data protocol established, and some non-realtime Risk-like game with long turns, the machines could trade strings or arrays this way.

If there was a two channel external audio amplifier present that could boost the TX Spectrum's MIC output to the level the RX Spectrum's EAR expects, that would be perfectly fine.

Of course, if one were to modify both Spectrums so MIC/TAPE were exposed bare without any of the RC networks of each computer present, they could be connected together between Spectrums in any number of ways.


There are actually two problems that need to be solved:

  1. The physically provided and expected signal levels on the EAR and MIC connectors are not symmetrical - The ZX Spectrum expects certain components (roughly a pre-amplifier on the MIC output and the recorder's main amplifier on the EAR input). If you connect the two lines, those amplification steps are missing and signal levels will not be adequate.
  2. The software support. While it is possible to bit-bang any signal on the MIC output by simply toggling a bit on port $FE, and the input state provided by another bit on the same port, there is no support for exact timing or interrupts based on tape input in the machine. Anything that uses the MIC and EAR signals must be timed by tight, cycle-exact loops within the system, which basically implies that during send or receive, there is not much else (like driving a game) the computer could do. As there is no latching or anything of the input signal in the ULA, if you don't actively listen at the exact time the other end is sending anything, the input will be lost.

What you describe looks a bit like a re-implementation of the ZX network provided by IF1 - If that were possible without additional hardware, I guess Sinclair would already have done it that way.

  • New software would have to be completely written from ground up to work with this of course. It would be similar in spirit to how Manic Miner altenrates music and gameplay (iirc) - except this hypothetical game, once it'd established its timing protocol, would be game-rx-tx (with machine Bs roles reversed). No ROM routine would ever handle this weirdness :) this question focuses just on the electrical interface, and getting one machine to get something recognisable into the mictape of another. Assume the software can be written
    – knol
    Commented Aug 15, 2023 at 10:57
  • 1
    Assumption taken. Note the main software problem is not on the sending end, that can be done just like you said, but rather on the receiving end. (Note I'm not saying it cannot be done - there will simply be not much of a game left once you got the comms going :) )
    – tofro
    Commented Aug 15, 2023 at 11:51
  • 3
    Assuming the hardware is taken care of, software protocol isn't a big deal. Half duplex is known since the begin of time and in computers used at least since the first tty was used as terminal :)) In fact, using the basic tape format of header blocks and (optional) data blocks (maybe without most of the lead in :)) would make a good start. Add some header types like for ACK/NACK and so on, and you'll get a slow but decent communication.
    – Raffzahn
    Commented Aug 15, 2023 at 12:06
  • @tofro: Can the ULA video timing on the one either be forced into a known synchronization relationship with that of the other or ignored? If the "logic master"'s game logic could fit between the end of its display and vsync, it could wait for a pulse from the other machine, trigger vsync, then send out a state packet (turning off vsync at the appropriate time). The other machine, meanwhile, would use its ULA for frame timing, and send its "sync" pulse at the start of its vblank.
    – supercat
    Commented Aug 17, 2023 at 15:52
  • @supercat I’m imagining it’d end up more like those flicker-free ZX80 games in terms of every part of the logic being designed to be exactly of equal duration regardless of branching decisions, mixed with an Apple II-esque non-interrupt-driven overall timing and a Manic Miner-esque stoccato processing loop. So sync up the loop at the start, and let that fall within the rasters where it will. Along with suitable slight course corrections per the two separate crystals being an inexact match.
    – Tommy
    Commented Aug 18, 2023 at 0:40

enter image description here

I connected two different Spectrums via tape sockets - I fed the output to the input, and the input to the output + a common ground wire. then I wrote a program in order to send it, I first switched the empty receiving Spectrum to ready mode with the LOAD "" command and then started sending the program from the second Spectrum with the SAVE "anyName" command. the program was sent faster than to a tape recorder. Now I don’t have a Spectrum, but I want to write a network game program using write/read commands for port 254 in/out in the 4th bit.

I also thought that the Ukrainian Spectrums were different - but I hope that the details of the simulation do not affect the standard of operation of the tape output, because the schematic solution is a black box that implements standard external exchange protocols. In the figure I show the example of a Russian clone whose input and output signals are the legs of individual microchips. Perhaps, based on my experience, someone will get to the bottom of the truth. but I'm not sure that port 254 controls these particular microchips or pins. I also don’t know what Ula is - is it a COM port..

I laid 25 meters of hidden triple wire - telephone sets worked through it. But Spectrums were unable to transmit programs over such a distance - so I abandoned the network protocol project in those days. Now I understand that it was possible to put gaming computers nearby to create a network

I don’t think that this will load the processor 100% because the Spectrum could load the game and simultaneously draw a picture or show a countdown counter - but maybe I’m wrong because the picture could appear by itself when delivering data to the video memory area enter image description here

  • 1
    @Pavlo ULA was an ASIC that implemented most of the Spectrum "logic" (think north / south bridge on modern PC motherboards). Ukrainian clones (as well as any Soviet clones) did not contain any ASIC just because no state-owned chip making factory would produce them - so, hobbyists found ways to replicate ULA using discrete logic chips. Respectively, tape I/O analog circuitry was built around comparator / operational amplifier chips available on "consumer market" (typically a Soviet clone of LM211J / LM311N)
    – DmytroL
    Commented May 14 at 16:38
  • @Pavlo As for creating a makeshift network, someone did make a very good point in a comment above that using tape in / tape out for such purposes would be useless, at least for gaming, because TX/RX would consume 100% of CPU time. Maybe that could work for turn-based games but definitely not arcade ones.
    – DmytroL
    Commented May 14 at 16:51
  • then perhaps it’s worth looking towards changing the states of individual microchip legs - I once read the states of the PiC controller pins for my own encrypted LPT device. but this will be inaccessible to housewives
    – Pavlo
    Commented May 16 at 13:13
  • 1
    "the program was sent" so it was a success? Also you write "faster than to a tape recorder" - which makes no sense to me. Why would the speed of the protocol be changed at all?
    – knol
    Commented May 16 at 17:28
  • 1
    @Pavlo "Spectrums communicated with each other about the speed of data exchange," - how, if you used standard SAVE and LOAD? Now, if you were to wrote the communication protocol yourself, this is indeed possible. Once I wrote such a program communicating via two parallel port (present in my ZX Spectrum clone) wires connected to a n IBM PC LPT port. The speed was about 50 times faster than the tape loading.... Commented May 22 at 20:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .