| |
Burglar
Registered: Dec 2004
Posts: 1089 |
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....
|
| |
nucleus
Registered: Feb 2002
Posts: 16 |
+1 256 bytes
+1 petscii
+1 wild
see you at x2016 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
another problem is that the clock speed of emulation (and 1541U/chameleon) is too perfect - it can vary quite a bit on real drives (and C64s!) - i'd always make the timing so one cycle more or less is OK, else its too much on the edge and could randomly fail on real machines. |
| |
soci
Registered: Sep 2003
Posts: 479 |
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?
Maybe next time when I have access to my gear I could measure this. But if STY $DD00 needs finishing one cycle earlier then STA $1800 might need this as well. And then it's zero sum possibly. But it's CIA vs. VIA so there could be some difference.
If the sender changes two signals (say, Data and Clock) at the same time
Yes, I've seen this too ;) As the X1541/PC64 PCLink (connected to IEC/Userport) in IDEDOS needs to be as fast as possible the C64 only reads the port once for handshake and data.
The timing problem was solved on the PC side. It updates the data and handshake in two writes even if both are controlled by the same register. |
| |
Hein
Registered: Apr 2004
Posts: 946 |
So, only if explicitly asked to run on a real 1541, because of the awesome flip disk screen, with the risk of crashing and delaying the compo, else it's 1541U? Not that I care, I'm working on a one filer. Looking forward to the 64+ PETSCII entries. :) |
| |
lft
Registered: Jul 2007
Posts: 369 |
I tried adding one safety cycle per bit pair in the transfer routine. 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? |
| |
Cresh
Registered: Jan 2004
Posts: 354 |
Guys, this discussion is extremely interesting, but is not about X16 compos. |
| |
lft
Registered: Jul 2007
Posts: 369 |
We can has loadercompo?
Sorry for hi-jacking the thread. Here's a new one: Fastloaders & serial transfer timing |
| Previous - 1 | ... | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 - Next |
