New tape loading speed - testers needed!

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: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

New tape loading speed - testers needed!

Post by Symoon » Sun Jun 26, 2016 3:05 pm

Hi there,
I'm working on a tool called TAP2F16 for ".TAP to Fast *1.6 speed". The tool produces a 44kHz WAV file that, you guessed it, runs around 1,6 times faster than original tapes. That means for instance that a program loading in 5mins will now load in 3mins.

You may wonder "why?", since TAP2CD already does a similar job much, much faster?
Well, TAP2F16 has the advantage of loading on standard Orics, without any loader, or ROM modification. So it should work on Atmos and Oric-1 as well, and maybe (no guarantee) load some programs that didn't work with TAP2CD (Lone Raider for instance).

But so far I only could test it on Atmos (ROM 1.1). Could anyone help and make a test on a real Oric-1? You can find attached a ZIP with Lone Raider.
Of course you can also test it on your Atmos to confirm it's working - or not. As I'm really playing with the limits of the ROM decoding routines, any test is welcome.

Thanks in advance :)
Attachments
loneraidF16.zip
Lone Raider Fast 1*6
(269.62 KiB) Downloaded 114 times

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

Re: New tape loading speed - testers needed!

Post by Chema » Mon Jun 27, 2016 10:07 am

Hi Symoon!

I have just returned from a mini-vacation :) As soon as I have some time to set up my Oric I will test. If you don't get feedback from me in a couple of weeks, drop me an email (just in case I forgot!! :) )

Great idea!

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

Re: New tape loading speed - testers needed!

Post by Symoon » Mon Jun 27, 2016 1:02 pm

Thanks Chema; I should be able to test it next weekend on an Oric-1 - at least I hope so ;)

BTW I forgot to say, but of course you need a digital player, it certainly won't work on "real" old tapes.

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

Re: New tape loading speed - testers needed!

Post by Symoon » Sat Jul 02, 2016 7:38 pm

Tested and working fine on Oric-1 :D :D
I loaded Lone Raider and Zorgons Revenge and they ran like a charm.
Woho !

Time for me to change a few things and I'll release the tool.

EDIT: also loaded Oricium on an Oric-1, in 3min32 instead of 5min41, works like a charm and what a scrolling! :)

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

Re: New tape loading speed - testers needed!

Post by Symoon » Sat Jul 09, 2016 11:44 am

Okay, I just released Tap2F16, you can find it with the other Oric Tape Tools, exactly here:
https://sourceforge.net/projects/euphor ... s/Tap2F16/

Feedback welcome ;)

This tool, based on Fabrice's TAP2WAV, converts Oric .TAP files to 44kHz (big) WAV files designed to work on any standard Oric, but that will load about 1.6 times faster than the usual FAST speed - "F16" standing for "Fast *1.6".
One may wonder "why?", since TAP2CD from Fabrice already loads programs much, much faster. Well here the challenge was: what can be achieved with zero hadware or software change? So a few more programs work, and it also works on Oric-1's ROM 1.0. No impressive upgrade but funny to see that digital player reliability allows an average 38% improvement.

THE IDEA
So you got it: no special routines here, just an optimized tape signal. It was based on a study of the ROMs.
The standard signal, in FAST, codes a bit "1" by a 416 microseconds sinusoid (2 x a 208µs duration), and a "0" by a 624µs sinusoid (3 x 208µs). When reading a tape, the VIA 6522 detects a sinusoid, then sends a flag to the Oric, which will start counting the time between it and the next one (and so on).
Then Oric compares this duration to 512µs (which is the middle between 416 and 624µs), and stores a "0" bit for a longer duration, or a "1" for a shorter duration. So there is an 20% margin which was useful with 1980's tape players running at different speeds.

This decoding method is interesting with nowadays digital players, which offer good audio quality and perfect reading speed. So let's try and save loading time on two sides:
1- the 20% margin is now useless
2- the "1" bit has no minimal length! So it can be much shorter... Its only limits are harware response and ROM decoding time.

After painful counting of ASM instructions duration, confirmed by testing with a small program, the results show that the minimal duration for a "0" is 529µs (at 44kHz, which is 23 samples), and 115µs for a "1" (5 samples). Try to remove ONE sample to any of these values, and the Oric won't load anymore.

