iss wrote:Congrats! The speed is really impressive.
I think you can extend the idea and create kind of networking trough the tape port .

Thanks !
Networking PC and Oric through the tape port is an idea I've explored for yeaaars, but needed to improve skills on various sides:
- how to allow the Oric to be interrupted by an incoming signal (which is a real data signal)
- how to decode an Oric signal "live" on a PC/Mac
Quite another story !

About this attempt, I wanted to try to reach the fastest speed. But sadly it's not reliable (that's why TAP2CD doesn't go that fast: reliability!). What you see is a mix between TAP2CD-like accelerated loading, mixed with a little RLE compression (an empty Hires screen will load in 0.8s instead of 3.2 in the video)

Symoon wrote:Networking PC and Oric through the tape port is an idea I've explored for yeaaars, but needed to improve skills on various sides:
- how to allow the Oric to be interrupted by an incoming signal (which is a real data signal)
...

For what reason did you reject using the CB1 interrupt as a 'start listening' trigger? So the Oric would be off doing its other things, upon getting a CB1 interrupt it would attempt to receive a packet, which either would timeout quickly (if it was noise on the line) or else would be a real piece of content.

Symoon wrote:Networking PC and Oric through the tape port is an idea I've explored for yeaaars, but needed to improve skills on various sides:
- how to allow the Oric to be interrupted by an incoming signal (which is a real data signal)
...

For what reason did you reject using the CB1 interrupt as a 'start listening' trigger? So the Oric would be off doing its other things, upon getting a CB1 interrupt it would attempt to receive a packet, which either would timeout quickly (if it was noise on the line) or else would be a real piece of content.

I didn't reject anything Just never found enough spare time to explore how to program: "how to time out when the Oric has recieved crap, and how to prevent the Oric blocking again and again if it recieves lots of crap".
It's certainly doable and maybe not too complicated, the only problem is... Me, and life

Hello! I need your help to test the reliability of an expected improvement on the very fast tape loading routines. Fabrice gave me (huge) hints on how to measure things in the best possible way (with a 3µs precision).

How to operate, once you downloaded the test kit:
- you need a perfect quality WAV player: quality of playback, and signal fully played (not cut at the beginning or ending)
- move away your cellphone and any other audio interference
- load MD3456-Interrupt.wav on an Atmos (no Oric-1, except if it has a ROM 1.1)
- RUN the program then load MD3456_test_sample_3_--___.wav and write the interval that appears after "Résultat final :"
- RUN the program then load MD3456_test_sample_4_--___.wav and write the interval that appears after "Résultat final :"
- RUN the program then load MD3456_test_sample_5_--___.wav and write the interval that appears after "Résultat final :"
- RUN the program then load MD3456_test_sample_6_--___.wav and write the interval that appears after "Résultat final :"
- finally send me those 4 results!

This allows me to know if all the Atmos will measure the same time interval between various very fast tape signal combinations. I need those results on a maximum of different Atmos machines.

Here's an example of results on one of my machines:
Atmos Paris: 3:[B7-AE] 4:[A2-9C] 5:[8D-87] 6:[75-6F]

As you can see the are some transfer errors, in my opinion bytes are skipped from time to time.
Else, congrats it's really fast!
The only conclusion that I can make is: player need to be "top quality" .
For playback I used my TapOric's WAV-file player, which is based on the default android's java MediaPlayer.
I think it's not the best option for Oric and it would be better to pass the data trough OpenSL API, as I do with TAP playback, but this requires more work - parsing of WAV files - it's on my (long) ToDo list.
Anyway, other interesting thing is that in my tests I used a "special device" connected between smart phone and Oric. This is the "so called" ground-loop noise isolator.
I don't know why but without this "magic" filter I was unable to see the boat. I will check with oscilloscope what is difference and how it improves the signal. I bought this filter just from curiosity and I'm still skeptical about its "miracle" possibilities, but my test are clear with it I see the picture every time, without it - no single success.

(off-topic: interesting story about the ground loop isolator - actually I bought it from China because the 1/2 price. But the china guy send me first a nice mini bluetooth receiver instead. On my complaint he sent me the right item immediately. So I have the bluetooth receiver as gift )

Thanks ISS!
Well, this is not the fastest possible speed but I've slowed down things a little (with stop bits) while trying to find a basic signal form that would work on a majority of Atmos. I only got 3 Atmos at hand, and it works on two of them; I suspect the 3rd has a random problem somewhere.

They are the ones that gave the best results on all machines, with any Oric apparently being able to separate them correctly (at a few microseconds) using the same values. But I think that some combinations are problematic on some Orics.

Anyway, if it fails on other machines, then I'll definitely have to slow down the speed or find some auto-calibration system which will be very complicated.

No problem Chema, I was not expecting everyone to drop everything to test unreliable tape loading

I think Fabrice did the best possible compromise between speed and reliability. TAP2CD is brilliant.

I've been trying to push the limits by using faster sinusoids, but I've been struggling ever since to try to make it run without modification on most Atmos (I don't even expect all).
I've also tried many different bits coding strategies, to finally find that what Fabrice did in TAP2CD is probably the best, so I'm using it. BTW little by little, trying to have more precision, my code gets closer and closer to Fabrice's TAP2CD (BTW Fabrice is giving a hand by replying to many questions I have )

Here's roughly how it works:
- At the moment, I'm using sinusoids of 3, 4, 5 and 6 samples, where TAP2CD uses IIRC, 4, 6, 8 and 10. It's faster but some Atmos don't like that, or give different values reading the lenght of each sinusoid.
- I've also added a kind of small RLE compression: every repeated byte will be coded with only a sinusoid of 5, 6, 7 or 8 samples (to repeat 1, 2, 3 or 4 times). So speed will vary with repetitions.
- based on my previous statistics, showing that globally Oric programs hold (IIRC) 60% of zeroes and 40% of 1, I used the shortest sinusoids to code zeroes: 3 is "00", 4 is "01", 5 is "10", and 6 is "11".
With both these "improvements", Zorgon's Revenge loads in 20 seconds (not counting the loader).

And finally I have in stock a dictionnary that codes the 14 bytes that take the longest time in the program to load (based on occurencies of unrepeated bytes and their length). I only made the program to make the signal, and Zorgon lasts then only 15 seconds - but I didn't implement the decoder yet. It will require heavy modifications and I'm not sure it's worth doing if in the end the thing only works on a few Atmos...

I wanted to make it more reliable first, if possible! Some sinusoids combinations lead to different lenght measure by the VIA, and some Atmos then mix for instance a 3 samples length with a 4 sample length. I think I found the best values and I'd like to see on how many machines it works, to see if it's worth carrying on.
I "only" have 3 Atmos at hand; the WAV test I posted works on two Atmos here, and the 3rd seems to have random errors which I don't understand yet (I made test programs and visually checked one by one about 150 bytes which had no mistakes in the Amos interpretation...)