| |
Krill
Registered: Apr 2002
Posts: 2844 |
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....
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
*processing* |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
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: 5017 |
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: 2844 |
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: 2844 |
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: 2844 |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting Krill
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 waitsyncQuote:
Good point! Haven't really thought about that, but might explain a few problems I've encountered during the years. :) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting tlrHaven't really thought about that Me neither, until there were some weird transient errors during testing. This patch is one of the things i must backport to the IRQ loader. =) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Quoting KrillNot 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
The problems described sound very wellknown to me, and that is finally a good explanation why those effects happen. On the other hand, this might speed up spinup time and such in future. My first thoughts when reading this was measuring the time between two syncs, and one step further measuring the rpm and adapting a few things if too far out of range. |
| Previous - 1 | ... | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 - Next |
