Experimental very fast tape loading

Anything related to the tools Tap2Wav, Tap2CD, Tap2Dsk, Sedoric Disc Manager, Tape Header Creator, WriteDsk, and generaly speaking tools related to the management of Oric data files and devices.
User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Mon Mar 05, 2018 1:20 pm

Thanks!

Impressive, but useless as long at it only works on one or two Atmos ;)
It's a kind of "laboratory conditions" speed, that Oric could have advertised but never implemented :-p

Problem is that if I have to slow down the basic sinusoid speed, it will make things more complicated (less available values means less functions).

User avatar
iss
Squad Leader
Posts: 691
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Experimental very fast tape loading

Post by iss » Mon Mar 05, 2018 2:00 pm

Symoon, your code is really nice! I expect in final version you move it in to stack instead of $400. ;)
About the values: in my experiments with smart phones I found that most of them simple can't play wave forms with only 3 samples (no matter of sampling frequency 44k1 or 48k). This is a hardware limitation related to DAC and to the low-pass output filter. Of course this is just private case valid for phones, but I'll be not surprised if such limitation can be found in some PC sound cards.
Else, how do you choose the threshold values used to detect different 2-bit groups?
I think I have something useful for you - do you know Fabrice's chronometer? :)

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Mon Mar 05, 2018 3:20 pm

Yes, Fabrice sent me the sources of this chronometer a few weeks ago (that being said, if you have a TAP file, I'd be happy as I never used an assembler ;))
So far I only used my own small test programs ;) You found the right problem: threshold value.
Here's what I did to get the threshold:
- I made a test program that decodes a signal made of all the combinations of a sinusoid, surrounded by 2 other sinusoids. So I test all the combinations of groups of 6 bits, measuring only the two in the middle. This way I hope to get the length read for every sinusoid, possibly affected by sinusoids before or after.
- I designed various waveforms to see the ones that gave the more distinct threholds. For instance, "01" could be coded -___ or _-__ or _--- or _--_ or __--, and so on...
- tested all this on several Atmos (up to eight or nine when results seemed rather good)

It ended up that signal like _--___ was the better read by the Via, but it's sometimes a matter of two microseconds ;) The problem I have is double:
- threshold varies from one machine to another
- some machines (15-20% of the ones I tested) can't make the difference between 3 or 4 samples (or was it 4 or 5 ? Can't recall right now) every time.

The test I sent *seems* to be the optimal one for all the machines. The other problem is now it requires a perfect audio quality, as you pointed.

With my 3rd Atmos, it seems to have some random reading mistakes. I just don't understand why, having made further tests and checks, all seem correct but when loading a program, I get mistakes. Still searching, maybe one of the longer thresholds wich I didn't test much (7 or 8 samples). Might try with another sinusoid form too, but if the source of the problem is somewhere else (timing or whatever in those hardware things I don't know much), then it's game over ;)

And BTW yes, the goal is to put the code in page 1 ;) I plan to silmplify the header / name loading to get a few more bytes if required.
Thanks for your comment on the code, but you will notice that it has many common things with TAP2CD - meaning that it's for a great part Fabrice's code ;)

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Tue Mar 06, 2018 12:44 am

Tried loading again Zorgon on the "faulty Atmos" tonight, to check if the faulty bytes were exactly the same than the 1st time I tried.

You guessed: it loaded like a charm.
:shock: :?

Could it be possible that some Atmos are more sensitive to audio interferences than others? It absolutely didn't work last time I tried (at least 10 times), while it worked on other machines minutes before.

Conclusion: on my 3 machines, it's a 100% success... In certain conditions that I don't understand :lol:

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Thu Mar 08, 2018 12:33 pm

iss wrote:
Sun Mar 04, 2018 3:12 pm
Downloaded, tested ... and here is the result:
Image
Two other people tried on their machines and seemed to get similar problems of picture being moved to the right (more or less than you).
This is I think due to some bad values when uncompressing: the loader thinks some bytes have to be repeated more than they should.

I began trying to do specific measures in such cases (several repetitions of bytes) to see if values were not close to the edge, but so far no problem on my machines...
The other possible cause is an interference (Wifi, phone, noise in Windows while playing the WAV?) that causes the problem. I tend to think it could be the case, since many lines with compression are fine, there are about "only" 11 mistakes in your picture (the blue sea starts in column 11 at the bottom of the hires screen). But I keep testing quietly ;)

