| |
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....
|
| |
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 :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
