I see your posts Symoon and perhaps you could supply some info on the oric/atmos tape system signal processing.
For a couple of months I have been attempting to take old tapes(print through different/poor playback deck) and correct their frequency response to allow decoding. This has been done on a win7x64pro computer using AVS audio Editor. The tape is recorded mono at 44.1KHz filtered and processed by some Fortran programs I have written. The programs show plots of 1: Histogram of half period zero crossing intervals 2: time plot of signal with superimposed zero crossings 3: plot of zero crossing intervals against time 4:number of cycles of the two frequencies in each burst 5: conversion to 1 and 0 bits assuming 8cycles per bit for high frequency and 4 for the low frequency. So I have now discovered that the tape preface stream is 13 bits 1010000111001 or the inverse?
Now I am faced with questions I cannot answer.
1/how is the information carried in the f1/f2 signal stream number of cycles per bit etc
2/having got a bit stream as shown for the tape synchronizing lead-in e.g.1010000111001101000011100110100001110011010000111001........ how is the data buried in this. I assume oric codes.

This all came about from my Backgammon program posting when I finally discovered that the listing I had was incomplete or a older one and the tapes I have cannot be entered into any oric/atmos because of degeneration and a perfect player needed even if they weren't spoiled.
Perhaps others will be happy to exchange painful experiences with tying to recover old tapes.
In expectation
Happy new year to all

The easiest way if you want to make TAP files, could be to post your (unmodified) 44kHz WAV files somewhere so I could take a look at them and try converting them. There are no miracles to expect but with experience, somethimes old Oric users manage to make things better

To answer your question, here is the way bits are stored in the standard signal:11100110100001110011010000111Stop bits - Start bit - Data (bits in reversed Oric byte order) - Parity
Seems you're fine with your decoding since the tape signal begins with synchro bytes of value $16, so 00010110 (encoded as 01101000 in the signal).

Describing the signal itself is a bit more complicated, since there are two speeds (fast or slow) and a small (harmless) bug.
I got a complete description of the fast signal made by Fabrice long ago, which I could post here if you wish.

PS: in my own experience, I've had much less problems with tapes than with disks!

Hi Symoon, Seasons Greetings. Thank you for the prompt reply.
If I understand correctly wherever the synch sequence starts on the tape( sometimes the signal is faded very low and increases) but the synch sequence ends with 111 then restarts with start bit 0, then data ( MSB first as rs232) 01101000 (decimal 22), then odd parity bit 0, then 3 stop bits 111 again. So the following signal has 13 bit groups with:-
1 start bit; 8 data bits;1 odd parity bit; and 3 stop bits.
Q: Does the ORIC hardware detect the zero crossings in the tape signal, or just sample the state above or below zero at regular intervals?

I have this dream that slow tape clear text programs could be printed out or converted to RS232 signals and input to the ORIC on a single wire. I haven't tried playing my cleaned up signals back from the computer into the ORIC because I see that playback rates are an issue. In the end archiving programs on BD/BDRE disks would give future proofing from degradation (space no object 100 GBs possible)

You give the impression that the fast and slow signals have different encodings, is this so?
Q: I would like to find out what the slow encoding is? I have located a copy of 'The ORIC Advanced User Guide' will this tell me? It will arrive from US in Feb.

I am only dealing with slow tapes at the moment because I see that fast recordings are extremely mangled. Also, I never got into disks.
I have attached an archive containing small wav file recorded years ago, so good. also, its decoded binary file each byte is one bit of the wave stream. see it in a hex editor like 'Hexplorer' or 'Neo' set as 13 columns.
Regards DRBOB

PS begin
I have just realised that I should be able to reconstitute (stitch together) the sine-wave frequencies 'clean' from my computer analysis (the analysis seems to be more robust than the ORIC) and convert the frequencies to fast, or any speed! Attached is my only reasonably clean WAV file. I will try processing it!
PS ends

If I understand correctly wherever the synch sequence starts on the tape( sometimes the signal is faded very low and increases) but the synch sequence ends with 111 then restarts with start bit 0, then data ( MSB first as rs232) 01101000 (decimal 22), then odd parity bit 0, then 3 stop bits 111 again. So the following signal has 13 bit groups with:-
1 start bit; 8 data bits;1 odd parity bit; and 3 stop bits.

