| |
Burglar
Registered: Dec 2004
Posts: 1088 |
X2016 Competitions: Your Input Wanted!
The 28th of october is still far away but getting closer and closer. The organizers have been getting busy and are now well underway to get everything sorted out for another smashing X!
Since entry delivery and running the compos at X14 went quite smooth and voting is now done in realtime, we believe we may have room for 1 or 2 more (small/fun) c64 competitions. Like a PETSCII compo or a 4k compo, or maybe you guys have an idea?
Or perhaps you think the straightforward demo/music/gfx compos are enough.
Let us know :) |
|
... 214 posts hidden. Click here to view all posts....
|
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting sociI've just did a small research on the limited set of popular loaders I'm aware of.
...
Thanks for this breakdown! I wonder, when you state that a loader does checksums, are you referring to the serial transfer or just the process of reading a block from disk? Spindle does the checksumming on the C64 side, which captures both kinds of errors. |
| |
enthusi
Registered: May 2004
Posts: 677 |
just curious, is the serial transfer ever likely to fail? That being said, a load of tap was shown live from tape with badass monitors degaussing left and right... |
| |
soci
Registered: Sep 2003
Posts: 479 |
Only the GCR bitstream was randomly corrupted in the test. (~1 in 8000)
I assumed no-one would check the integrity between the drive and the c64, so I didn't even tried that.
I was wrong ;) This stuff is pretty advanced. |
| |
soci
Registered: Sep 2003
Posts: 479 |
The "usual" failure mode for serial transfers of fastloaders is when there's not enough safety margin for asynchronous transfers.
If the oscillators are a bit more detuned or the serial cable is longer sampling may happen around the transition and not when the signals are stable.
I think there's also some timing difference with the C128DCR's 1571 which makes this worse. At least I remember I had to adjust the timing for that in the past when I still determined it by trial-and-error. But cycle counting gives more reliable results. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
This just about calls for a new topic, but what sort of errors occur in the GCR stream in practice when using different drives?
Is it purely extra/missing zeros generated by gaps between polarity changes being too long/short, hence also throwing out the byte boundaries for the rest of the block? And how often does this tend to occur? |
| |
Grue
Registered: Dec 2001
Posts: 161 |
Quote: Quoting sociI've just did a small research on the limited set of popular loaders I'm aware of.
...
Thanks for this breakdown! I wonder, when you state that a loader does checksums, are you referring to the serial transfer or just the process of reading a block from disk? Spindle does the checksumming on the C64 side, which captures both kinds of errors.
Might be, but it does work with my 1541-II and 1541ultimate, but fails on Chameleon if using its external iec. |
| |
nucleus
Registered: Feb 2002
Posts: 16 |
+1 256 bytes
+1 petscii
+1 wild
see you at x2016 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:I think there's also some timing difference with the C128DCR's 1571 which makes this worse.
yup. guess what loader has problems with it :) |
| |
soci
Registered: Sep 2003
Posts: 479 |
Did a spot check on the Spindle 2.1 serial transfer timing, and this part seems to be the tightest (~1.4us).
Tracks were aligned so that STY $DD00 must finish before the end of BIT $1800 to get recognized. In the reverse direction STA $1800 needs to be finished 1us earlier(!) than the end of LDX $DD00 to get recognized. So that ~1.4us is even less...
But this is simulation only. Therefore I can't say if it's bad or not. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Good thing the serial transfer is checksummed then. =)
Actually, I think STY $dd00 must finish one cycle before the end of BIT $1800 in order to be picked up, so this would put us back at 1.4us. Do you have experimental data that indicates otherwise?
I could try to slow down the serial transfer routine, just to see how that affects the benchmarks. If it doesn't, perhaps it's better to be safe than sorry.
Related: When I was working on Shards of Fancy, and thus on a pre-1.0 version of Spindle, there was one point where everything would work perfectly on the 1541U and in Vice, but randomly fail on a real drive. Sometimes I would get lockups or random crashes roughly halfway through the demo, and of course I ran into this issue less than a week before the party was due.
It took a while to track down, but in hindsight it was obvious: If the sender changes two signals (say, Data and Clock) at the same time, they might not change simultaneously from the point of view of the recipient. In particular, the IEC bus works with pull-up resistors, such that a transition from high to low is going to be significantly quicker than a transition from low to high. So if the C64 changes 10 into 01 with a single store instruction, and the 1541 reads the corresponding register at the wrong time, it's going to read 11 (corresponding to low-low on the bus).
The problem is that this difference in timing isn't modeled by Vice, and on a 1541U with a minimal IEC-cable the signals appear to change quickly enough that the probability of this happening is negligible. So this was a case where the emulation was "too good", causing a very real bug to be hidden from developers. |
| Previous - 1 | ... | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 - Next |
