| |
Krill
Registered: Apr 2002
Posts: 2855 |
Release id #197710 : Transwarp v0.64
General Q&A thread, also report problems and error logs here. |
|
... 162 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2855 |
A few words about the encoding scheme.
As is easy to see, it works with plain d64 images, effectively storing 224 bytes of data in a standard Commodore GCR disk block.
Also, attentive readers of the source might have noticed that just a single decoding table of $ae bytes with $69 entries ($45 spare gap bytes) is used.
Here's how it works:
Commodore GCR encodes 4 bit raw nibbles to 5 bits on disk, or 4 bytes raw to 5 bytes on disk.
Enumerating all possible values these 5 bytes can take, we get:11111111 11222222 22223333 33333344 44444444
$60 $60 $79 $60 $60 That's about 6.58 bits of entropy for the 4 outer GCR bytes each, and 6.92 for the middle GCR byte.
However, the possible values the bytes may have are determined by their predecessor (except the first byte).
After "decorrelating" these 5 sets of values, we are left with11111111 11222222 22223333 33333344 44444444
$40 $60 $19 $60 $40
6 6.58 4.64 6.58 6 So we can store 6 + 6 + 4 + 6 + 6 = 28 bits of data without interdependencies of the individual 5 GCR bytes in the same space where Commodore GCR encodes 32 bits.
When combining these reduced sets of possible values for all 5 GCR bytes, we get aheat map:
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- 08 08 08 -- 08 08 08 -- 08 08 08
30: -- -- -- -- -- 08 08 08 -- 08 08 08 -- 08 08 08
40: -- -- -- -- -- -- -- -- -- 18 19 19 -- 19 19 18
50: -- -- 13 13 02 1b 1b 1a -- 18 1b 1b 02 1b 1b 0a
60: -- -- -- -- 02 0a 0a 0a -- 18 1b 1b 02 1b 1b 1a
70: -- -- 13 13 02 1b 1b 1a -- 18 1b 1b 02 13 11 --
80: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
90: -- -- 03 03 02 07 03 06 -- 04 03 07 02 07 03 02
a0: -- -- -- -- 02 0e 0a 0e -- 1c 1b 1f 02 1f 1b 1a
b0: -- -- 13 13 02 1f 1b 1e -- 1c 1b 1f 02 1f 19 08
c0: -- -- -- -- -- -- -- -- -- 18 19 19 -- 19 19 18
d0: -- -- 13 13 02 1f 1b 1e -- 1c 1b 1f 02 1f 1b 0a
e0: -- -- -- -- 02 0e 0a 0e -- 0c 0b 0f 02 0f 0b 0a
f0: -- -- 03 03 02 0b 0b 0a -- 08 0a 0a 02 02 -- --
length 0xd9, offset 0x25, used 0x8a, density 63.6%, unique 0x0d
longest gap 0x13, gap space 0x2a The byte values here are just a bitfield to show which of the 5 GCR bytes may take on the index value.
Now, it takes a bit of trial and error for carefully picking 6-bit values to assign to each byte in a table like this, such that:
- each of the 4 outer GCR bytes can reach all 6-bit values from $00 to $3f
- the middle GCR byte can reach all 4-bit values from $00 to $0f.
There are many possible variations to satisfy these constraints, and the final decoding table can also be somewhat smaller than the heat map, as there are more than $40 value bytes to choose from across all 5 GCR bytes. So secondary goals are:
- minimise table size
- maximise gap space to stuff with code and data. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
still trying to understand this, after 10 minutes I understood what you mean in the first part by bit entropies but still not understanding how your table works. how do you encode data into krill gcr ? |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting Oswaldhow do you encode data into krill gcr ? There are 5 different encoding tables for the 5 GCR bytes. 4 of them have $40 entries, 1 of them has $10 entries.
These encoding tables map raw 4- or 6-bit values to encoded GCR bytes.
The constraint is that an encoded GCR byte must map to exactly one decoded value for all 5 GCR bytes (in order to use just one single decoding table). Luckily, the values in the decoding table need not be unique, as in the same value may appear in multiple slots.
E.g., a specific GCR byte value may appear for the first GCR byte but is impossible for the fifth, and vice versa. Those two specific GCR values are allowed to decode to the same raw value, however. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
*processing* |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Not sure where i've lost you. 8-bit GCR value goes into table, 6 bits come out, 1 out of 5 times, 4 bits come out. Repeat. =) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
fex: "The constraint is that an encoded GCR byte must map to exactly one decoded value for all 5 GCR bytes" |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting Oswaldfex: "The constraint is that an encoded GCR byte must map to exactly one decoded value for all 5 GCR bytes" ldx $1c01 ; read GCR byte
lda decodetable,x; decode Given this one decoding look-up table for all GCR bytes, there is no way to magically map a GCR byte value to more than one decoded value, is there? =) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Not sure where i've lost you. 8-bit GCR value goes into table, 6 bits come out, 1 out of 5 times, 4 bits come out. Repeat. =)
How can 6 bits come out if there are only 20 different values in that table? |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting WVLHow can 6 bits come out if there are only 20 different values in that table? Do not confuse the heat map with the actual decoding table, which i haven't posted. "The byte values here are just a bitfield to show which of the 5 GCR bytes may take on the index value."
I merely described a recipe of how to generate the mapping. As there is a lot more than one valid solution, i refrained from picking any specific decoding table to show here. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Not a new trick, but a lesson i learned:
It's a good idea to skip any SYNC happening to roll by just when going to wait for a SYNC, like so
skipsync bit $1c00
bpl skipsync
waitsync [...]; SYNC time-out check
bit $1c00
bmi waitsyncThe reason is that custom loaders usually do quite a few things between the SYNC signal and the first data bytes rolling in. As the SYNC signal on standard-format disks is much longer (5 times) than the time between adjacent data bytes coming in from disk (about 26 to 32 cycles depending on track zone/density), this extra time is best not left unused in highly optimised loaders.
Now, when not skipping a current SYNC before waiting and "jumping" right into the middle or even the end of a SYNC, it may happen that there is, in fact, not the time the code requires before data rolls in, and faulty data is read.
This problem is mitigated to some extent by checksumming, but the checksum is rather weak. Faulty data may slip through, resulting in creative errors some time after actual loading.
Chances for this to happen are somewhat higher in an IRQ-loading setup, right after trackstep, and when the motor is spinning up when starting to load a file. |
| Previous - 1 | ... | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 - Next |
