Tape speed loading, OTLA revisited

Page 2/2
1 |

By gdx

Enlighted (5848)

gdx's picture

01-10-2022, 12:58

RvS wrote:

Well, I could, but I would need to have the correct ’poke -1,’ value for your system. This is currently hard coded in the loader.

The correct poke is: POKE-1,(15-PEEK(-1)\16)*17

By RvS

Expert (92)

RvS's picture

01-10-2022, 21:50

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.

By CASDuino

Champion (306)

CASDuino's picture

01-10-2022, 22:17

RvS wrote:

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

Highly unlikely. I've tried TZX files created by OTLA and they don't work on TZXDuino as it's a bizarre ID:15 type. I think the CASDuino firmware will just be too slow to keep up. So far I've only been able to get an OTLA file to work on OpenMSX and not on a real MSX even using playback from my PC. I've only tried my HX-10 as I'm not sure how well it would do on an MSX2.

By Manuel

Ascended (19059)

Manuel's picture

01-10-2022, 23:29

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

By CASDuino

Champion (306)

CASDuino's picture

02-10-2022, 04:31

Manuel wrote:

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

Hmmmm. They're ROM files and r2b doesn't work on 64 bit systems which is an issue otherwise it would be good. Definitely something that needs to be updated to modern systems although the source isn't available.

By RvS

Expert (92)

RvS's picture

26-10-2022, 18:49

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.

By RvS

Expert (92)

RvS's picture

26-10-2022, 18:41

CASDUINO wrote:

Highly unlikely. I've tried TZX files created by OTLA and they don't work on TZXDuino as it's a bizarre ID:15 type. I think the CASDuino firmware will just be too slow to keep up.

Challenge accepted Smile

Page 2/2
1 |