This is how a byte is encoded. Start bit, data, odd parity, then 3 stop bits (3 and a half actually... I will post Fabrice's explanations).
When I'm talking about the synch sequence, I'm referring to the beginning of each program recording, starting with about 200 bytes (value $16), then on byte value $24, then a header, then the program.

DrBob wrote:
Q: Does the ORIC hardware detect the zero crossings in the tape signal, or just sample the state above or below zero at regular intervals?

I really don't know exactly how the hardware is working. From what I've read: the VIA 6522 detects "positive transitions", and the Oric measures time between these transitions. Short time: it's a "1" bit, longer time, it's a "0".

DrBob wrote:
You give the impression that the fast and slow signals have different encodings, is this so?
Q: I would like to find out what the slow encoding is? I have located a copy of 'The ORIC Advanced User Guide' will this tell me? It will arrive from US in Feb.

The data encoding structure is the same, but it's the bit representation in the signal that differs. I'm writing from memory, hoping I don't mess things up:
- In fast speed: "1" bit is a sinusoid of 416µs, "0" bit is a sinusoid of 624µs.
- in slow speed, "1" bit is EIGHT sinusoids of 416µs each, and 0 is FOUR sinusoids of 832µs each.

Slow speed is more complex to deal with IMHO as, with repeated information to code bits, it makes it quite harder to know where you are when reading it.

I have made TAP files of your "a3F" WAV file without any problem using the usual tape tools. Just had to convert it from stereo to mono, and from 16 to 8 bits. Not really sure what the content is, seems like mirrored text.
Also decoded without problem the "c0S" file, it's Tansoft's CHESS

Thanks for that Symoon.
If the VIA 6522 detects "positive transitions" I suspect that the ORIC tape input should work if just square waves are applied to it.
However, I have quite a lot to think about now. Thanks for the info, I will get back to you at some stage if I may.

You're welcome, glad if it can help in any way.
As promised, here are Fabrice's explanations from long ago:

So, as you already know, the Oric can save *FAST* at 2400 bauds, this is what we read in manuals. However, don't mistake bauds for "bits per second".
If the Oric could save 2400 bits per second, you would only need about 27 seconds to save an hires screen and 1'50" for a big 32 KB program. In fact, two factors make it for a longer time : first, eight bits in your program result in more than eight bits written to tape, and second, one bit written to the tape results in more than 1/2400 s of time. Let's see the first factor because it is handled in the same way for both SLOW and FAST mode. Every byte of the program to save is formatted as follows:

like in serial communications, you see:
- one start bit (a 0)
- eight data bits (least significant bit sent first)
- a parity bit (if the number of '1' bits in data is even, it is a 0, otherwise a 1)
- stop bits (three 1's)
This already makes 13 bits for a single byte, and each of these bits has to be written as a wave on tape. Here we split the discussion between SLOW and FAST mode. SLOW mode is nicer to look at, but as you might not expect (you have surely heard about a speed of 300 bauds in this mode), you won't get 300 Hz waves on the tape : instead, you get either a 1200 Hz wave or a 2400 Hz wave.
Here is how a '0' bit looks like when it is output by the oric in slow mode:

you count right: eight periods at 2400 Hz !
Note that both these waves last 1/300 s, that's why people talk about the 300 baud speed in SLOW mode.
Now, let's look at the output in FAST mode. A '1' bit is a nice 2400 Hz period:

i.e half a 2400 Hz period first, then half a 1200 Hz period. "What ?", you said, "0's and 1's don't last the same ?". Right, haven't you ever noticed saving a block of nul bytes takes more time than a block of bytes filled with #FF values ? The conclusion is the oric doesn't save and load at 2400 bauds in FAST mode : depending on the number of 1's and 0's, the speed will vary between 1600 and 2400 bauds. The worst case, as said before, when you save a byte filled with 0's, leads to ten '0' bits (start, data, parity) and three '1' bits, that is 10/1600+3/2400 = 18/2400 seconds instead of 8/2400s you could have hoped before reading this (it's even worse indeed, 37/4800 s due to a bug, more on this later). So, your nice 32 KB program we spoke about at the beginning (filled with 0's...huh?) now requires 32000x37/4800= 4'07"...Ouch! (32000x29/4800= 3'13" for the same "program" filled with 1's).
Some of you may ask why Tangerine's engineers did not choose a faster speed, say 4800 bauds ? Don't blame them, have you ever looked at the signal rendered by your tape recorder ? You send it nice rectangular waves and it returns you awful distorsed sinusoidal-like waves ! A 2400 Hz wave is already a very high frequency (something like a B6 key), tapes don't like it very much.
Also, you may ask why they didn't choose a symetric 1600 Hz period to represent the '0' bit ... just commodity, in my opinion : they already had the code to produce half a 2400 Hz period and half a 1200 Hz period, which is common to SLOW and FAST modes. So, at last, why didn't they just use half a 1200 Hz period for this '0' bit ? For code re-use again, they didn't : when loading tapes, the low-level routine detects positive edges only (0 to 1 signal transitions) and the elapsed time between two positive edges serve to determine if a '0' or a '1' bit has been heard: if it looks like

|--|
|--| , it is a 1. If it is longer,
|--|
|-----| in fast mode, or
|-----|
|-----| in slow mode (4 times), it is a 0.

However, something funny with their choice, is the scheme is more robust against bugs ... I'm not talking about tape errors here, but bugs in the rom routines... For example, they wrote without errors the code to output a bit, but then forgot how the routine worked (the next duration of a tape level is programmed through a VIA timer, before this level really starts) and they short-circuited this routine at the entry of the "write-byte" routine (they asked to wait for a timer countdown). As a result, there is an extra half period after each byte and it inverses the output of the next byte ! Every odd byte is inversed (or every even byte, whatever you like best...), that is, a '1' in such bytes is produced like this:

But do you remember the read routines only detect positive edges ? This means that the routine gets a shifted input. Below is a picture showing the periods associated with bits, both when writing and reading:

Happy end ! the input is correct (forgetting stop bits) ! Do you see how this written extra half-bit results in an extra bit every odd byte and disappears every even byte when reading ? So, here is the solution of the title's poser (quite philosophical indeed...).
I even suspect they initially used fewer stop bits like in serial communications (perhaps 2 stop bits) and then added a third one and don't count them exactly because it was not working...
Now you can breath, oric tape routines work (with some luck) and they will continue to serve you many years if you haven't switched to disks yet.

That is most interesting Symoon, thank you. As an aside it says to me that the system is a classic example of a dash to market.

It highlights the problem of sloppy tape players. I have measured the frequencies of the slow tapes from the one I have (see attachment). Also observe the HF print through and ringing of slow frequency at transition; the very one where triggering is done. It is a modern mono Bush which told me the frequencies are 1225 Hz and 2450 Hz. Compared to the actual (from above) of 1200 Hz and 2400 Hz. No way to adjust the speeds on the player and is probably responsible for my ORIC and ORICMOS (ORIC with modified/ corrected ROM chip). I can't for the life of me remember what the code on it is or where it came from! suffice it to say that I made it at work being up to my neck with such things. Using the AVS Audio Editor I can play back recorded tapes with altered speed; I must see if that makes the ORIC read them.

One thing we haven't mentioned is in what form the data stored on a tape actually is.
Is it the ASCII codes as finally stored in memory as described in Bob Maunder's book 'The ORIC-1 Companion' section 4.2 pages 96-102?
I'm not quite there yet but will be in a couple of days.

About speed, Orics have (more or less) a 20% tolerance to speed variations.
The Oric ROM actually tests time between two transitions, as being shorter or longer than 512µs; remember short sinusoids are (normally) 416µs long, and longer ones are 624 or 832µs long.
So I think the speed variation you may encounter is not a problem.

The slow sinusoids of the singal you posted actually look problematic to me. It is likely that, sometimes, the Oric could mistakenly think they hold two short values (two "1" bits) instead of a long one (a "0").

I post this here in case anyone gets in a twist like I did.
Having old tapes, but not the recorder on which they were made, I have played them back on two recorders with little success. One is a Bush slow recording shown in above post. The next I tried did not work with my programmes at all. I have finally realised that the playback is inverted on the previous recording. Since the program used full cycle periods to delineate the bit-group boundaries it will not work with one polarity of the signal Changing the program to use half periods makes the analysis polarity independent. Happy now .