Experimental very fast tape loading
Re: Experimental very fast tape loading
Man you rock! What you achieved here is fantastic!
Re: Experimental very fast tape loading
Thanks!
Small programs seem to work on real machines, but not bigger ones.
Seems like I'm back with some threshold/timing/audio source issues, I must say I'm getting a bit tired of it! (and blind when the loading hangs on real machines, no way to go back to the interpreter and save the memory).
Enough for tonight![Wink ;)](./images/smilies/icon_wink.gif)
Small programs seem to work on real machines, but not bigger ones.
Seems like I'm back with some threshold/timing/audio source issues, I must say I'm getting a bit tired of it! (and blind when the loading hangs on real machines, no way to go back to the interpreter and save the memory).
Enough for tonight
![Wink ;)](./images/smilies/icon_wink.gif)
Re: Experimental very fast tape loading
I wonder if it's possible to implement "ripping cartridges" on the Oric.
On machines like the Commodore 64, Atari ST, etc... it was possible to plug cartridges on the expansion bus, and by pressing some button you would reset the machine using the cartridge instead of the on-board rom, which would preserve the state of the memory and allows you to see what was there, search for graphics, fonts, sprites, but also disassemble source code or view memory in hex, eventually saving that to disk.
I guess on the Oric that could be done with a dual ROM, or maybe by replicating the Microdisc boot process with a 16KB eprom overlayed on top of the ROM.
Re: Experimental very fast tape loading
Such a system would be cool ![Wink ;)](./images/smilies/icon_wink.gif)
Even just a memory save on tape or anything actually![Very Happy :D](./images/smilies/icon_biggrin.gif)
Anyway, I think I found the problem, while trying to add more bytes at the end of the signal, I managed to have Zorgon loading completely - with a few errors. I also slowed down the signal reading from 44100Hz to 43500Hz (about 1% slower) and it loaded Zorgon perfectly on a real Atmos with ROM 1.0 and ROM 1.1
The thing is: by re-structuring the code, I had added 1 more microsecond to access to the dictionary decoding, and it seems to be the cause of the failure: a bit too short and when dictionary is accessed several times in a raw, it ends up missing a sinusoid.
Each access requires 27µs, so apparently, I have 26µs maximum as spare time to process the signal and not miss something when there are several 3-samples sinusoids in a raw (69µs each).
To be checked, but I think I can re-structure it all to save 2 or 4 microseconds before accessing the dictionary (and slow down another data to be accessed, without harm I hope).
![Wink ;)](./images/smilies/icon_wink.gif)
Even just a memory save on tape or anything actually
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Anyway, I think I found the problem, while trying to add more bytes at the end of the signal, I managed to have Zorgon loading completely - with a few errors. I also slowed down the signal reading from 44100Hz to 43500Hz (about 1% slower) and it loaded Zorgon perfectly on a real Atmos with ROM 1.0 and ROM 1.1
The thing is: by re-structuring the code, I had added 1 more microsecond to access to the dictionary decoding, and it seems to be the cause of the failure: a bit too short and when dictionary is accessed several times in a raw, it ends up missing a sinusoid.
Each access requires 27µs, so apparently, I have 26µs maximum as spare time to process the signal and not miss something when there are several 3-samples sinusoids in a raw (69µs each).
To be checked, but I think I can re-structure it all to save 2 or 4 microseconds before accessing the dictionary (and slow down another data to be accessed, without harm I hope).
Re: Experimental very fast tape loading
Okay, tongith Xenon-1 and Zorgons Revenge loaded on real Oric with ROM 1.0 and ROM 1.1
So now, still want to do:
- an option to use a 100% standard speed loader (or F16 will be the option, depending on tests)
- an option to use the previous one-part Novalight (ROM 1.1 only this time) so it doesn't have to be loaded for each part, but the user will have to design his own small multipart loader like 10 HIRES:CALL#100:CALL#100:CALL#100
- change the C code a bit so thresholds can be changed easily
- more tests, more tests
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
So now, still want to do:
- an option to use a 100% standard speed loader (or F16 will be the option, depending on tests)
- an option to use the previous one-part Novalight (ROM 1.1 only this time) so it doesn't have to be loaded for each part, but the user will have to design his own small multipart loader like 10 HIRES:CALL#100:CALL#100:CALL#100
- change the C code a bit so thresholds can be changed easily
- more tests, more tests
Re: Experimental very fast tape loading
Ok, everything is coded. Now I need to check the thresholds again. I've had bad surprises with a few games, and Fabrice seems to keep having problems too. And with the F16 speed too. I'm a bit worried.
Re: Experimental very fast tape loading
Discovered something today. Good news, and a question!
Some of the Orics that I thought would not work with Novalight actually work for some of them... By changing the volume on the PC playing the WAV, from maximum (working on 80% of the machines) to minimum!
I guess the signal was so loud that the Orics were not able to make the difference at 100% between 3 or 4 samples.
But how is it possible that such a volume level difference is required from a machine to another?
Some of the Orics that I thought would not work with Novalight actually work for some of them... By changing the volume on the PC playing the WAV, from maximum (working on 80% of the machines) to minimum!
I guess the signal was so loud that the Orics were not able to make the difference at 100% between 3 or 4 samples.
But how is it possible that such a volume level difference is required from a machine to another?
Re: Experimental very fast tape loading
I really have no idea, but Orics have always been very picky with volume settings. I think something is wrong with all the input circuitry.
In my experience most games load with my laptop volume at 80% as you said, but some may need less volume. I usually start with very low volumes and move up until the game loads because my rom will issue an error quickly for low volumes (or won't go further than Searching), but keep at Loading forever if the signal is too high.
If you want me to test anything, just send me the wav files and I will give them a try in my Atmos.
In my experience most games load with my laptop volume at 80% as you said, but some may need less volume. I usually start with very low volumes and move up until the game loads because my rom will issue an error quickly for low volumes (or won't go further than Searching), but keep at Loading forever if the signal is too high.
If you want me to test anything, just send me the wav files and I will give them a try in my Atmos.
Re: Experimental very fast tape loading
Some of my Orics have zener diodes at the input of the OpAmplifier. The idea is to limit the input amplitude of the signal (also good for protection) but this can change the required volume level. If you can open your Orics and take pictures on the analog part (on left side of the ULA) and note which picture works well at what volume, it would be helpful for statistic and to understand the difference.
Re: Experimental very fast tape loading
I'm away from those Orics for a couple of weeks, but will picture them when I can!
- NekoNoNiaow
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: Experimental very fast tape loading
If you can publish the code I would love to give it a look this week end.Symoon wrote: ↑Tue Apr 24, 2018 11:59 am The thing is: by re-structuring the code, I had added 1 more microsecond to access to the dictionary decoding, and it seems to be the cause of the failure: a bit too short and when dictionary is accessed several times in a raw, it ends up missing a sinusoid.
Each access requires 27µs, so apparently, I have 26µs maximum as spare time to process the signal and not miss something when there are several 3-samples sinusoids in a raw (69µs each).
To be checked, but I think I can re-structure it all to save 2 or 4 microseconds before accessing the dictionary (and slow down another data to be accessed, without harm I hope).
I know I said that a few weeks ago and did not have a chance to do it but I promise to do better.
![Wink ;)](./images/smilies/icon_wink.gif)
Yup, it is likely due to differences in the amplification/binarization stage of the circuit.iss wrote: ↑Sun May 06, 2018 11:24 pm Some of my Orics have zener diodes at the input of the OpAmplifier. The idea is to limit the input amplitude of the signal (also good for protection) but this can change the required volume level. If you can open your Orics and take pictures on the analog part (on left side of the ULA) and note which picture works well at what volume, it would be helpful for statistic and to understand the difference.
I gave a look at the schematics for this digitizing stage a few weeks ago and from what I understand the normal variation of precision in the resistors/capacitors across models would not be sufficient to explain the sensitivity to volume difference so I suspect that different models might use slightly different resistor values which would lead to different amplification results and thus different thresholds for a given value to be interpreted as 1. Some models could very well end up being too sensitive.
Having pictures of the different boards where the colors of the resistors stripes are clearly visible in the area around the input connector would definitely help.
One thing that could also be attempted when generating the audio file:
- try using square waves instead of sine waves, this will guarantee that "0" volumes cannot be interpreted as "1"s.
- Then, test with full volume again on the Atmos which requires a low volume.
You could also try using square waves with tapered edges as an intermediary between sine waves and squared ones:
Code: Select all
__ __
__/ \__/ \__ ...
Re: Experimental very fast tape loading
@NekoNoNiaow: I'll send you the source code.
Actually I'm quietly writing the docs while waiting for some feebcak from testers.
I tested the thing, working on 10 machines and not working on one (that never ever loaded anything at high speed).
I have to test again in a few weeks, since I would like to try with thresholds that work with Euphoric too (not the case with the ones I tested).
Actually I'm quietly writing the docs while waiting for some feebcak from testers.
I tested the thing, working on 10 machines and not working on one (that never ever loaded anything at high speed).
I have to test again in a few weeks, since I would like to try with thresholds that work with Euphoric too (not the case with the ones I tested).
Last edited by Symoon on Tue May 08, 2018 8:42 am, edited 1 time in total.
Re: Experimental very fast tape loading
Have you checked your spam folder?
Gmail almost systematically sends my emails there, don't know why
![Sad :(](./images/smilies/icon_sad.gif)
![Sad :(](./images/smilies/icon_sad.gif)
![Sad :(](./images/smilies/icon_sad.gif)