So you can see right now that you'll need a PERFECT WAV player, without any audio interference - a single sample not read and it's over. For instance, on my PC, I need to shut down WiFi, and even to reboot it from time to time - seems after a while it's not able (or doesn't have enough ressources anymore) to read WAV files perfectly.

This has been successfully tested on Atmos and Oric-1, even the display of the program name, or the making of a whole byte is OK, the Oric still has time to compute them even if the stop bits are shorter (and BTW, I set 3 stop bits, instead of 4 with TAP2WAV, to save a little more time).


THE PROGRAM
You should find TAP2F16.EXE compiled in two versions: 16 and 32 bits, as well as the source code in TAP2F16.C. 16 bits if for older machines still running real MS-DOS, 32 bits should run on recent computers (even 64 bits)

Just type: TAP2F16 yourprogram.TAP wavfilename.WAV

In case of failure, I have added a "-o" ("old machine") switch which adds an extra sample (so 23µs) to each "0" and "1" bit. I'm not sure it's really useful, but it may help if your Oric fails to load (or if the comptuer fails playing the WAV file properly!), at the price of a longer loading time...

User avatar
iss
Flight Lieutenant
Posts: 495
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: New tape loading speed - testers needed!

Post by iss » Sat Jul 09, 2016 12:18 pm

Symoon, thank you for the tool!
Nice idea and implementation and very informative explanation.
I can confirm, that Tap2F16 works under Linux 32/64 too. ;)
There are 3-4 harmless warnings during compilation, but that's no problem at all.

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

Re: New tape loading speed - testers needed!

Post by Symoon » Sat Jul 09, 2016 12:21 pm

iss wrote:There are 3-4 harmless warnings during compilation, but that's no problem at all.
Thanks for the feedback :)
Warnings are very likely with me, I'm a crappy C programmer (only learnt it in 1998 and never really used it since then).
I wouldn't have been able to do anything if Fabrice didn't code his tools in the 1st place ;)

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

Re: New tape loading speed - testers needed!

Post by Symoon » Sat Aug 06, 2016 1:07 pm

I've updated the tool, changing the waveform so the signal is smoother for the 6522 (I think the previous version was not that good).
If you ever failed to load, you can download and try again!

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: New tape loading speed - testers needed!

Post by ThomH » Tue Nov 08, 2016 3:13 am

Symoon wrote:THE IDEA
So you got it: no special routines here, just an optimized tape signal. It was based on a study of the ROMs.
The standard signal, in FAST, codes a bit "1" by a 416 microseconds sinusoid (2 x a 208µs duration), and a "0" by a 624µs sinusoid (3 x 208µs). When reading a tape, the VIA 6522 detects a sinusoid, then sends a flag to the Oric, which will start counting the time between it and the next one (and so on).
Then Oric compares this duration to 512µs (which is the middle between 416 and 624µs), and stores a "0" bit for a longer duration, or a "1" for a shorter duration. So there is an 20% margin which was useful with 1980's tape players running at different speeds.
Apologies; possibly this is a bit of a derailment but it's pretty clear you're on top of this stuff so is it okay to ask a quick couple of questions about the ROM routines for tape reading?
  • per Hardware programming on the Oric in fast mode the wave produced for a '1' is a 208µs segment plus another 208µs segment, and the wave produced for a '0' is a 208µs segment followed by a 416µs segment. From what you're saying it sounds like all the ROM measures is the sum of the two? It would be equally happy, even with a real speed-variable tape, if the '1' were two 312µs segments?
  • is the ROM deliberately or impliedly sensitive to phase? E.g. is it always summing one low then one high (or vice versa), or merely taking the time between each transition and tracking the rest of a byte from the first thing that looks like a 0 through until it's got the parity bit?

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

Re: New tape loading speed - testers needed!

Post by Symoon » Tue Nov 08, 2016 11:48 pm

