| | 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: 504 |
Quote: When we had this issue with n0sd0s it seemed to be limited to 1571 drives, just to note.
Means, a drive detection is enough and manipulating the code in case to slow things down, just as one does with NTSC. |
| | doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting BitbreakerMeans, a drive detection is enough and manipulating the code in case to slow things down, just as one does with NTSC. Alternatively:lda #%00100000
sta $1801
;IRQ transfer loop..
lda #%00000000
sta $1801 |
| | Bitbreaker
Registered: Oct 2002
Posts: 504 |
In fact 2 MHz mode can be switched on all over, except for the sector reading. Seems to speed up things by ~4% then.
That said, who is going to try it out on his 1571? .d64 is available for testing :-) |
| | doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting BitbreakerIn fact 2 MHz mode can be switched on all over, except for the sector reading. Seems to speed up things by ~4% then. As long as the track stepping is VIA timed I suppose. Of course in Lft's case sector reading and IEC transmission is basically _all_ there is.
Quoting BitbreakerThat said, who is going to try it out on his 1571? .d64 is available for testing :-) I'll give it a quick whirl for you on my C128D (non-CR) which has survived $1801 pokes in the past. It doesn't suffer from sensitive IEC timing though. |
| | Flavioweb
Registered: Nov 2011
Posts: 463 |
All this theory could mean that if a real hw drive is connected through another drive (eg running on drive 9 with 8 connected), we can have timing troubles? |
| | doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting FlaviowebAll this theory could mean that if a real hw drive is connected through another drive (eg running on drive 9 with 8 connected), we can have timing troubles? It will certainly _affect_ the timing. Whether it's a help or a hindrance is difficult to guess at without getting out the oscilloscope. |
| | chatGPZ
Registered: Dec 2001
Posts: 11359 |
yes, connecting more drives generates more trouble :) some guy reported the weirdest things for chameleon...and then it turned out he had 4 drives connected. doh! |
| | Bitbreaker
Registered: Oct 2002
Posts: 504 |
A lot of tests and pain was gained on tests on real hardware and it turned out that serial is not the biggest problem to cope with. A loader should also sustain some variation in rotation speed. Also in very rare cases it is not enough to rely on the checksum, neither of the header nor the payload. When spinning up and starting directly to load, it can happen that one still passes all tests and load chunk. Been there, seen that. Same goes if you ommit a check on right track during header sanity checks. It might happen that for a short while you are reading from a neighbour track after stepping, with valid checksums of course. All problems that do not occur on emulated hardware but might let you fail after a bunch of successful runs over a whole disk.
Another though: if you populate the gaps in specific gcr_decode tables with other variables/data to make optimum use of your floppy ram, there is another potential risk:
When reading chunk while spinning up/stepping one could also read invalid gcr codes and make looukups in the gaps. If we have zeroes there, it is an easier to get a false positive checksum. As we read an arbitrary amount of zeroes, we will match with a zero checksum as well, though we have just read nothing. But i have no yet checked, thought of what the floppy is reading if there's no change in polarization, maybe 00000 all over? |
| | doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting BitbreakerA lot of tests and pain was gained on tests on real hardware and it turned out that serial is not the biggest problem to cope with. A loader should also sustain some variation in rotation speed. Also in very rare cases it is not enough to rely on the checksum, neither of the header nor the payload, ... It seems to me that what is really called for is a stronger checksum. More carefully tuned drivecode is going to keep failing regardless, during disk swaps and mechanical problems if nothing else.
I don't know quite what though. A one's complement sum would be a start though, with the sector header and data block sums linked in.
I suppose anything fancier is tricky on a single-accumulator machine though but fletcher-16 is doable, and CRC-8 is only 6 extra cycles per byte if you can afford the 256-byte table. Probably an 8-bit sum in parallel with the standard parity byte would be quite sufficient though.
As has been noted a clearer error model to work with would certainly also help in evaluating the candidates.
Side-note: Things get rather interesting when combined with Kabuto's arithmetic coding, which sort-of makes errors cascade by default. Combined with a header swizzled into the middle of the payload I figure an 8-bit one's complement sum is farily decent. Of course having been to lazy to bothered doing the analysis and it is quite possible that the two arithmetic codes interact badly ;) |
| | Bitbreaker
Registered: Oct 2002
Posts: 504 |
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
|
| Previous - 1 | 2 | 3 - Next | |
