"Batman rises" needs EMULATE_MECHANICS = false
dirkwhoffmann opened this issue · comments
Batman rises stops with a LOAD ERROR in vAmiga if EMULATE_MECHANICS is enabled. If this option is disabled, the demo runs just fine.
When EMULATE_MECHANICS is enabled, vAmiga applies more stringent timing: It emulates the acceleration and deceleration phases of the drive motor as well as the delay caused by the movement of the drive head from one cylinder to the next.
TODO: Find delay parameters that
- are compatible with Batman rises
- are compatible with T2 -(see #411)
- match what we see in Amiga TestKit
The current value of OPT_STEP_DELAY (8ms) seems high. From the HRM Disk Timing section:
The drives used for the Amiga are guaranteed to get to the next track within 3 milliseconds. [...] When reversing directions, a minimum of 18 milliseconds delay is required from the last step pulse. Settle time for Amiga drives is specified at 15 milliseconds.
The demo waits waits 68 raster lines (~4.4ms) after stepping ($7fea2) which should be fine.
Interesting. I've run some experiments with different step delays:
< 5000 usec: Batman OK, T2 FAILS
= 5000 usec: Batman OK, T2 FAILS
= 5100 usec: Batman OK, T2 FAILS
= 5150 usec: Batman OK, T2 OK
= 5200 usec: Batman OK, T2 OK
= 5250 usec: Batman FAILS, T2 OK
= 5300 usec: Batman OK, T2 OK
= 5400 usec: Batman FAILS, T2 OK
> 5400 usec: Batman FAILS, T2 OK
The results should be taken with a grain of salt, because there was some indeterminism involved. However, I think it's safe to conclude the following from the experiments:
- Batman requires small delays
- T2 requires large delays
It's strange that T2 requires a delay which is higher as the one guaranteed by the spec. Hence, there might be other parameters involved that are not yet taken care of. Sidenote: I've never tried T2 with an original drive, because all my Amiga are equipped with Goteks. With the Gotek, it works fine.
Should I try the T2 with my Amiga 1000 (aka Battleship Galatica) original drive ? It has only 512Kb memory in total.
Haven't checked T2, but maybe it's issue is not emulating the direction change delay?
However, I played around with it a bit, and found that it also works if I add a 10ms delay. Added some debug statements, and I think I've found the issue. When the step delay is active you return a random byte. Meanwhile the dsksync logic is still running, so with a fairly high probability it will see 0x4489 during the waiting period and start reading garbage.
As for why this isn't an issue more often, I think that's because the Batman Rises trackloader isn't that great (still looking at it, but found at least one minor bug). Most trackloaders will retry on error, but I don't think this one does that.
Try to change the code to return e.g. (u8)(rand() & 0x55), and it should get past the initial loading screen at least.
so with a fairly high probability it will see 0x4489 during the waiting period
Yes, that's it! After masking the random bytes, Batman rises runs just fine to the end without producing any load error.
The T2 issue needs to be analyzed separately. More precisely: Why does the current vAmiga implementation require a head step delay which contradicts the spec.
Haven't checked T2, but maybe it's issue is not emulating the direction change delay?
Maybe. I need to check if a critical direction change takes place.
Should I try the T2 with my Amiga 1000
@mithrendal It would be interesting to see if the disk works with the A1000. However, it might be difficult to create the disk. Because we're talking about timing delays between two adjacent tracks, the tracks on the real disk need to match the track alignment of the ADF. More precisely: Byte 0 of all tracks would have to start at the same angle. Even more precisely: When specified in radial coordinates, if byte 0 on track n has the physical location (r_n,phi_n) and byte 0 on track m has the physical location (r_m,phi_m), then phi_n = phi_m. I am unsure if there is a tool capable of creating a disk with this property.
Some more findings:
When booting Kickstart 1.3, the drive head moves quickly between track 0 and track 1 a couple of times. The time between these steps is about 4 msec which violates the spec (the minimum delay should be 18 msec). After that, the drive performs the usual polling clicks from time to time to detect disk changes.
Df0:667 readyToStepDown: REVERSING DIRECTION TOO QUICKLY (4330).
Df0:695 Stepping down to cylinder 0
Df0:649 readyToStepUp: REVERSING DIRECTION TOO QUICKLY (4341).
Df0:712 Stepping up to cylinder 1
Df0:667 readyToStepDown: REVERSING DIRECTION TOO QUICKLY (4170).
Df0:695 Stepping down to cylinder 0
Df0:649 readyToStepUp: REVERSING DIRECTION TOO QUICKLY (4465).
Df0:712 Stepping up to cylinder 1
Df0:667 readyToStepDown: REVERSING DIRECTION TOO QUICKLY (4168).
Df0:695 Stepping down to cylinder 0
Df0:649 readyToStepUp: REVERSING DIRECTION TOO QUICKLY (4341).
Df0:712 Stepping up to cylinder 1
Df0:667 readyToStepDown: REVERSING DIRECTION TOO QUICKLY (4171).
Df0:695 Stepping down to cylinder 0
Df0:649 readyToStepUp: REVERSING DIRECTION TOO QUICKLY (4467).
Df0:712 Stepping up to cylinder 1
Df0:695 Stepping down to cylinder 0
Df0:649 readyToStepUp: REVERSING DIRECTION TOO QUICKLY (4374).
Df0:712 Stepping up to cylinder 1
Df0:695 Stepping down to cylinder 0
Df0:712 Stepping up to cylinder 1
Df0:695 Stepping down to cylinder 0
Df0:712 Stepping up to cylinder 1
Df0:695 Stepping down to cylinder 0
Df0:712 Stepping up to cylinder 1
What I don't know is how to react to a spec violation. If a change reversal occurs too quickly, does the drive ignore the skip command, does it read garbage for a longer period of time, or does it continue to read from the old track for some time?