If it's ever a system noise (still, it can be anything else ), that's anyway a good "use case": you wouldn't be alone and I have to think how to prevent it.
If I end up with TAP2CD's way to go (which is very likely ), then there should be no problem as it will begin with the standard loader and synchro. As long as I don't edit it like a savage and invoke "Errors found"

Now that several people managed to load the ship HIRES picture, I'm currently busy trying to implement all the ideas to go as fast as possible.
Loading time of the ship picture is really reduced but the result is not quite correct yet

Well, I managed to load it correctly on Euphoric, but still have problems on real Orics, or with other programs.
Looks like I'm in for another painful test campaign

If I ever work the last problems out, the loading times are finally what I expected. Not counting the loader:
- the HIRES ship loads in 2,1 seconds
- a simple large circle in HIRES loads in 0,85 seconds (many empty areas)
- Zorgons Revenge in 14,5 seconds

Ah, I haven't made serious tests but on the picture at least the results seem much better! Added 4 bytes and saved 7 microseconds that seem to solve problems!

Screen87.png (4.92 KiB) Viewed 4929 times

Ok, I've messed up the index of the small dictionnary I'm using hence the strange looking colours.
But that's for another day. I'm lost with comparisons, SBC and ADC according to C, timers value that are smaller when WAV length is longer... Break!
At least it works on my Atmos.

In short, it's for a great part based on Fabrice's TAP2CD and adds a few improvements (if you don't know TAP2CD, it's been there for 20 years now and is really great, you can find it with the Oric Tapetools).

- TAP2CD codes TWO bits (11, 10, 01, 00) using 4 different sinusoids for the WAV signal. This new loader does the same, but using 44kHz, it allowed to use faster sinusoids. IIRC TAP2CD used the equivalent of 4, 6, 8 and 10 samples for each sinusoid where the new loader uses 3, 4, 5 and 6. It's been the most painful work so far: the sinusoids are so short that I had to test (with the help of Oricians ) many different ways of "drawing" the signal to see which one allowed the Oric to read them in the best possible way. Most of the time, it mixed one for another, and worse: results differ from an Atmos to another. TAP2CD remains more universal and this new loader will not work on some Atmos.
- statistics had been made a while ago, and we noticed Oric programs were made of "0" bits at about 60%. So "00" is coded by the shortest sinusoid (TAP2CD uses it for "11" I think). This is not a critical and systematic improvement, just statistic.
- a RLE compression has been added: if a byte is repeated N times, it is coded only once in the signal, and is followed by N "repetitions". N repetitions are coded by (N-1) fastest sinusoids (3 samples), and ended by a 4 samples sinusoid for the last repetition.
- a dictionary has been added: before creating the signal, the TAP file is analysed and the most the most "repeated unrepeated" bytes (i.e. most repeated out of the RLE compression) are stored in two 7-bytes tables. Those tables are loaded in page 2 with the header and the program name. Bytes from those tables will be coded in a special way, faster than a "normal" byte.
- stop bits have been suppressed. Only a start bit remains, lasting 6 samples for a "normal" byte to follow, 7 or 8 samples for a byte that is stored in one of the two dictionnaries, and 9 samples for bytes repetitions (RLE). Why not using 3, 4 or 5 samples: because the Oric is busy working during this time, decoding and storing in memory the previous byte. It does require those 138 microseconds (so one could say stop bits have been suppressed but actually are merged with the start byte )

I'm almost there. Still struggling to have everrything working in those 138 microseconds, seems like I only have a last problem at the end of a page (filling a new page requires a few more microseconds... Got to find where to save time, won't be easy now ).

And on the decoding side I suspect that the Oric is now scanning tape data in much tighter loops?

One thing I wonder though, does the Oric see an analog signal from the tape? I.e., does it receive an actual digital version of the analog signal? Or is it using a digital counter with an analog comparator triggered by interrupts?

(Yes, I should be looking at the TAP2CD documentation. I will, I will. )

NekoNoNiaow wrote:
And on the decoding side I suspect that the Oric is now scanning tape data in much tighter loops?

Yes, there are 5 types of loops, lasting between about 25 and 100 cycles (or microseconds) + time for an interruption.
I will publish the code once final (and cleaned from years of fragmented work and experiments)

NekoNoNiaow wrote:
One thing I wonder though, does the Oric see an analog signal from the tape? I.e., does it receive an actual digital version of the analog signal? Or is it using a digital counter with an analog comparator triggered by interrupts?

I'm not sure I'll reply the question correctly, but I'd say this: it's an analog signal, but that requires a perfect digital player
The Oric still has to measure sinusoids duration with thresholds, and test those thresholds to translate the sinusoid into a digital value.
But it for sure won't work on "real analog tapes". That was the idea: go faster thanks to the quality of digital WAV players.

I'm not sure I'll reply the question correctly, but I'd say this: it's an analog signal, but that requires a perfect digital player
The Oric still has to measure sinusoids duration with thresholds, and test those thresholds to translate the sinusoid into a digital value.
But it for sure won't work on "real analog tapes". That was the idea: go faster thanks to the quality of digital WAV players.

Ok, I think this is indeed what I wanted to know. Thanks!
I will rephrase to make sure I got it correctly: the Oric cannot measure the actual analog value but it can compare it with threshold values. I suppose that when the analog values reaches these thresholds an interrupt is triggered?