Improving Tape Loading on Minstrels Part 2 (BBC, Electron and Oric)

In the previous post, I looked at some of the simple tape loading interfaces on machines like the ZX80 and Jupiter Ace.

This time, I look at some more complicated approaches, like this in the BBC Micro.

This is very different from the "resistor, capacitor and another resistor" designs in the ZX80.

But is it any better?

Acorn Electron

The BBC and the Electron both have quite a complicated tape interface circuit. This is the Electron version (which I think is identical to the BBC).

There is a lot going on, it takes up quite a lot of space on the Electron circuit board (most of the rest of the resistors being colour composite video generation).

It does not have the pair of 3.5mm jacks like the Sinclair machines, it as a 7 pin DIN socket, designed to use with a dedicated "computer cassette recorder", such as the Acorn ANF-03, although that was really designed for the BBC.

The Electron did have it's own, the ALF-03, but this one is broken. I must get around to fixing that one day.

It also has quite a good cassette format, with blocks and checksums and file names. You even get the block counts and file sizes listed (in hex) when you are searching for a file.

(Ah the good old days of filling a C90 with all your games.....)

I will start at the top with the tape output.

This is attenuated from the ULA output and then buffered by 1/4 of an LM324 quad op-amp.

It is fed to pins 1 and 4, in case you are driving a stereo recorder, although it only listens to pin 3, usually the left channel.

The spec says the level is 200mV peak to peak.

Next is the motor control, quite a useful feature, it uses a relay to be able to start and stop the motor, a feature that was designed for portable cassette recorders which had a switch on the microphone you could use to stop and start recording when you had something interesting to say.

That allows it to stop and start between parts of a program as it is loaded and processed, which can be quite handy.

Finally, comes the tape input.

This uses the other 3/4 of the LM324 to give three stages of processing.

The input is on the right hand side of the diagram, I have redrawn it the other way around.

There is a 10KΩ resistor to limit the current, and then a pair of diodes to clamp to the input to the +/- 5V range, to protect the rest of the circuitry. The op-amps need a -5V supply, which is there solely for them.

First there is some RC filtering, then an amplifier with a gain of about 1.25.

More filtering, and another amplifier with a gain of about 1.25.

Finally, an inverting amplifier with a gain of about -60.

The two oddly wired transistors act as diodes, which together will clamp the output voltage to +/- 600mV.

The service manual expects the resulting voltage to be between 500mV and 2V.

I tested this in Circuit Lab with a 1KHz sine wave input. (the circuit seemed very picky about the transistors-as-diodes, I had to use BC337 to get an output)

The input at the top in blue is floating around 2.5V DC, the outputs of stage 1 and 2 reduce this and center it on the 0V rail.

It also copes if the input is already floating around 0V.

The final output is clamped to +/- 600mV and decoupled by the 1µF capacitor for the ULA, which presumably have appropriate biasing to process the signal.

It seems to cope quite well with noise, this is filtered out between the first and second stages.

Oric

The Oric 1 and Oric Atmos follow a similar design, also with the 7 pin DIN and relay control, but a simplified amplifier circuit.

I think I am going to need to redraw that.

One difference here is the sound output from the Oric is connected to pins 4 and 5 (pin 4 is I suppose technically the output of the Oric's sound, and pin 5 is input to the Oric's amplifier to hear the tape, although they are wired together)

Tape output is yet another different way to arrange two resistors and a capacitor.

The tape input uses am LM358 dual op-amp.

The Oric does not have the -5V rail that the Electron doe, so the LM358 is run from 0V and 5V, single rail. The two op-amps are biased around a 1/2 VCC virtual ground.

The input is filtered (but there is no biasing or over-voltage protection). It is inverted by the first amplifier with unity gain. That is followed by a non-inverting stage with a gain of 101.

The output is then inverted again by the transistor.

The 1KΩ resistor and 2.2nF capacitor seem to be a late addition, some Oric's do not have them, and others have the resistor wired on the back

And the capacitor wired on the front of the board.

One even has both on the back, with the 1K wired to ground rather than 5V?

I am not sure that is going to work.

I also redrew that in Circuit Lab so I could show the stages on the chart.

You can see the second stage boosts the signal to clipping to get a good signal.

It also seems to cope with different offsets but the output gets a bit rough if there is some noise on the input.

Other Systems

