A few things about tape format... I'm not willing to be boring, I just want to be sure to understand the way things are working when everything's normal, because I'm currently struggling with complicated re-written loading routines... (I'm trying to adapt WAV2TAP to convert these re-written routines, but I wonder if there are not small differences that might prevent me from doing it).
So, open your Oric à Nu books at page 259 (or your 1.1 ROMs at E4AC), and WAV2TAP.C source code; here we go: we are now playing to the "correct me if I'm wrong" game
According to l'Oric à Nu, here's how I understand the loading process of a tape program in 1.1 ROM:
* First the Oric is searching for the synchro bytes (#16#16#16#16#16#16...), code in #E735:
- the Oric takes a bit from the tape
- moves a byte from 1 bit to the right, and adds the new bit
- as long as it's not #16, loop
- we have a #16, so the Oric is synched
- now take 3 bytes, see if they're #16 again. As soon as one of them is not, start the whole sync process again. If they're OK, continue.
So here we can draw this conclusion: the Oric needs FOUR CONSECUTIVE #16 bytes to consider the synch is ok: one to find the synch, and 3 to check the synch.
* Then the Oric loops, waiting for the #24 value, indicating the header beginning (code in #E4AC).
Here we can say that whatever there is between the four #16 bytes and the #24 bytes, the Oric will consider the program begins.
We could have the following values:
09 05 16 16 16 16 07 45 E2 A7 24 ...
the Oric would consider this is a correct synchro and load the bytes following #24 (header + program).
And now, WAV2TAP.C
We got this:
Code: Select all
synchronize()
{
int decaleur=0,val;
printf("Searching synchro...\n");
while(1) {
while((decaleur&0xff) != 0x68)
decaleur=(decaleur<<1)|getbit();
if (getbyte()!=0x16) continue;
if (getbyte()!=0x16) continue;
if (getbyte()!=0x16) continue;
do {
val=getbyte();
} while (val==0x16);
if (val==0x24) break;
}
}
- get synched with #68 value (which is #16 with reversed bits, as they are stored on tape); loop as long as you don't find #68
- get 3 bytes, as soon as one of them is not #16, start the loop again (== start the whole sync process again), if they're all #16 then continue
- get rid of all the other #16 you could find
- as soon as another value is found, test it. It must be #24, if not, start the whole sync process again. If it's #24, then consider the program begins.
So with WAV2TAP, if I'm not mistaken, we MUST have the following consecutive values to consider the synch is OK: 16 16 16 16 24
The former example (09 05 16 16 16 16 07 45 E2 A7 24) would not load.
That means anyone that intentionally changed one of the four #16 values before the #24, or any error in the tape signal on these values, will prevent WAV2TAP from transferring the program, but won't prevent the Oric from loading it if the Oric found four #16 values somewhere before...
Now please tell me I'm wrong, if I was sure of what I'm saying I wouldn't ask
Cheers,
Simon