| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Release id #217506 : Sparkle 2.1
Just saw the new range of rotation speeds the new sparkle tolerates and pondered a bit about it. It might work out well on Vice, but does it really make sense to support such a wide range on real hardware? In fact as zeroes are read when no flux inversion happens withion a given time frame, quite a few more zeroes will be read if rotation speed goes way under spec? The time frame is given by the speedzone. If i am wrong, feel free to correct me. I understand that any mean to cease out read errors is welcome, as the sector checksum is the weak point. |
|
... 1 post hidden. Click here to view all posts....
|
| |
Sparta
Registered: Feb 2017
Posts: 49 |
I actually tested this on a real drive. The lowest rpm I could set on one of my old belt-driven 1541s was 277 and Sparkle had no problem reading the disk at this speed so I think VICE is correct.
I guess it is because there cannot be more than two 0s in the GCR encoded data. In zone 3, every bit is read in a 3.25-microsecond time frame (if I understand it correctly), so the 3rd bit is read 0 if there is no flux inversion within 6.5-9.75 microsenconds after the last inversion. But this would mean a 33% slowdown (200 rpm). So technically, loaders could handle much lower speeds than Sparkle's 269 rpm.
I may be overestimating the relevance of this. All in all, it is just another measure to improve reliability. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting SpartaI may be overestimating the relevance of this. All in all, it is just another measure to improve reliability. Assuming that tolerance for a large range of average rotational speeds is a proxy for tolerance of extreme wobble, drives currently should be no worse than 130 cycles / 124 cycles * 300 rpm = 314.5 rpm at the high end.
Quoting Spartatolerance of at least 269-314 rpm This would mean that tolerance for up to 314 rpm may probably be just enough, so all good. =)
But...
Quoting SpartaSince the native interleave of this zone is 4 but fetching and transferring a block requires only a little bit more than 3 sectors passing under the RW head, there is plenty of time left to finish checksum verification outside the loop without a performance penalty. This may be true for 100% CPU available to the loader, but how does it look for most real-world scenarios with a lot less?
Surely some performance penalty should be seen when going down the CPU percentage figures? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
Now make better test programs for measuring flutter already, so we can model this better in VICE :) |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Quoting KrillThis may be true for 100% CPU available to the loader, but how does it look for most real-world scenarios with a lot less?
It is true for real-word scenarios as well. I actually made a new build of Memento Mori with Sparkle 2.1 (including the last disk that streams data while scrolling the bitmaps with the side border open) just to test this.
Quoting KrillSurely some performance penalty should be seen when going down the CPU percentage figures?
Sparkle 2.1 is as fast as Sparkle 1.5 (previously the fastest Sparkle) on real hardware tests across all tested CPU availability figures.
Half of the checksum calculation is done in the GCR loop in zone 3, and the other half takes a mere 851 cycles outside the loop and this is constant and independent of C64 CPU load. It is also pretty negligible compared to the time required for transferring and decrunching a sector, both of which are inversely proportional to C64 CPU availability, making this even less relevant at higher CPU loads. Also, I am gaining much more with the re-introduction of the second block buffer in the drive. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
That is also what i would expect, if CPU load is high, the floppy is even more idle and missing more sectors anyway, so doing the checksum outside the loop should not slow down things until getting close to the next interleave?
Edit: It also gives the advantage to get the tables smaller with a few extra opcodes spent. The 7th Table then also fits into zp. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting Bitbreakerso doing the checksum outside the loop should not slow down things until getting close to the next interleave? That's what i mean, yes. :)
With 100% CPU, transfer of a block is done somewhere before the next file block rolls by (4 sectors after the current block).
With less than 100% CPU, block transfer takes longer, and at some point the next file block is just missed.
At the same magic CPU percentage, i'd expect the full on-the-fly version not to miss the next file block, as there is ever so slightly more time to transfer the block.
But yeah, the overall impact across all CPU percentages should not matter much, and is probably negligible in most cases.
Anyways, this sbc $1c01 //AAAAABBB V=0 118/-11 126/-13 136/-13 144/-15 c5-c7 is a very nice trick to clear the V flag! :) Will attempt to use it for my purposes. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
The sbc trick should also give new chances to fit tables better, as they are mirrored? |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting BitbreakerThe sbc trick should also give new chances to fit tables better, as they are mirrored? Maybe, although there was the EOR "trick" before already to have backward-tables. lax VIA2_PRA ; 40 46 50 52 ; 00000111 ; 0 - %11: [26..51], %10: [28..55], %01: [30..59], %00: [32..63]
eor #%11111000 ; 42
sax .lobyte(decode1 + 1) ; 45 ; -----111
alr #%11111000 ; 47 ; -00000--
tay ; 49 |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Quoting BitbreakerIt also gives the advantage to get the tables smaller with a few extra opcodes spent. The 7th Table then also fits into zp. Exactly. It allowed me to free a whole block by eliminating the huge 8th table and simplify the saver code which otherwise would have overwritten the 8th table with GCR-encoded data. Then the table needed to be restored once saving was complete.
Quoting KrillAnyways, this sbc $1c01 //AAAAABBB V=0 118/-11 126/-13 136/-13 144/-15 c5-c7 is a very nice trick to clear the V flag! :) Thanks. :) I wish LAX #$07 was a viable option. It would have saved another cycle in the loop.
Quoting BitbreakerThe sbc trick should also give new chances to fit tables better, as they are mirrored? In this use case it doesn't. The first table spreads out either way. But yeah, maybe in other situations it may help, similar to the EOR trick. |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Quoting SpartaQuoting BitbreakerThe sbc trick should also give new chances to fit tables better, as they are mirrored? In this use case it doesn't. The first table spreads out either way. But yeah, maybe in other situations it may help, similar to the EOR trick.
I take this last one back. The sbc trick did help find a tight fit of the first table among the others. I somehow confused it with the 4th table when I wrote my original post and looked at my table layout. |
| Previous - 1 | 2 - Next |
