Experimental very fast tape loading
Re: Experimental very fast tape loading
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
But if the boat image loads well, it means the system works
Re: Experimental very fast tape loading
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"
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"
Re: Experimental very fast tape loading
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 PS: Euphoric is priceless for debugging with WAV files.
Loading time of the ship picture is really reduced but the result is not quite correct yet PS: Euphoric is priceless for debugging with WAV files.
Re: Experimental very fast tape loading
Well, I *do* recognize the picture
Re: Experimental very fast tape loading
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
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
Re: Experimental very fast tape loading
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.
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.
Re: Experimental very fast tape loading
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!
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.
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.
- NekoNoNiaow
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: Experimental very fast tape loading
Sorry for intruding in the thread with a newbie question but what is the basic principle behind the fast loading?
Re: Experimental very fast tape loading
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 ).
- 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 ).
Re: Experimental very fast tape loading
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)
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
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: Experimental very fast tape loading
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. )
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. )
Re: Experimental very fast tape loading
Exactly, nicely sumed up. Don't know why I began my answer with "in short"NekoNoNiaow wrote: ↑Thu Mar 29, 2018 5:41 amOn the encoding side:
* some data compression (RLE + dictionaries)
* more compact audio encoding (less samples per signal)
* higher encoding signal frequency
Yes, there are 5 types of loops, lasting between about 25 and 100 cycles (or microseconds) + time for an interruption.NekoNoNiaow wrote: And on the decoding side I suspect that the Oric is now scanning tape data in much tighter loops?
I will publish the code once final (and cleaned from years of fragmented work and experiments)
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 playerNekoNoNiaow 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?
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
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: Experimental very fast tape loading
Huhu.
Don't worry, I do the same. Just ask DBug about the length of my emails/posts.
Ok, I think this is indeed what I wanted to know. Thanks!Symoon wrote: ↑Thu Mar 29, 2018 6:43 am 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 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?