| |
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....
|
| |
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: 11387 |
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! =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
Micro64 also emulates head-movement inertia (including bero typical overengineering) iirc |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting mankeliThis happens on U64 too. (Ultimate 64 Elite V1.43 - 3.11) Aerial Core for example doesn't work with mount & run, it needs run disk.
Aerial Core was the very first demo I attempted to run after I received my 1541u-II+ - I was a bit disturbed when it didn't work haha |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Quoting Quiss
Just saw this happen in The Demo Coder, albeit in an emulator. (Thanks to Trident for helping me debug!)
Thanks for pointing me to this and doing all the debug work! Meanwhile i added a cheap fix for Bitfire (just use the latest commit from github), by simply stepping to track 17, where i bogus-read a sector by job code before loading the dir-sector from track 18 and start the loader. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Now, test the popular loaders the hard way.
During loading, push the r/w head of an open drive off-track manually, see if the loader can cope with that. =D
(I actually did that when adding/debugging the track correction mechanics a while ago.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
maybe prepare a disk with D64 Shredder V0.1 ? :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