Honourable mentions to the companies that avoided having to deal with the different input sources by using their own cassette recorders, either built in (for Amstrad and Amstrad built Sinclair machines) or external (Commodore and Atari).

Those systems just need to deal with boosting the signal from the tape head, rather than any unexpected offsets or automatic gain controls, or noise reduction systems, bass boost etc.

Maybe I will cover those separately if anyone is interested.

Adverts

You can all sort of kits, test gear and upgrades and recreations of the ZX80, ZX81, Jupiter ACE and Commodore PET in my Tindie store.

• https://www.tindie.com/stores/tynemouth/

---

Patreon

If you enjoy posts like these, you can support me via Patreon, and get access to advance previews of blog posts (Part 3 is already on there), and exclusive posts.

You also get progress updates on new projects and other behind the scenes updates, as well as access to my Patreon only Discord server for even more regular updates, and to discuss your own projects.

Patreon tells me you will all be rushing to join if I give you 50% off the first month, so I have:

• https://www.patreon.com/tynemouthsoftware

Acorn Electron Repair - Part 2 Keyboard

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This is the second part of the Acorn Electron repair. Last time I got the main board working after it arrived in this state. Looking at this photo, you can see the colour difference between the two halves. I would guess that someone had two Electrons, one with a broken keyboard, and one with a faulty main board, and guess which two halves I have here?

Now it is time to look at the keyboard. The Electron has a very nice keyboard, a metal frame with individual keyswitches soldered onto a single sided PCB. This is connected to the mainboard via a 22 way ribbon.

This is quite unusual, I don't recall seeing this type of cable anywhere else. You can see quite well here how it is constructed as due to the damage, it has started to delaminate.

There are two layers of clear plastic sandwiching some bare copper strips, crimped at each end.

Here the connector is cracked, but just about holding together. In order to test it, I've put sellotape on both sides to try to hold it together.

The back of the PCB has some foam tape to protect the ribbon from the pins on the back of the PCB. With that removed, you can see the where the cable is connected, the fourteen diodes and four resistors. I check continuity through the cable, and most pins were connecting, but there seemed to be the possibility of a couple of shorts where the copper ribbons were close.

I decided to test it with one of my USB keyboard controllers as I know that it is protected against shorts on the pins. On the Electron, fourteen of the pins are connected directly to the address lines, so any shorts could damage the board. (there are diodes to protect the address lines from shorting in operation, but they are on the keyboard PCB, so any shorts in the cable could cause problems).

The keyboard appears to work, but not all the keys, it's a bit intermittent, and there is a danger of shorts, so I think I'll go for replacing the cable. I'm not aware of a supplier of this sort of cable, so I am going for a more easily available alternative.

First off, I removed the cable, and soldered in a pin header to the keyboard. Space is a little tight, so I went for a straight header soldered in at an angle.

The connector on the Electron end is also a pin header, with the same standard 0.1" spacing.

To connect those, I've used Harwin M20 (also called Dupont and various other things) crimps and headers. I didn't have a 22 way, so I used a 20 way and a 2 way.

I tested this again on the USB keyboard controller, and all but a few keys were working.

The ones that were not responding are usually just dirty contacts in the switches. Unless there's a pattern, like a whole row or whole column, in which case check the connections. You can also test this by shorting the two pads for a switch on the back if the PCB, which will effectively press that key.

Where a particular key doesn't work, most of the time they just need to be pressed a few times to brighten up the contacts. If that doesn't help, pull off the key caps with a key puller and give it a quick squirt with contact cleaner. Put the keycap back and press it a few times and they usually come back.

The keys were all now working with the USB keyboard controller, so back to the Electron. That is a straight connection to the main board, but it's fairly tight in there.

In order to make it a bit easier, I've split the ribbon cable into individual wires, so they all lie flat to the side and the case closes fine.

With all that back together and a bit of a cleanup it's working nicely.

The obligatory 10 PRINT program gives the expected results.

Time for a bit of testing.

2022 Update: Did you spot the prototype SD2Elk in one of the photos? I don't think anyone did at the time. The idea was basically add a userport to the Electron and use a BBC Userport SD solution. The worked with a few tweaks to the code, but so much software wouldn't work as it was all originally tape based and didn't work when the disk interface used extra RAM and moved page up. I was looking at various solution to that, but finally ditched the project when I saw that someone else had released something along similar lines. I was unsurprised to see a review from Chinnyvision which basically concluded that none of the games he wanted to play worked for exactly the reasons given above.