In short, it's for a great part based on Fabrice's TAP2CD and adds a few improvements (if you don't know TAP2CD, it's been there for 20 years now and is really great, you can find it with the Oric Tapetools).
- TAP2CD codes TWO bits (11, 10, 01, 00) using 4 different sinusoids for the WAV signal. This new loader does the same, but using 44kHz, it allowed to use faster sinusoids. IIRC TAP2CD used the equivalent of 4, 6, 8 and 10 samples for each sinusoid where the new loader uses 3, 4, 5 and 6. It's been the most painful work so far: the sinusoids are so short that I had to test (with the help of Oricians
) many different ways of "drawing" the signal to see which one allowed the Oric to read them in the best possible way. Most of the time, it mixed one for another, and worse: results differ from an Atmos to another. TAP2CD remains more universal and this new loader will not work on some Atmos.
- statistics had been made a while ago, and we noticed Oric programs were made of "0" bits at about 60%. So "00" is coded by the shortest sinusoid (TAP2CD uses it for "11" I think). This is not a critical and systematic improvement, just statistic.
- a RLE compression has been added: if a byte is repeated N times, it is coded only once in the signal, and is followed by N "repetitions". N repetitions are coded by (N-1) fastest sinusoids (3 samples), and ended by a 4 samples sinusoid for the last repetition.
- a dictionary has been added: before creating the signal, the TAP file is analysed and the most the most "repeated unrepeated" bytes (i.e. most repeated out of the RLE compression) are stored in two 7-bytes tables. Those tables are loaded in page 2 with the header and the program name. Bytes from those tables will be coded in a special way, faster than a "normal" byte.
- stop bits have been suppressed. Only a start bit remains, lasting 6 samples for a "normal" byte to follow, 7 or 8 samples for a byte that is stored in one of the two dictionnaries, and 9 samples for bytes repetitions (RLE). Why not using 3, 4 or 5 samples: because the Oric is busy working during this time, decoding and storing in memory the previous byte. It does require those 138 microseconds (so one could say stop bits have been suppressed but actually are merged with the start byte
I'm almost there. Still struggling to have everrything working in those 138 microseconds, seems like I only have a last problem at the end of a page (filling a new page requires a few more microseconds... Got to find where to save time, won't be easy now