| |
Krill
Registered: Apr 2002
Posts: 2940 |
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: 2940 |
Quoting Copyfaultdoes an SHX used on the drive's cpu reliably have this "&h+1"-masking going on? It has no RDY-line, so should be the case... Afaik, it's reliable on all 6502 (and variants with illegals) systems without DMA interference. But yes, what Groepaz said. :)
And of course i optimised only as much as needed. =) (And Y is the buffer number and thus not a constant.) |
| |
Copyfault
Registered: Dec 2001
Posts: 468 |
Yes, y is the buffer no. (and thus not const), you wrote that in your post... but the SHX was too tempting so I dared to share the thought;) |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
transfering while stepping track, awesome idea :) remembers me when I tried to "stream" load vector anim, and it always stopped for track stepping haha. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting Oswaldtransfering while stepping track, awesome idea :) remembers me when I tried to "stream" load vector anim, and it always stopped for track stepping haha. I think stepping itself is not to blame for the hiccup. =)
The normal* stepping duration in Transwarp is $90 (144) bycles, that's a fifth (18%) of a revolution, or 4 sectors. So for a regular interleave 4 loader, that means just one missed block. Plus they would use shorter stepping times, usually around $30-$40 bycles. (The $90 setting was determined experimentally, it was the safest setting across all test drives.)
However, the loader you used probably did not load blocks out of order, and then the mean waiting time for a block after trackstep is half a revolution, a tenth of a second, and the worst case double that time.
* With secondary addresses >= 2, the track step times for either or both half-track steps can be increased for drives with particularly long settle times or slow steppers, in order to counter stepping-related loading problems.
Bits 3..1 increase the overall stepping time: +2 = $a0, +4 = $b0, +6 = $c0, ..., +14 = $0100 bycles.
Bits 7..4 increase the time between first and second half-track step: +16, +32 etc. would shift the relation further towards the overall stepping time.
So loading a Transwarp file with ,8,255 would be pretty slow. =)
Having the secondary address take on more meanings than just loading to BASIC start or saved address, i was slightly dismayed to see BiGFoot use ,8,8 out of an old learned habit. =D |
| |
Count Zero
Registered: Jan 2003
Posts: 1882 |
https://codebase64.org/feed.php
Tap tap tap ... oh, thats the sound of my drive sometimes recently - not the frequency of your codebase submissions! :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1403 |
load ,8,8 considered harmful!? |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
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: 2940 |
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: 5076 |
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: 2940 |
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. |
| Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 18 - Next |
