| | lft
Registered: Jul 2007
Posts: 369 |
Fastloaders & serial transfer timing
This is a continuation of an off-topic discussion in X2016 Competitions: Your Input Wanted!.
There was some concern about serial transfer routines that might fail due to small margins.
I tried adding one safety cycle per bit pair in the transfer routine of Spindle. This caused an average slowdown of 1.5% for my benchmark scenario.
Crosses are bitfire 0.3, just to get some perspective.
Hollow circles are the latest unreleased Spindle with the original (fast) transfer routine.
Green circles are the latest unreleased Spindle with the new (possibly more robust) transfer routine.
I'm thinking that perhaps the robust version should be default, and the fast version available as an option. But on the other hand, nobody has reported any actual issues with the fast code on real drives, so this decision would be based on fear, more or less. Spindle users, what do you say? |
|
... 19 posts hidden. Click here to view all posts....
|
| | Bitbreaker
Registered: Oct 2002
Posts: 508 |
Just let such an error happen again on a real drive (thanks THCM), when i turn on the motor and start reading without writing.
Some parts of the broken sector is the same as from the orig, but the last three bytes would be the checksum of the orig sector + the two zero bytes. Funny enough the checksum of the broken sector would be $23, so i would need to transfer one byte further to see if that is true. Actually i should run into the next sync mark there?
If one waits 0,5s until the motor is at a stable rotation speed, those problems vanish.
broken
!byte $d2,$14,$18,$15,$6b,$15,$70,$70,$00,$06,$d0,$d1,$90,$be,$0c,$75
!byte $1f,$00,$fe,$fe,$85,$d5,$70,$75,$b3,$e2,$c7,$b0,$cb,$53,$fd,$07
!byte $cd,$ba,$e9,$e1,$bd,$e5,$fd,$f5,$57,$ad,$01,$c0,$bf,$1b,$0d,$f8
!byte $f0,$df,$6d,$f4,$3e,$7f,$6a,$05,$66,$2a,$dc,$ad,$33,$ad,$e0,$1d
!byte $d0,$27,$29,$25,$22,$37,$e0,$2b,$f0,$53,$00,$50,$33,$de,$2f,$f1
!byte $e6,$46,$02,$c0,$0a,$76,$28,$25,$1b,$37,$41,$95,$0a,$36,$4c,$77
!byte $17,$4c,$7b,$3f,$98,$10,$17,$a0,$98,$00,$9d,$68,$1a,$98,$9d,$40
!byte $aa,$bd,$da,$0e,$22,$9d,$4c,$1a,$0a,$a0,$00,$85,$44,$17,$8d,$b1
!byte $77,$60,$8d,$55,$a0,$8d,$63,$c3,$93,$4c,$1e,$1b,$cc,$85,$ff,$bd
!byte $bb,$fc,$30,$09,$d9,$f2,$1b,$90,$05,$f0,$02,$49,$ff,$18,$69,$02
!byte $cd,$af,$15,$4a,$90,$0f,$b0,$10,$98,$85,$11,$30,$c9,$c9,$02,$90
!byte $02,$f0,$10,$bd,$6b,$1a,$65,$fe,$9d,$5e,$11,$bd,$6c,$a5,$ff,$4c
!byte $db,$19,$02,$e5,$98,$02,$1c,$0c,$8d,$7e,$18,$a8,$a2,$00,$35,$9d
!byte $43,$30,$2e,$8a,$a2,$1b,$9d,$3e,$1a,$ca,$10,$fa,$8d,$12,$d4,$8d
!byte $15,$6e,$fe,$8c,$94,$8e,$3a,$c3,$aa,$20,$9f,$17,$a2,$07,$a9,$05
!byte $9d,$82,$41,$a9,$01,$9d,$5d,$6d,$b2,$5f,$1a,$4c,$f4,$6b,$00,$00
orig
!byte $d2,$14,$18,$15,$1b,$15,$3e,$1e,$7e,$41,$46,$02,$07,$21,$6c,$e8
!byte $af,$b1,$e9,$1d,$7f,$52,$19,$1d,$af,$b1,$3b,$3e,$2c,$3d,$25,$c7
!byte $9a,$2a,$0c,$34,$e7,$68,$30,$35,$3d,$5c,$1d,$ce,$9a,$46,$a1,$70
!byte $76,$01,$02,$04,$05,$c9,$f4,$3e,$7f,$6a,$05,$56,$2a,$dc,$ad,$c3
!byte $ad,$e0,$1e,$22,$27,$29,$2c,$32,$37,$e0,$29,$3f,$53,$00,$58,$43
!byte $de,$2f,$f8,$a6,$46,$02,$c0,$20,$76,$28,$2c,$31,$37,$41,$95,$b0
!byte $36,$4c,$77,$17,$4c,$7b,$37,$d9,$10,$17,$a8,$a9,$00,$9d,$68,$1a
!byte $98,$9d,$4d,$1a,$bd,$da,$0e,$e2,$9d,$4c,$1a,$60,$a0,$00,$8c,$b4
!byte $17,$8d,$b0,$17,$60,$8d,$5c,$1a,$8d,$63,$c3,$93,$4c,$1e,$19,$bc
!byte $85,$ff,$bd,$9b,$fc,$30,$09,$d9,$f2,$1b,$90,$05,$f0,$02,$49,$ff
!byte $18,$69,$02,$ac,$af,$15,$4a,$90,$0f,$b0,$1d,$b9,$85,$11,$3d,$e8
!byte $c9,$02,$90,$02,$f0,$10,$bd,$6b,$1a,$65,$fe,$9d,$5e,$11,$bd,$6c
!byte $a5,$ff,$4c,$1b,$19,$02,$e5,$98,$02,$1c,$0c,$8d,$7e,$18,$a8,$a2
!byte $00,$35,$9d,$43,$30,$2e,$8a,$a2,$1b,$9d,$3e,$1a,$ca,$10,$fa,$8d
!byte $12,$d4,$8d,$15,$6e,$fe,$8c,$94,$8e,$3a,$c3,$aa,$20,$9f,$17,$a2
!byte $07,$a9,$05,$9d,$82,$41,$a9,$01,$9d,$5d,$6d,$b2,$5f,$1a,$4c,$f4
|
| | ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Intriguing. Are you able to obtain the 320 byte raw datastream from such an event? |
| | Bitbreaker
Registered: Oct 2002
Posts: 508 |
I'm afraid, not yet, but it seems like the gcr decode/read misses some bytes or at least reads some with wrong value. Added the possibility to receive the checksum at least, c64 currently running and i am waiting for another fail :-) |
| | chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:But i have no yet checked, thought of what the floppy is reading if there's no change in polarization, maybe 00000 all over?
it will randomly insert ones every 3 or 4 bits or so (the so called "weakbit" case) |
| | Bitbreaker
Registered: Oct 2002
Posts: 508 |
Okay. seems like also spindle is stumbling over that problem. Krill seems to be safe. My fair guess, it is due to the extra revolution for scanning that it does, and that there, the checksum is going over 4 bytes only, thus less error prone. After that process the drive is at a good speed most likely. Working on a solution for that, that is a bit more intelligent than just dumb waiting :-) Tests currently running... |
| | lft
Registered: Jul 2007
Posts: 369 |
Thanks for finding and reporting this! I'll fix it, but I'll try to come up with a better way than waiting for half a second on every track change. There may be just 34 of them, but that's still a whopping 17 seconds. |
| | Fungus
Registered: Sep 2002
Posts: 686 |
Someone with an old white or longboard 1541 with an older alps mechanism that only goes to track 38 should test stepping, if it's done too fast on the older drives it will lock up without fail.
I'd be interested in a table of safe stepping delays for these old ones myself. |
| | lft
Registered: Jul 2007
Posts: 369 |
I think those are separate issues. Minimum stepping delay is to prevent the stepper from missing a signal, and stopping half a track too early. This is about stopping at the right location, but then wobbling around due to inertia and reading parts of the sector from outside the track. Both are important to get right. |
| | Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
Randomly occurring read errors should come in 2 different flavours: those that desynchronise (i.e. the drive reading more/less bits than were written) and those that don't (and just report one or more adjacent/nearby bits incorrectly).
If there's just a single non-desyncing read error then the XOR checksum used is almost guaranteed to catch it, but anything that desynchronises has odds of 1/256 to incorrectly report the sector as valid. OTOH, rejecting invalid GCR codes (anything not in the table of commodore's 16 codes) will catch many of these errors, but I doubt that timing of fast loaders permits for that.
(And I'm wondering how many of each occur in practice.) |
| | Bitbreaker
Registered: Oct 2002
Posts: 508 |
Okay, i let my test scrub for 474 times over night and it didn't have a single corrupt file after loading (i checksum stuff on c64 side again) It seem like it is enough to successfully read 2 arbitrary sectors while spinning up. One was still too less and caused sporadic errors after like 100 full disk reads. So no plain waiting needed as it seems :-)
One could of course take care for illegal gcr-codes upon checksumming, at least in my case, but that would give a heavy speed penalty. However, illegal gcr codes also lead to further problems when sending, as we would then also lookup illegal values during the gcr2ser lookup, what could lead to a ATN hi for both bit pairs and corrupt data further.
As for spindle it is a bit difficult to build a checksum over whole files, as the depacker would possibly choke on broken blocks. But one could compare the packed results when checksumming over a depack buffer.
Else things are really getting rock solid, due to endless checking (stopping upon errors does not make sense on a loader for demos) it survives removing of the disk and reinserting or also slowing it down by squeezing the disk by hand to slow it down, or pushing it around in the drive while reading where it would skew to other tracks. This makes turn disk so easy, by just letting it read the new dir sector with a magic number until there's success. |
| Previous - 1 | 2 | 3 - Next | |
