The random ramblings of a French programmer living in Norway...
← Mobile UsabilityFixing a Brionvega Algol BV1 →
  The Oric Tape Nightmare
Sat 23rd November 2019   
Let's talk about tapes, more specifically "Oric Computer Programs Stored on Tapes".

If you follow my Youtube channel1, you know that I do have a significant amount of original Oric software on tapes, and that I've been buying tape players.

The Oric tapes problem

One of the major headaches Oric owners had back in the days was that loading software was a very unreliable operation: It was not uncommon to have to try three or four times before a brand new program finally decided to launch without any error.

The average Oric owner became an expert in changing the volume or turning the azimuth2 screw on his tape drive depending of which game they were trying to load, which in turn had an impact on whatever software they also tried to save.

There are three main reasons for this problem:
  • No standardized tape device
  • Not using checksumed block loading
  • Simplistic tape recording hardware

Standardized tape device

Commodore 1530 Datassette
Commodore 1530 Datassette
Many of the 8bit computers at the time had their own standardized tape drive:

The C64 and VIC 20 users had the Commodore 1530 Datassette with its C2N interface.

The 8bit Atari users had the Atari 410, 1010, XC11 or XC12 Program Recorders over the SIO interface.

Some other computers like the Amstrad CPC 464 or the Sinclair ZX Spectrum +2 even had a built-in tape drive as a part of the computer body.
Sinclair ZX Spectrum +2
Sinclair ZX Spectrum +2

Having a standardized tape system brings a number of benefits, both for the users and the software publishers: If everybody uses the same drive with the same settings, it's much easier to make sure everybody can load the programs, and find out if specific tapes are damaged or not.

That being said, there were a number of 8bit computers which did not came with their own tape drives, and they were not infamous for having such problems, so this cannot be the only reason.

Checksumed blocks format

When loading a typical game takes between 3 and 5 minutes to load (in FAST mode), or more than 15 minutes (in SLOW mode), it is generally a good idea to report errors as soon as they are detected, and eventually give a chance to people to try to reload the problematic section.

There are many computers that had such a format, saving a program in short individual sections with their own header, and a very noticeable tone change between them.

When a section would fail to load, the computer would tell you to rewind a few numbers back on the tape counter and retry.

The default Oric format does not do that, all you get is a synchro sequence, some basic header, and then all the data in one single block with some basic error correction which generally resulted in a frustrating ERRORS FOUND message at the very end of the loading.

Manic Miner Oric Loading Screen
Manic Miner Oric Loading Screen

There are few exceptions, like the game Manic Miner which on top of having a very very smart animated loading screen also happen to use its own loading system with checksums and retry.

Obviously this only helps when there are loading errors, in a perfect world things just load fine by default, so that's not a root cause either.

Hardware circuitry

The next step is to actually look what happens at the hardware level.

If we look at the Oric schematics we can see the following:

Oric Schematics
Oric Schematics

On the right, in black, we can see the VIA 6522, which is a multi-purpose device used in the Oric to access peripherals like the keyboard, printed, soundchip, etc... but also to provide timers that can be used to poll the keyboard, blink the cursor, ... or measure the delay happening between two events.

At the top left, in blue, we have the audio circuitry, with the speaker, amplifier, and the connection to the oric TAPE connector3.

In the center, in mustard yellow, we have the tape drive motor relay circuitry. This part is totally optional, all it does is to close a connection between two pins to allow the Oric to automatically stop or start the drive.

The two important sections are the green and red ones at the bottom.

The green one is in charge of filtering whatever arrives on the TAPE IN pin of the DIN connector on the back of the machine, and convert it to some signal that the VIA 6522 will be able to sense on the pin 16 (CA1).

The red one is what actually is used to write to tape: The status of the pin 17 of the VIA (CB1) goes through R12 a 22Kohm resistor4 and this is what is sent to the TAPE OUT pin.

I doubt you can do more minimalistic.

So, basically, the question is to know what we actually get on the tape with this system, and why it happens to not be reliable.

Hello World Test

Since analyzing very large files is never funny, I decided to do a very small scale experiment, with a very very tiny program:

10 CLS
30 CSAVE"TEST.TAP",A#BB80+40*27,E#BB80+40*27+39

All this program does is to write the message ORIC COMPUTER PROGRAM at the bottom of the screen, and then save this section of memory in a small program called TEST.TAP.

With an emulator we can easily see the actual content:


This is a typical Oric file, which contains the following (hexadecimal values):
  • 16 16 16 (...) 24 / Synchronization sequence, can have many more 16 values
  • 00 00 80 00 / File type information
  • BF DF / End address
  • BF B8 / Start address
  • 00 / Separator
  • 54 45 53 54 2E 54 41 50 / TEST.TAP
  • 00 / Separator
The rest is the actual payload, a bunch of spaces (20) followed by ORIC COMPUTER PROGRAM and some more spaces.

We can easily convert this program to an actual tape that can be listened to the Oric, all we need is to use Tap2Wav5, then record the Wav file on an actual tape, and play the tape on the Oric.

%osdk%\Bin\taptool TEST.TAP OricComputerProgram.wav

Which gives us the following wav file, 2 seconds long, 45.8KB in size, you can hear it with this audio control:

So, what does that look like, exactly?

We can simply load the wave file in some audio editor, like Audacity:


Personally I prefer Wavosaur, it does not do half of the quarter of what Audacity does, but it does things I need that are super annoying to do in Audacity, and when zooming in details Audacity only shows dots while Wavosaur still shows useful curves.


