| |
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. |
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 363 |
Can only suspect some timing issue... |
| |
TheRyk
Registered: Mar 2009
Posts: 2255 |
Is it 1541U or U II + issue or both?
Do you have the latest firmware upate?
Did you contact 1541U developers via bug report/ticket?
Normally they are eager to know about such issues and try to fix them via firmware update, at least that was the case with EasyFlash emulation. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
To simplify checking, could you link a few examples? and please indicate which 1541u/u2/+ ver/fw ver |
| |
Count Zero
Registered: Jan 2003
Posts: 1933 |
Naming it "1541U" sounds like my very early version which had a network port still? VERY incompatible :) Will try with that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
The 1541 needs a bit to reset. My guess would be that the boot program tries to communicate with the drive before the drive finished reset. |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: 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.
Wasn't it because the loader assumes the turbo code is in a particular place in drive memory (in one of the read buffers) after being loaded by the C64 and just calls that directly from the C64 side?
Normally, when the C64 loads something (like a turbo loader) from disk it would send some of that data back as the drive code to the drive, but I seem to remember some turbo loaders would not send the drive code from the C64 back to the drive, instead they would just assume the last loaded code was still in the drive buffer.
So if you're just mounting the disk image and running the prg by injection, not running the prg by loading it from the emulated disk drive, then the disk drive will not have the code in its internal buffer. So the C64 cannot call that code. |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
I just checked Martin's theory on No Bounds and it is not the case. It simply embeds the drivecode bootstrapping with M-E and short embedded code that reads the relevant sectors to drivemem. This is a pretty common method. |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: I just checked Martin's theory on No Bounds and it is not the case. It simply embeds the drivecode bootstrapping with M-E and short embedded code that reads the relevant sectors to drivemem. This is a pretty common method.
I remember now, it was the transwarp example that issues a M-E with the partial just loaded file in the read buffer: Transwarp V0.84 |
| |
mankeli
Registered: Oct 2010
Posts: 146 |
This seems to happen on later 1541 ultimates as well, iirc maybe even on the U64. I'll check later tonight. |
| |
mankeli
Registered: Oct 2010
Posts: 146 |
This 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. |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
why use the graphical interface, why not control the 1541u via tcp?
maybe check ugo 0.1 or Ucodenet (20200408). u can also do seamless disk swapping that way. |
| |
The Sarge
Registered: Aug 2002
Posts: 49 |
If you want, you can use Assembly64. It has an inbuilt "Flip Disk Player" that takes care of this for you. Multi-disk demos are started with this feature, and you don't even have to swap disks; it does this for you automatically.
The Flip Disk Player has been adjusted in most of the popular demos mitigating this problem with Ultimates right now.
https://assembly64.hackerswithstyle.se/assembly/download.html |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
maybe it is due to the drive not being 'I' initialized, which more or less happens when loading something?
EDIT: could be tested by loading the first file, then power cycling the drive before doing "RUN". |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
Quote:maybe it is due to the drive not being 'I' initialized, which more or less happens when loading something?
good one. i remember this case was tricky to fix in chameleon :) |
| |
mankeli
Registered: Oct 2010
Posts: 146 |
Yeah, this works:
LOAD"*",8,1
RUN
But this doesn't:
LOAD"*",8,1
*drive reset*
RUN
So it's indeed the loader depending on some state on the drive. Funny, since atleast Spindle works with the Action Replay fast loader. |
| |
LordCrass
Registered: Apr 2023
Posts: 8 |
It's because of the disk ID bytes at drive memory $12/$13. A shortcut is given to execute an FDC read job, which at some point compares on-disk ID to what is expected, but what is expected hasn't been set and is just $00, so error 29 Disk ID Mismatch occurs. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: It's because of the disk ID bytes at drive memory $12/$13. A shortcut is given to execute an FDC read job, which at some point compares on-disk ID to what is expected, but what is expected hasn't been set and is just $00, so error 29 Disk ID Mismatch occurs.
Interesting! So how does this work on regular load? It still uses FDC read jobs so who sets up $12/$13?
There is the BAM flag at $1c which indicates we are not initialized so I guess that is involved somehow? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Interesting! So how does this work on regular load? It still uses FDC read jobs so who sets up $12/$13?
There is the BAM flag at $1c which indicates we are not initialized so I guess that is involved somehow?
To answer my own question: The id always gets set up when doing a SEEK ($b0).
A regular load seems to always do initialize in the beginning of the directory search, but for loaders that do not use this a SEEK is sufficient.
That job code handling is done by the $45 check at $f3ec. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting Martin PiperI remember now, it was the transwarp example that issues a M-E with the partial just loaded file in the read buffer: Transwarp V0.84 Yes, that's part of the 2-blocks bootstrap fastload strapped in front to speed up booting the actual loader.
Was 1-block in early dev versions, but that turned out to be too slow for my purposes. =)
(You can always fall back to loading Transwarp itself via ,8+RUN not ,8,1 when autorun won't work for some reason.)
As for the problems described here, i like the concept of a multi-loader coming in a self-contained package in C-64 memory, that would function just fine when run immediately after drive reset, new disk etc. :)
Then again, no particular love for non-stock aftermarket hardware. |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
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.
Areal Core has its own issues, it does not load on a stock c64+1541 without cartridge due to the dirart and not having the boot prg as first file.
trying to load the prg will give file not found, unless you modify the filename with ? and * |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting Burglarit does not load on a stock c64+1541 without cartridge due to the dirart and not having the boot prg as first file.
trying to load the prg will give file not found, unless you modify the filename with ? and * Time to add that "disk image linting" to cc1541 we talked about recently. =) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Quoting Burglarit does not load on a stock c64+1541 without cartridge due to the dirart and not having the boot prg as first file.
trying to load the prg will give file not found, unless you modify the filename with ? and * Time to add that "disk image linting" to cc1541 we talked about recently. =)
Great idea! |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: Quoting Martin PiperI remember now, it was the transwarp example that issues a M-E with the partial just loaded file in the read buffer: Transwarp V0.84 Yes, that's part of the 2-blocks bootstrap fastload strapped in front to speed up booting the actual loader.
Was 1-block in early dev versions, but that turned out to be too slow for my purposes. =)
(You can always fall back to loading Transwarp itself via ,8+RUN not ,8,1 when autorun won't work for some reason.)
As for the problems described here, i like the concept of a multi-loader coming in a self-contained package in C-64 memory, that would function just fine when run immediately after drive reset, new disk etc. :)
Then again, no particular love for non-stock aftermarket hardware.
I really liked the way that bootstrap code started executing on the C64 then switched over to the fastload. |
| |
mankeli
Registered: Oct 2010
Posts: 146 |
Quote: 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.
Areal Core has its own issues, it does not load on a stock c64+1541 without cartridge due to the dirart and not having the boot prg as first file.
trying to load the prg will give file not found, unless you modify the filename with ? and *
Oh, thanks for reporting!
Getting the dirart to even work was a huge pain ^^
But yeah atleast the problem got narrowed down to Basic LOAD leaving some state to 1541 which Spindle then depends on. As an another example Skybox doesn't work with mount and run either, and it probably has dirart as DEL Files. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting mankeliBut yeah atleast the problem got narrowed down to Basic LOAD leaving some state to 1541 which Spindle then depends on.
As LordCrass identified, it's only the disk ID that is not set up. This could be fixed in the M-E bootstrap code such that a seek is done before the reads. I think that could fit.
For an inject run strategy to work with the current code, the 1541 needs to be configured with this disk ID as a minimum. |
| |
WVL
Registered: Mar 2002
Posts: 903 |
Wouldn't it be the job of 1541u/u64 to set up the drive correctly with the right ID set? This sounds fixable to me.
Then again, I know nothing about drive code and don't understand why the disk ID would matter anyway? And what is linting (is that the disk structure with one t/s pointing to the next t/s?).
The last time I did anything with that is when I made cd1541 to make the d64 for pearls for Pigs (because cc1541 didn't support 40 tracks back then). Or.. actually I think jackasser added 40 track just in time in cc1541 and I still made my own tool which I can't seem to compile anymore...
So what I wanted to say : if I can make my own d64 creation tool knowing almost nothing about d64 and drives, then others will have done so too. The result: d64's with lots of small problems. A tool to check a d64 would be helpful. |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
Quote: Quoting mankeliBut yeah atleast the problem got narrowed down to Basic LOAD leaving some state to 1541 which Spindle then depends on.
As LordCrass identified, it's only the disk ID that is not set up. This could be fixed in the M-E bootstrap code such that a seek is done before the reads. I think that could fit.
For an inject run strategy to work with the current code, the 1541 needs to be configured with this disk ID as a minimum.
I wouldnt fix code for non standard hardware. ultimate firmware has to be fixed. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I wouldnt fix code for non standard hardware. ultimate firmware has to be fixed.
This isn't really about the Ultimate, it's just a matter if you want to support just running the binary to have the demo load, regardless how you got the initial loader into memory.
AFAIK there's is already a different option to load disks like this on the Ultimate's. Need to handle those disks differently, that's all. |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Issuing a JSR $d00e ("read BAM") at the beginning of the M-E bootstrap code restores the ZP variables and allows the bootstrap code to properly load the drive code even if the drive gets turned off and on between LOAD and RUN. This will be part of the soon-to-be released Sparkle 3.1. Not that I consider this a loader problem. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting SpartaNot that I consider this a loader problem. It both is and isn't. :)
For years i'd had fallback code to work around some of the graver 1541U emulation bugs. A few people shook their heads and told me not to work around emu bugs, lest they never be fixed, but 1541U and friends have too much of a market share.
With some unrelated drivecode overhaul, these workarounds became unnecessary, but i decided to keep the nag message that still keeps popping up here and there in demo compos. (Firmware version N good, version N+1 bad again. Apparently there's some weird regression thing going on.) |
| |
mankeli
Registered: Oct 2010
Posts: 146 |
Quote: Issuing a JSR $d00e ("read BAM") at the beginning of the M-E bootstrap code restores the ZP variables and allows the bootstrap code to properly load the drive code even if the drive gets turned off and on between LOAD and RUN. This will be part of the soon-to-be released Sparkle 3.1. Not that I consider this a loader problem.
Cool! Sounds like a simple fix on the loader side. I hope LFT would consider this for Spindle too at some point.
And yeah technically this isn't the loader's fault, but I think it's still a nice enhancement on the loader side to support having initial .prg to be loaded with different method. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I suppose the $1c BAM flag could be used to skip the read BAM call if already done, but maybe it's not worth it. |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: Quoting Martin PiperI remember now, it was the transwarp example that issues a M-E with the partial just loaded file in the read buffer: Transwarp V0.84 Yes, that's part of the 2-blocks bootstrap fastload strapped in front to speed up booting the actual loader.
Was 1-block in early dev versions, but that turned out to be too slow for my purposes. =)
(You can always fall back to loading Transwarp itself via ,8+RUN not ,8,1 when autorun won't work for some reason.)
As for the problems described here, i like the concept of a multi-loader coming in a self-contained package in C-64 memory, that would function just fine when run immediately after drive reset, new disk etc. :)
Then again, no particular love for non-stock aftermarket hardware.
After experimenting with making a smaller boot loader, I came up with this: https://github.com/martinpiper/C64Public/raw/refs/heads/master/..
This loads only $13 bytes at $316, it then executes code at $318, this then loads up to 256 bytes (in the same file) into $cf00-$cfff range.
In this example it loads code at $cfaf, which then just loads the next file. It could however do anything, like a M-E and then turbo load.
Code for the boot: https://github.com/martinpiper/C64Public/blob/master/IRQDisk/Sm.. |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
Quoting Martin PiperAfter experimenting with making a smaller boot loader, I came up with this: https://github.com/martinpiper/C64Public/raw/refs/heads/master/..
This loads only $13 bytes at $316, it then executes code at $318, this then loads up to 256 bytes (in the same file) into $cf00-$cfff range.
In this example it loads code at $cfaf, which then just loads the next file. It could however do anything, like a M-E and then turbo load.
Code for the boot: https://github.com/martinpiper/C64Public/blob/master/IRQDisk/Sm..
I'm afraid your autorun code does not work with my dolphindos setup, cpu jam $0008. so this is less compatible then the issue this thread is about.
I haven't tested more, but I wouldn't be surprised if this crashes on many other setups (with cartridge fastloaders) too. |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: Quoting Martin PiperAfter experimenting with making a smaller boot loader, I came up with this: https://github.com/martinpiper/C64Public/raw/refs/heads/master/..
This loads only $13 bytes at $316, it then executes code at $318, this then loads up to 256 bytes (in the same file) into $cf00-$cfff range.
In this example it loads code at $cfaf, which then just loads the next file. It could however do anything, like a M-E and then turbo load.
Code for the boot: https://github.com/martinpiper/C64Public/blob/master/IRQDisk/Sm..
I'm afraid your autorun code does not work with my dolphindos setup, cpu jam $0008. so this is less compatible then the issue this thread is about.
I haven't tested more, but I wouldn't be surprised if this crashes on many other setups (with cartridge fastloaders) too.
I don't target incompatible extras :) |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
Quoting Martin PiperI don't target incompatible extras :) then you're in the wrong thread :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Just turn oof dolphin dos. Like you need to do for most other games anyway. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
I guess this is the difference in bitfire's bootloader install, before uploading the loader with M-W/M-E and reading in the dir sector. I had faced those problems on Peiselulli's old 1541U too.
.install_bootstrap
jsr .open_w_15
lda #'i'
jsr .iecout
jsr .unlisten
|
| |
Fungus
Registered: Sep 2002
Posts: 691 |
Quote: Quoting Martin PiperI don't target incompatible extras :) then you're in the wrong thread :)
Yeah the thread is titled Spindle and Sparkle demos not launching. It is not titled use Martin Piper's crap because reasons. |
| |
hedning
Registered: Mar 2009
Posts: 4732 |
I don't really understand all of the tech stuff, but if it works on real hw, why is this an issue? It feels like it's something that the Ultimate guys should go for? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I don't really understand all of the tech stuff, but if it works on real hw, why is this an issue? It feels like it's something that the Ultimate guys should go for?
It works in the most common use case, yes. If you reset/power cycle the drive after loading it doesn’t work. Although not required, wouldn’t be bad to be resilient against something like that at the cost of 3 bytes IMO. Consider it a feature request.
BTW, this whole discussion pointed me to some potential problems in my own drive code. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Note that reset/powercycle just before running can cause other issues.
Here's a decades-old code snippet from the olden days before 1541U et al.:stepperfix: ; here, the drive was apparently reset immediately before running the loader -
; step down a track: this works normally if the stepping bits are congruent with the stepper motor.
; however, it may happen that the bits are misaligned (opposite to the actual stepper position, bit 1
; reversed), this alone does not move the head but stepping makes it go into the direction opposite to
; the one desired when moving. the stepping down two halftracks will actually step up and step down one
; halftrack each and thus will end up on the same track as before, but align the stepper bits to the motor.
ldy #2
sty CURRTRACK41
dey
jsr trkseek41
stepperok:This kind of thing is relevant only when going full bare-metal, though, DOS "I" routine should work fine. =)
Edit: Thinking about it, not so sure any more about the last bit. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
anything that reads from the disk (using DOS/jobcode) should realign the stepper with the usual +/-0.5 tracks dance, no? |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting chatGPZanything that reads from the disk (using DOS/jobcode) should realign the stepper with the usual +/-0.5 tracks dance, no? Only after errors. The problem of incongruent stepper bits may thus appear only after stepping (so after DOS-init and switching to bare-metal routines). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
But we were talking about "I" command, no? When there is no error, its all fine? :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: But we were talking about "I" command, no? When there is no error, its all fine? :)
it is, but a subsequent custom track seek needs to consider that the stepper bits can be incorrect and do "the dance" it self. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
But how would they be, after succesfull "I"? Wouldn't the DOS set them at least once? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Not sure if the are touched at all if not trying to move the head. A seek to track 18 if you are already there probably won't move anything. |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Please correct me if I’m mistaken but it seems to me that this is only a problem if you don’t know which track you are on before the first 0.5 track step is taken by the loader. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting SpartaPlease correct me if I’m mistaken but it seems to me that this is only a problem if you don’t know which track you are on before the first 0.5 track step is taken by the loader. Well seems to me that generally you don't know which track you're on right after a reset/powercycle. =) |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: Quoting SpartaPlease correct me if I’m mistaken but it seems to me that this is only a problem if you don’t know which track you are on before the first 0.5 track step is taken by the loader. Well seems to me that generally you don't know which track you're on right after a reset/powercycle. =)
And until the disk spins, a GCR sync mark is found, the GCR header is read, decoded, and the track and sector bytes are discovered. :) |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
Except when some kind of DMA loading for the first file was involved (Like 1541U or TC64 does) - which is what this thread is all about :) |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
That’s what the read BAM call will remedy:
1. By some means (LOAD, DMA), Sparkle’s installer gets loaded to the c64
2. Drive reset (in case of real HW)
3. RUN
4. M-E bootstrap code gets uploaded and executed in drive’s buffer
5. Bootstrap reads BAM
6. I am on track 18 |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
Tested so far on U, U2, and U2+, 1541-II, and Oceanic. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
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: 1790 |
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: 11387 |
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: 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 ? :) |
