longpulses

Handling of long pulses

TAP version 0

According to the original TAP specification, long pulses are encoded like this:

The data byte value of 00 represents overflow, any pulselength of more than 255*8 cycles.

Since this is somewhat underspecified, mtap2 uses the following definition:

The data byte value of 00 represents a long pulse value of 2500 * 8 cycles.

• Long pulses pl (pl = (cycles+7)/8) recorded from the original tape, with pl > 255 are split up into n 00 pulses, with n = (pl + 2499) / 2500
• As a special case, all pulse lengths pl with 255 < pl <= 2500 are encoded as exactly one 00 pulse.

TAP version 1

According to TAP spec, in TAP version 1 long pulses are encoded like this:

Data value of 00 is followed by three bytes, representing a 24 bit value of C64
cyles (NOT times 8). The order is as follow: 00 <bit0-7> <bit8-15> <bit16-24>.</bit16-24></bit8-15></bit0-7>

This allows for a more precise representation of long pulses:

• Long pulses pl (pl = cycles) are split up into n parts of length 0xffffff; save (n-1) pulses of layout 00 ff ff ff.
  followed by a pulse 00 xx xx xx, with x = pl % 0xffffff.
• Split the remaining cycles into two long pulses of the same length.

This ensures that there no artificial "short" pulses are created.

TAP version 2

For TAP version 2 splitting of pulses into half-pulses needs to be considered.

• n = (cycles / 0xffffff); save (n-1) pulses 00 ff ff ff
• for the remaining cycles: 2500 < cycles < 2*0xffffff
• if (n-1) is even: save 2 pulses with length (remaining cycles / 2)
• if (n-1) is odd: save 3 pulses with length (remaining cycles / 3)

This ensures that there is always an even number of long "half" pulses, and no artificial "short" pulses are created.