User avatar
iss
Squad Leader
Posts: 691
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Experimental very fast tape loading

Post by iss » Thu Mar 08, 2018 2:55 pm

Hm, this is interesting and I think you are right about the bad values in decompression - because bytes are looking somehow shifted but they still 'hires-correct' bytes :) i.e. there are no strange or wrong colors and pixels.
I looked in Fabrice's chronometer source, but it's very specific to his Tap2CD encoding (he counts separately high and low levels and switch the active triggering edge on every interrupt). For your case, in my opinion, it would be easier to add counter directly in the loader. Here is the idea: select one unused memory page to store the values, for instance #7000-#70FF, clear this area from BASIC or assembler setting ZERO to all 256 bytes. In loader source after you get the timer value in Y-register insert one line: inc $7000,y. Create samples with 3,4,5,6,7,8 periods and play them. At end use BASIC program to plot the results as X-Y chart, where X are #7000+x, and Y are PEEK(#7000+x). That's it! :)
Below is screenshot of chronometer - you can see how the values are grouped and it's easy to select threshold constants.
chrono.png

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Thu Mar 08, 2018 8:40 pm

Hehe, actually if you go back to my post from Feb 22, 2017 10:08 pm, you can download the kit I used to test different waveforms for the signal ;)
It only had test files for 3, 4, 5 and 6 samples, but it will work with WAV files using 7, 8 or 9, and with any waveform.
3456-Test.png
3456-Test.png (2.38 KiB) Viewed 2220 times
(here, values are perfect because it's Euphoric :) )

In short: it measures a sample, let 2 pass, then measure again. Only based on up front.
This way I could make all the combinations of different length before/after the sample I wanted to measure, to see if it was affected by the variations before/after him, and how constant (or not!) was the wavform I was testing.

Here are the measures I got on various machines for the waveform that gave the best results:

Code: Select all

type _--____

Atmos Paris:	3:[B7;AE] 4:[A2;9C] 5:[8D;87] 6:[75;6F] 7:[5D;57] 8:[45;42]
Atmos "Reset":	3:[B7;B1] 4:[A2;9C] 5:[8A;84] 6:[75;6F] 7:[5D;57] 8:[45;42]
	zorg:	  [B8;AF]   [A3;9D]   [8B;85]   [73;6D]
Atmos "MBec":	3:[B7;AB] 4:[A5;9C] 5:[8D;84] 6:[75;6F] 7:[5D;57] 8:[45;42]
 with 88 before:  [  ;  ]   [     ]   [8A;87]
Atmos 6522 bof:	3:[B7;B1] 4:[A2;9C] 5:[8A;84] 6:[75;6F]
Atmos 214102:	3:[B7;A8] 4:[A5;9C] 5:[93;84] 6:[78;6F] A8 for 3 !
Atmos 60Hz:	3:[BA;AE] 4:[A2;9C] 5:[8A;81] 6:[75;6C]
Atmos Vrrr:	3:[BA;AB] 4:[A8;99] 5:[8A;81] 6:[72;6C] A8 for 4 !
Kenneth:        3:[B7-B4] 4:[A2-9C] 5:[8A-84] 6:[75-6F]
Euphoric (+-1):	3: B1     4: 99     5: 81     6: 69
As you can see, on each machine, all intervals are strictly different. Only two machines have crossing results: A8 which is 3 or 4 samples. I think "Atmos 214102" is the one to exclude.
You can see that the longer the sample, the more constant the result seems to be. So for repeated bytes, as they use 5 to 8 samples, it should have less errors that bytes between 3 and 6.
Also don't forget on the Hires screen, that all mistakes are not visible. They are immediately visible on bytes repetitions because they slide the whole picture, but if a simple byte is faulty, it can affect hidden pixels and remain invisible.

BTW, I also made a program measuring everything that was sent, filling 500 results (two pages). Tested it with Zorgons Revenge, it showed that the intervals are less separated than the results above, but still different (sometimes a matter of 4 microseconds...).

Anyone can use the kit and see if results on his machine are similar - a bit boring to test, but can be helpful ;)

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Sun Mar 11, 2018 3:13 pm

