| |
Krill
Registered: Apr 2002
Posts: 2982 |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
load ,8,8 considered harmful!? |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting ChristopherJamload ,8,8 considered harmful!?
Nah, can be considered wholesome, but only if you have a rather wonky drive that would give you retries (transient read errors) and slowdowns (missed blocks) after stepping with the default settings. =)
Otherwise just an unnecessary throttle. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
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: 5095 |
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: 2982 |
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: 5095 |
*processing* |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
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: 5095 |
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: 2982 |
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: 903 |
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? |
| Previous - 1 | ... | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 - Next |
