Experimental very fast tape loading

[Chema]

It could well be some kind of sound when starting the player... Did not check, as the Oric usually waits for the sync Sorry I should have made sure.

But if the boat image loads well, it means the system works

[Symoon]

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"

[Symoon]

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

voilier_futur2c.png (5.44 KiB) Viewed 3562 times

PS: Euphoric is priceless for debugging with WAV files.

[Dbug]

Well, I *do* recognize the picture

[Symoon]

Ha ha Dbug, maybe I could leave it like this, then?

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

[Chema]

- Zorgons Revenge in 14,5 seconds

[Symoon]

Ok, back to studying.
It seems one of my improvments is a bit too slow, and shifts the decoding from the signal after a few hundred bytes, missing a sinusoïd.

Need to find how to accelerate this part, of remove it by something less efficient but faster, and compensating it in some other way.

[Symoon]

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 3432 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.

[Symoon]

- Zorgons Revenge in 14,5 seconds

Oricium main part would be 12.9 seconds
TAP2CD loads it in about 31 seconds, so that would be 2.5 times faster... But I still need to make it work

[NekoNoNiaow]

Sorry for intruding in the thread with a newbie question but what is the basic principle behind the fast loading?

[Symoon]

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 ).

[Symoon]

Ok finally, it was just a matter of threshold adjustment.
I'm good on two of my three Atmos here.
When the 3rd is fine too, I'll release another WAV test file.

You can pick up a choice - just needs to be a one-part program (or picture), that does not use page 4
(multipart management and moving the code into the stack will be the final steps)

[NekoNoNiaow]

I see, interesting, thanks for your detailed answer!

So this is essentially a combination of several enhancements:

On the encoding side:
* some data compression (RLE + dictionaries)
* more compact audio encoding (less samples per signal)
* higher encoding signal frequency

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. )

[Symoon]

On the encoding side:
* some data compression (RLE + dictionaries)
* more compact audio encoding (less samples per signal)
* higher encoding signal frequency

Exactly, nicely sumed up. Don't know why I began my answer with "in short"

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)

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.

[NekoNoNiaow]

Exactly, nicely sumed up. Don't know why I began my answer with "in short"

Huhu.
Don't worry, I do the same. Just ask DBug about the length of my emails/posts.

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?