Here's a new test kit.
If you encountered problems loading the previous "very fast speed" WAVs, you can try with this one and report the results ;)

The Atmos will compare what it read with what it expected to read, and display the mistakes in red.
Resultats are shown on 4 screens, if you guys encounter mistakes, it would be cool to post pictures of at least one screen (with errors obviously ;) ).

Load first the test program, [test-fast-speed-program.wav] it's of course a standard speed file.
When requested, load the test file, [test-fast-speed-testfile.wav].
(there's a short readme file too)
test-fast-speed_ROLA-v2.zip
(8.5 KiB) Downloaded 62 times
Thanks ;)

User avatar
Chema
Game master
Posts: 2302
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Experimental very fast tape loading

Post by Chema » Sun Mar 11, 2018 11:14 pm

Hi Symoon!

I made a couple of tests for you today :) It was harder than I'd thought, because I am no more using my old laptop for reproducing and also changed my smartphone and the new one seemed useless for loading things.

After some attempts I could load Oricium with the fast routines developed by Fabrice in the new tap2cd (I needed several attempts until I got the right volume) and spent a few minutes playing a bit with it 8). Then I tried your first file and the picture loaded perfectly!

However your test program did not work well. I got the 'Errors found' message at each block it tried to load from the loader! Remember my ROM is the one which actually checks if there were loading errors.

When feeding the test data wav, it plays for something such as a second and the screen fills up with data mostly printed on red!

I attach the pics here (sorry I did not take one of the boat, but it was perfect, I think).
IMG_20180311_221928.jpg
IMG_20180311_221959.jpg

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Sun Mar 11, 2018 11:32 pm

Thanks Chema!

The errors found are nothing bad, it's just me that savagely cut into the synchro sequences of each part, to make things shorter... I forgot the early Atmos ROMs, I shouldn't have done that!

I'll check the figues in the 2nd picture. On Oric.org forum, Voyager made tests that were good except that the signal decoding was shifted by one byte, giving many "errors"... It's because the test WAV doesn't have any synchro, as I wanted a rough test, I stupidily didn't think this could happen.
Adding a synchro wouldn't be a good idea anyway: if the Atmos doesn't decode correctly, it will never synch, and I would never know why...

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Mon Mar 12, 2018 1:47 pm

Quickly checked your values Chema. The values seem quite strange at the start (like "1" or "8" in the left column, this should never happen).
Could it be possible that there's a "click" sound or something similar, when you start the WAV file ?

The rest of the values in hexadecimal are more correct, they simply don't match what is expected since, I guess, the beginning is creating some mess.

User avatar
Chema
Game master
Posts: 2302
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Experimental very fast tape loading

Post by Chema » Mon Mar 12, 2018 2:37 pm

I don't know... I always got the same kind of screen (not sure about the values), but what puzzled me most is that the test wav file just lasts a fraction of a second... is that right?

I can repeat the experiment and see if the values are constant or what, if you want.

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Mon Mar 12, 2018 3:13 pm

Chema wrote:
Mon Mar 12, 2018 2:37 pm
I don't know... I always got the same kind of screen (not sure about the values), but what puzzled me most is that the test wav file just lasts a fraction of a second... is that right?
Yes it is normal ;) I'm measuring 512 sinusoids. That's maximum 512*8 samples - much less actually as many last only 3 samples ;)

It just seems something is happening when you start playing the sample, either a sound is associatied in your OS ("click!" when you click), either your player has trouble playing the very beginning... In the 2nd case, maybe you can try adding some silence at the beginning of the WAV test file ?

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Mon Mar 12, 2018 7:22 pm

(sorry previous post was written in a hurry: "either... either..." => not really, it can be anything else, those were just two ideas that sprang to mind when I wrote the message ;) )

User avatar
Symoon
Archivist
Posts: 1394
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Experimental very fast tape loading

Post by Symoon » Mon Mar 12, 2018 10:14 pm

Ok Chema, I checked again your values: the first 256 samples are not read correctly or not read at all, but after that the displayed values match the WAV file perfectly fine! :D

That's very interesting because it means it could be useful to add a short silence, or some longer synchro, at the beginning of a generated WAV file!

Thanks for the test ;)

Post Reply