Anyway, both pieces of software are free and useful, so pick whatever you feel comfortable with :)

Oric Tape Encoding

If you zoom on either sample view, you should notice that we get a relatively simple square signal with only two values: LOW and HIGH.

And if you stare at it even longer, you should notice that the HIGH values (in blue in the following picture) are all of the exact same length, while the LOW values are present in two different durations, some short ones in green, and some longer ones in red:

Short and Long sequences
Short and Long sequences

So, let switch to binary!

If we look up what we wrote earlier, we know that our tape starts by a series of 16 (hexadecimal) and then a 24, which in binary are represented as the following:
  • 16 hexa = 00010110 binary
  • 24 hexa = 00100100 binary
  • 00 hexa = 00000000 binary

If we look at the patterns in the short and long sequences, we can isolate something that repeats at the beginning:

**..*.****.... | **..*.****.... | **..*.****.... | **..*.****....

but that does not seem to match any of our binary patterns, and certainly not 00010110.

So let's take a look at what is in the source code of the tool:

void emit_standard_byte(int val)
int i,parity=1;
for (i=0; i<8; i++,val>>=1) {

From what I see, we are actually having more than 8 values for each byte, which makes sense from an error correction and synchronization point of view.

It also looks like the bits are stored from the lower to the highest position, so we should be searching for 01101000 instead of 00010110.

Let say we use "*" to represent 1 and "." to represent 0, it means that 01101000 is actually *..*.*** which means we actually have our pattern:

**..*.****.... | **..*.****.... | **..*.****.... | **..*.****....
-01101000----- | -01101000----- | -01101000----- | -01101000-----

We are left with one unknown value at the start and 5 at the end.

In the code we can see that the first one is a 0 bit:
  • emit_standard_bit(0);

The four last ones (stop bits) are 1's:
  • emit_standard_bit(1);
  • emit_standard_bit(1);
  • emit_standard_bit(1);
  • emit_standard_bit(1);

and the remaining one is just before the four ones, it is the parity bit for what was just read:
  • emit_standard_bit(parity&1);

Let's look how the bit writting is implemented:

void emit_standard_bit(int bit)
if (bit)

the emit_level function automatically flips and flops between LOW and HIGH, so basically what this function does is to use identical short values for 1's and a longer LOW value for 0's, which matches what we found so far.

So that's the way it works:

To detect if something is a zero or a one, the Oric just counts how long it took to go from LOW to HIGH.

The implications are clear:

If the tape speed is not constant, or if the edge transitions are not clear, a 1 can easily become a zero.

In this case we can easily see that there is no room for error, the WAV file was generated by a tool, it's all digital, there was no annoying laws of physics to wreck havoc.

But what about an actual Oric saving the exact same file???

Let me plug my Oric, connect it to my PC sound card, and we will try that!

Actual Oric output

I started first by recording from the Atmos directly to my main PC using the Xonar U7 connected on Line Out, and what I got was kind of puzzling:

I does sound allright, but when looking at the wave file, gosh!

What happened???
What happened???

The real Oric recording is slightly longer, but it also starts totally bent... which makes no sense.

Since it could be my audio card, I decided to give a shot with my laptop instead, using my girlfriend's Steinberg CI2+ USB external sound card.

Different Oric, Sound Card and PC
Different Oric, Sound Card and PC

As you can see, the results are similar, the signal has the right amplitude but start completely offset and then gets correct at some point, I tried with two different Atmos and the result was similar.

As regarding the actual shape of the square wave, I let you compare:

Oric vs Ideal
Oric vs Ideal

The top part is the wave generate by the Oric tools on PC, the bottom one is the sampled results from the actual Oric (resized to fit and match).

Temporary conclusion

It probably need more work and tests, but my current theory is that since the Oric is not able to generate a signal that even remotely look like a square signal (an issue we already experienced with the expansion bus) the result is that there is some significant slopes and curves in the signal, so whatever mechanism is used to detect the length of a dip or raise may be confused by the slow rising or dipping signal, and may also be influenced by the playback volume.

If you add on top of that, that not all Orics run exactly at the same frequency (because of difference in clock frequency chips), you may end up with some publishers saving their Oric programs with machines that generate programs harder to read by other machines.

It would also be interesting to automate a saving sequence and see if there is any variation depending of when the machine is warmer.

What I'm wondering is if we could not solve loading problems by just using a variant of Fabrice Frances' WavClean designed specifically to recreate a similar wave file that can be resaved on impossible to load tapes: Since modern hardware is much more able to generate a perfectly clear and square signal, that would probably significantly improve the chances that we can load a game.

Additional notes

Before publishing the article, I asked a couple of Oric people who have worked a lot on the Oric tape issue to review it, and I got the following feedback:
  • The signal generated by the tool is not doing exactly what the Oric does (different number of stop bits) but the Oric does not care
  • The actual loading issue may have been caused by a reference error on one of the resistors (possibly R8) which should have been 10k ohm instead of 100k
  • The curved wave could be caused by some bias compensation in the recording system
This was only the first of a series of articles about the Oric and tapes, so I'll be digging more in details in all that, and who knows, maybe even see if changing a resistor can fix all the problems!

3. This part has no real impact on tape loading or saving, but since the two pins are exposed on the connector...
4. There's also R13 and C7 which connect to the 0v
5. Or TapTool, or some of the most recent variants.
comments powered by Disqus