ThomH wrote:per Hardware programming on the Oric in fast mode the wave produced for a '1' is a 208µs segment plus another 208µs segment, and the wave produced for a '0' is a 208µs segment followed by a 416µs segment. From what you're saying it sounds like all the ROM measures is the sum of the two? It would be equally happy, even with a real speed-variable tape, if the '1' were two 312µs segments?
Two 312µs segments would probably give a '0'. Those segments are a convenient way to describe/generate the signal, but they're not used to decode it.
From (my bad) memory here's how it works:
- the 6522 detects a positive transition
- then its 16-bits timer begins to decrease, starting from #FFFF (in µs)
- another positive transition is detected by the 6522
- then the Oric ROM saves and checks the higer timer byte value: if it's lower than #FE then it's a '0' (time has decreased more than twice 256µs), if it's equal or higher (#FExx or #FFxx) then it's a '1' (time has decreased less that twice 256µs)
The only important things about the signal are:
1- it has to be done so the 6522 detects positive transitions
2- it has to let the right amount of time pass between those transitions
ThomH wrote:is the ROM deliberately or impliedly sensitive to phase? E.g. is it always summing one low then one high (or vice versa), or merely taking the time between each transition and tracking the rest of a byte from the first thing that looks like a 0 through until it's got the parity bit?
So it's based on time. Starts decoding a byte (+parity) with a '0' start bit, and loops on stop bits ('1') waiting for the next start bit.

Hope this helps ;)

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: New tape loading speed - testers needed!

Post by ThomH » Wed Nov 09, 2016 12:41 am

Thanks! That's helped a lot. Of the platforms I happen already to know about, that's actually really close to the way the Vic-20 does it: on that platform a 1-bit version of the input wave is connected to a VIA control line to catch transitions in one direction only, counted against that VIA's second counter; the implementation then diverges only because Commodore's code waits for an interrupt either way: if it was the timer interrupt then that's a long wave, if it was the control line input then it's a short.

Whatever though, thanks for the info. I'll adjust my thing immediately.

User avatar
iss
Flight Lieutenant
Posts: 495
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: New tape loading speed - testers needed!

Post by iss » Tue Aug 08, 2017 10:30 pm

Symoon, I want to confirm (one year later :)) the minimal duration for a "0" is 529µs and for a "1" - 115µs.
Currently I'm using successfully T0=541µs and T1=125µs and the loading is very reliable even with WiFi turned on ;).
Unfortunately, strange problem occurs at first 3-4 bytes of the read data - I mean exactly the data (!) - the header is loaded OK, the name of the program is displayed OK, the start and end address are OK, but not the first bytes.
Do you have ever experienced such error?
I hope to fix this issue and there will be surprise (or two) for all :).

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

Re: New tape loading speed - testers needed!

Post by Symoon » Wed Aug 09, 2017 5:21 am

Interesting ;)
The thing is that, after the header is loaded, there are several operations done by the Oric: displaying the program names, and so on.
This requires time, and IIRC when saving there are more than 3 stop-bits sent right after the end of the header (from memory, it's 4 or 6 stop bits, but check it again please!).

So if there aren't enough stop-bits in the signal (after the header) to give time to process the name display, the following bytes are affected when loading back the program. As the stop bits are "1" and their time is shortened a lot with F16, maybe that's the problem.
Tap2F16.c (just like Tap2wav) builds the WAV file with MANY MORE stop-bits than the ROM after the header: 100 instead of the "4-or-6-I-can't-recall", so there's plenty of time.

I wonder if this, plus the fact that your duration values are different from mine, is not giving a hint on what your surprise could be :-p

EDIT: found back what I had checked: with Euprhoric, ROM 1.1, fast AND slow speed: 6 stop bits instead of 3 after the program's name. Though I trust Euphoric, it would be safe to confirm with a real machine (or a ROM instructions analysis), and with ROM 1.0 too as routines were modified between 1.0 and 1.1.

User avatar
iss
Flight Lieutenant
Posts: 495
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: New tape loading speed - testers needed!

Post by iss » Wed Aug 09, 2017 8:11 am

Thanks, Symoon! I knew it you can help me! ... and always is good to read the sources carefully:

Code: Select all

void emit_gap()
{
  int i;
  /* un paquet de bits stop pour laisser le temps d'afficher la ligne de statut */
  for (i=0;i<100;i++) emit_bit(1); 
}
I missed this during the fight with other serious issues. I'll check tonight and will report back the result.
Else, yes, my timings are really hint - they are based on 48000 sampling rate which is the native playback sampling rate on many hardware platforms, for instance android :twisted: ....

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

Re: New tape loading speed - testers needed!

Post by Symoon » Wed Aug 09, 2017 8:18 am

Oooooh :)
I thought you were working on saving at fast speed on real Oric, I was wrong :)

(Android 2.3 or further? I'm old school in new techs ;) )

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests