1) Reading bytes of data on a real tape :
In some cases, it is impossible to do since the game or the program was saved (and loaded back) with a custom machine code routine that saved the bits of data without the standard leading and trailing bits of parity and so forth.
In effect, the rom usually writes one byte as 13 bits on tape: a starting 0, eight bits of data, a parity bit, and three 1 bits.
The process of converting a real tape into a tap file, is to read those blocks of 13 bits and then keep only the 8 bit of data, stripping the useless...
Now, for instance, if the main program was saved with a custom routine, writing only the bytes of data on the real tape, you cannot convert it back with wav2tap (mine or Fabrice's). And you are obliged to deal with a big wav file... (it's hard to hexedit the analog bytes of an Oric wav file !!! )
Example of programs that fail to be converted : Side B of Tyrann, Cobra (snake game from Norsoft), and many others.
2) Silences :
We can also imagne that, Sometimes, the silence duration was a mean of protection.
3) Pause of the tape player/recorder and tap file hell with euphoric....
Well, if you have more than one program on the tap file and that you are asked to stop your tape player by the program, it is not easy to do so with Euphoric (since there is no silence between two portions of code).
I think there is the need to include a kind of automatic stop on the tap file... It can be very usefull (to navigate quickly between programs on the same tap file for instance) : example ---> Tyrann, side A
The new format proposed, is a bit-to-bit translation of the real tape rather than a byte by byte, like this :
Real Tape New tap file data
pairs of bits are then grouped by 8 bits in order to form bytes of the new tap file.
Code: Select all
0 00 1 01 pause* 10 silence 11
If the last bit of a conversion fails to be the first, the 2nd or the 3rd pair of bits of the group of 8 bits, pairs of '11' should then be append to the last byte in order to complete it.
* (well it does not exist on the real tape, but some programs "auto-stp" the data player motor (usually small jack input of the tap player, din motor relay pins on the oric side).
Well, with this, we should be able to numerize any real tape.
Of couse, it would lead to a file format less compact than the tap file format we know, but at least less big than a wav file...
What do you think ?