| |
mankeli
Registered: Oct 2010
Posts: 146 |
Spindle and Sparkle demos not launching
Can someone explain why demos using Sparkle or Spindle loaders can't be run from 1541U by selecting the launch file and using "mount & run"?
You got to use "Run Disk" for the whole image. 99.9999% of the C64 demos can be launched with mount & run, and somehow this only seems affect those aforementioned loaders. |
|
... 60 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1791 |
Quote: Quoting KrillWell seems to me that generally you don't know which track you're on right after a reset/powercycle. =)
Can’t be too far from the one we were on before power cycling. ;p
Anyway, what I mean is that in the case of Sparkle (and Spindle too), the installer loads from track 18. Once the BAM is read after drive reset (via the above mentioned JSR $d00e in the M-E bootstrap code), I know I am still/back on track 18 and I can set the stepper bits accordingly.
The thing I found is that if anyone changes the step bits skipping the half track step, then the stepper motor may end up in an "invalid state", I guess mechanically. A subsequent normal step after that may not end up on the track you expect. I guess this is one of the reasons for the DOS implementation of "the dance".
This is what I've been using to fix that in my init code:; handle if we are positioned on a half track
lda $1c00
lsr
bcc wce_skp1
jsr head_in
wce_skp1:
; step in (higher track), then out (lower track) to settle head
; This is because some drive mechanisms will feel bad when going
; directly from step 10 -> step 00 (i.e track 18 -> reset routine)
jsr head_in
jsr head_out |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting tlrThe thing I found is that if anyone changes the step bits skipping the half track step, then the stepper motor may end up in an "invalid state", I guess mechanically. A subsequent normal step after that may not end up on the track you expect. I guess this is one of the reasons for the DOS implementation of "the dance". Precisely. :)
Here's a hypothetical but quite realistic scenario:
1. File is loaded from directory track T18.
2. Stepper bits are at %10.
3. Drive is reset.
4. Stepper bits are initialised to %00, head remains on T18. Invalid state.
5. File is run.
6. DOS init reads BAM without errors, stepper bits and head position unchanged.
7. Loader steps to another track.
8. Head does not land on the expected destination track. |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Quoting tlr; This is because some drive mechanisms will feel bad when going
; directly from step 10 -> step 00 (i.e track 18 -> reset routine)
What does “feel bad” mean? What happens to the drive mechanism when the DOS reset routine does a %10 -> %00 on track 18? |
| |
tlr
Registered: Sep 2003
Posts: 1791 |
Quote: Quoting tlr; This is because some drive mechanisms will feel bad when going
; directly from step 10 -> step 00 (i.e track 18 -> reset routine)
What does “feel bad” mean? What happens to the drive mechanism when the DOS reset routine does a %10 -> %00 on track 18?
feel bad = to be in an undefined state
See here: https://en.wikipedia.org/wiki/Stepper_motor#/media/File:Stepper..
e.g, if you are physically in state #1 and directly change the magnets to go to state #3 you might move partially, in the wrong direction, or not at all in some cases.
This will correct itself by stepping a few times, but then everything might end up one track off. This then needs to be detected by interpreting the track field in the sector header. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
Quote:e.g, if you are physically in state #1 and directly change the magnets to go to state #3 you might move partially, in the wrong direction, or not at all in some cases.
BTW - VICE (and i believe also 1541U) will always step "up" one half track in that situation, as this seems to be what the odd loader (i forgot the name of that demo) expects |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: feel bad = to be in an undefined state
See here: https://en.wikipedia.org/wiki/Stepper_motor#/media/File:Stepper..
e.g, if you are physically in state #1 and directly change the magnets to go to state #3 you might move partially, in the wrong direction, or not at all in some cases.
This will correct itself by stepping a few times, but then everything might end up one track off. This then needs to be detected by interpreting the track field in the sector header.
Looking at the normal 1541 DOS routines, I've been wondering how the stepping would handle disks with sector headers that have deliberately wrong track numbers.
Are there any real world examples of disks that used wrong track numbers for sectors? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
There are originals that do this. I remember something with directory on 18.5 (which the DOS can handle fine due to the +/- 0.5 stepping) |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Quoting tlrfeel bad = to be in an undefined state
See here: https://en.wikipedia.org/wiki/Stepper_motor#/media/File:Stepper..
e.g, if you are physically in state #1 and directly change the magnets to go to state #3 you might move partially, in the wrong direction, or not at all in some cases.
This will correct itself by stepping a few times, but then everything might end up one track off. This then needs to be detected by interpreting the track field in the sector header.
Thanks! Since I already added the DOS read BAM call to resolve the drive reset/powercycle/DMA load problem it also makes sense to implement a stepper bit fix. |
| |
Quiss
Registered: Nov 2016
Posts: 43 |
Quoting Krill
Here's a hypothetical but quite realistic scenario:
1. File is loaded from directory track T18.
2. Stepper bits are at %10.
I don't see anything in the ROM that would touch the lower two bits of $1c00 as long as the head is already reading from the track we need. Thus, the stepper bits can still be %00 even after loading the file, right?
Thus, a more simple scenario would be:
1. Drive is turned on, head happens to be near track 18. During powerup, $1c00 is $ff, but then the motor gets turned off (ROM init code at $f259). This cuts power to the coils, the head coasts to track 18.
2. User does load "*", 8. Drive re-energizes the coils by putting $f4 into $1c00 (ROM code at $f982). This doesn't do anything, since the activated coil is opposite to the motor position. Head is still on track 18. File loads. (Even though the coils are in an invalid state.)
3. File is executed, loader initializes and tries to step somewhere, but ends up on the wrong track.
Just saw this happen in The Demo Coder, albeit in an emulator. (Thanks to Trident for helping me debug!) |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting Quissa more simple scenario would be Indeed, bottom line being that the stepper bits can be in an invalid state even after having DOS-loaded a file living on the directory track.
Quoting QuissDuring powerup, $1c00 is $ff, but then the motor gets turned off (ROM init code at $f259). This cuts power to the coils, the head coasts to track 18. Note that the ROM init code does not only turn off the motors, but also sets the stepper bits to %00.F25E: 29 F0 AND #$F0
F260: 8D 00 1C STA $1C00 ; port B, control port This does not change the overall scenario, only minor details of it.
Current emulators usually don't implement head inertia when moving, thus any "coasting" is not emulated.
The head may move by a half-track on start-up (or later) even in an emulator because of that ROM init code resetting the stepper bits to %00, the stepping being performed whenever the motors are turned on (during init or after).
By the same token, the head may not move, but the stepper bits/coils be reset from %10 to %00 and become invalid.
Last time i checked, only the venerable CCS64 passed this test, but Denise is moving fast! =) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
