|
The Hires-image on the right is an exact inverse of the left. Both have the same color-ram ($10), so the white image consists mainly of 1 bits while the black one mainly of 0 bits. In TurboTape a 0 bit is represented by a shorter interval between negative flanks than for 1 bits. This can clearly be seen from the shorter loading-times. The output given is from a PRG->TAP converter of mine. Note the identical checksum even though the data differs! This reveals the weak spot of using a 1-byte EOR checksum (two $ff have the same effect than $00's which habe no influence on EOR checksums at all). The bottom images show the evolution of the EOR-Byte (0-255) over the data position (0-8000). As you can see the $FF bytes merely cause it to swap between two values or rather mirror, whereas the $00 bytes have no influence at all. The action in the center is due to the Text area. |
Test-image (hires bitmap) 1: TAP-name : test1.tap FILE-name : test1.prg DATA-start : $1f40 (#8000) DATA-end : $3f40 (#16192) DATA-length : $2000 (#8192) DATA-checksum : $3c (#60) TAP-length : $11fb0 (#73648) TAP-Time : 0:24.81  EOR-checksum value over data position:  |
Test-image (hires bitmap) 2: TAP-name : test2.tap FILE-name : test2.prg DATA-start : $1f40 (#8000) DATA-end : $3f40 (#16192) DATA-length : $2000 (#8192) DATA-checksum : $3c (#60) TAP-length : $11fb0 (#73648) TAP-Time : 0:17.90  EOR-checksum value over data position:  |
|
(btw, if you want to load the PRG or TAP file yourself, launch with SYS 8000) The higher frequency for 0 bits is obvious. Time for some numbers: In this TAP format a 0 bit is encoded as $1a and a 1 bit as $28. Multiplied by 8 you get the amount of cycles: bit 0: 208 cycles bit 1: 320 cycles Divided by the amount of cycles per rasterline you get roughly about 3 lines versus 5 lines between consecutive signals. This is a difference of 35%! After all the black image loads about 25% faster (since it does include a displaycode and white areas). Data in test1.tap consists of 10.038 0-bits and 63.602 1-bits. Data in test2.tap consists of 70.786 0-bits and 2.854 1-bits. (uneqal ratios due to displaycode) Packers/crunchers for use with tape should thus try to favor 0 bits. A simple approach would be a mere EOR over all data to achieve the maximum amount of 0 bits. And some additional information: Including a header and leading/secluding pauses, the speed at which the 2nd image loads is about 3660 baud = 458 Byte/s. That beats the ROM-loader for the 1541 Floppy with about 400 Byte/s. For Turbo Tape the loading speed ranges from amazing 4740 Baud (0 bits only) to 3080 baud (1 bits only). In average 3900 baud but without the pauses and the header, so expect about 3800 baud for large files. (note that these estimates are the average speeds over a whole file, not the streaming values which are higher of course). |