Tape speed loading, OTLA revisited

I took a look at the load code and it is really well done. The OTLA people knew what they were doing.
For OTLA to work at high speed, you need high quality audio like CD/DAT/PC audio cards for exact timing of signals.
There is some code to synchronise, and even a simple 'crc' calculation included.
The main decoding routine here below does all the hard work. It uses a lookup table that is filled with values:

a times (11111100b) 0xfc 'AND' mask value to create '00'
b times (11111101b) 0xfd 'AND' mask value to create '01'
c times (11111110b) 0xfe 'AND' mask value to create '10'
d times (11111111b) 0xff 'AND' mask value to create '11'
e times (01000000b) 0x40 value

The values a-e are pre-calculated by the OTLA builder program and depend on the selected bitrate/speed
The A register is used to hold both the counter value and the data value.
In 4 cycles, a byte is written because the A register is loaded with 0xfe and after each rica,rla
bit 0 and 1 are always 1. Depending on the length of the audio pulse/cycle, those bits are masked
with the 'AND' value. After the last rica,rla cycle, carry is zero and the byte is written.

The routine is balanced so each branch has roughly the same number of T cycles.

There are no checks on the file length or bytes written. The routine stops if pulses are received that are
longer than normal data pulses. In this case, the mask values (0x40) leave bit7 0 causing the jp m, to fall through.

The routine also xor's all bytes written and keeps that value in register B.
When the file is created, this 'crc' value is placed before the rest of the data at start-1.
The value of (start-1) is saved and restored by the loader program.
This means that the value for B after loading must always be 0.

cycle	bit	C	7	6	5	4	3	2	1	0	
	A	x	1	1	1	1	1	1	1	0	0xfe
1	rlca	1	1	1	1	1	1	1	0	1	
	rla	1	1	1	1	1	1	0	1	1	
2	rlca	1	1	1	1	1	0	1	1	1	
	rla	1	1	1	1	0	1	1	1	1	
3	rlca	1	1	1	0	1	1	1	1	1	
	rla	1	1	0	1	1	1	1	1	1	
4	rlca	1	0	1	1	1	1	1	1	1	
	rla	0	1	1	1	1	1	1	1	1	

The code will 'time' the cycle in the 'l' value and

store:
        and  h          ;(5)
        ld   (de),a     ;(8)    store data at (de)
        xor  b          ;(5)    xor all bytes stored with b (simple crc)
        ld   b,a        ;(5)
        ld   a, $fe     ;(8)  new byte 11111110b
enter:
more: 
HIGH:
        inc  l          ;(5)
        in  f , (c)     ;(14)       
        jp  p , HIGH    ;(11) loop until cas bit=1 (wait for cas input=HIGH)

        inc  de         ;(7)
        ld  h, table_H  ;(8)
        ld  h,(hl)      ;(8)
        ld  l, table-2  ;(8)
        rlca            ;(5)   rotate left, bit 7->bit 0 and bit 7-> carry
        rla             ;(5)    rotate left, carry -> bit0, bit 7 -> carry
LOW:
        inc  l          ;(5)
        in   f,(c)      ;(14)
        jp   m, LOW     ;(11) loop until cas bit=0 (wait for cas input=LOW)

        jp  nC, store   ;(11) starting with $fe, after 4 cycles of rlca,rla carry=0
        dec  de         ;(7)
        ld   b,b        ;(5) dummy
        and  h          ;(5)
        jp   m, more    ;(11)

Next step is the creation of simple OTLA tool and see if this could be integrated in tape solutions like CASDUINO.

This shows it works on real hardware: https://www.youtube.com/watch?v=ALueW5soXgU (and several other videos seem to exist).

On a real MSX, the tape input circuit can affect the OTLA data stream.
On my NMS8245 I have tried to find the signal amplitude at which point the tape bit in PSG register 14 starts to change.
Depending on the OTLA settings, the highest frequencies are 24, 22.05, 12 or 11.25 kHz.
At those frequencies, you need more volume/amplitude to register the signal on the MSX.
OpenMSX just reads the .wav file and (currently?) does not have these machine dependent filters.