| |
cadaver
Registered: Feb 2002
Posts: 1153 |
AR/RR fastloader, command channel & device number other than 8
I'm tinkering with a loader / boot system where it first sends the "UI" command on the command channel to read back the device init-time string & detect the device type. Similar to what the Easyprog fastloader (ELoad) does.
Seems that when the device number is something other than 8, and AR/RR fastloader has been enabled, reading the command channel will get stuck inside Kernal.
Using device number 8 works fine. Not enabling AR/RR fastloader (normal reset) also works.
Anyone else seen this or have an explanation? Probably this is something that I shouldn't bother too much trying to work around, since there are ways the user can fix it :) |
|
... 18 posts hidden. Click here to view all posts....
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Even shorter repro case with the AR/RR wedge command:
Load something on device 9 with fastload
@UI
@
-> device not present, which is cause of the lockup if you just persist on trying to read from it :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting cadaverEven shorter repro case with the AR/RR wedge command:
Load something on device 9 with fastload
@UI
@
-> device not present, which is cause of the lockup if you just persist on trying to read from it :)
Yes... but:
@UJ
@
works fine.
And it works also on Sd2IEC, Vice Virtual Drive and Ide64... |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Cool, thanks!
EDIT: UJ is unfriendlier in the sense that you actually do have to wait until the drive is responsive again, else you'll lockup. So yeah.. probably still have to go the upload drivecode first route :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
I guess rr/ar leave some drivecode running after a load, so maybe you go into troubles uploading some code to drive...
Just guessing eh... |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Possibly it messes the drive OS state some way, and only for device != 8. After the UI command, the drive appears to be in the idle loop, not responding to anything the computer would send under ATN.
In my tests uploading new drivecode always works fine even after AR fastload. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Got info from GRG, the problem stems from the AR fastloader setting $1802 on the fastload-enabled drive, but not resetting it. It's possible to M-W the correct value back in to fix, though that's making an assumption the drive is a 1541 :) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
cadaver: Do you save onto the disk?
If not, you can change the DOS version marker in the BAM (3rd byte on track 18, sector 0) from $41 ('A') to something else.
Trying to save (without prior "UI" command and AR/RR problems) would yield DOS mismatch error 73, which has the init string in the message.
Now, of course, no idea if that behaviour is implemented consistently across all weirdo drives. :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Yes, I save using jobcodes to write on preallocated sectors (or directly via Kernal on fallback loader)
But as all solutions seem a bit nasty, I went ahead and reversed my detection strategy, so drivecode-capable drives no longer receive the UI command / string detection at all, only SD2IEC. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
That seems like a sane thing to do. :)
How do you detect the real-drive model now? |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
I upload a monolithic drivecode from about $0400 to $06ff, it contains a detection based on Dreamload (reading strategic ROM locations), then it patches itself for the drive model, and signals to the C64 with the DATA line. C64 side contains a delay loop to watch for that signal.
Actually just committed the stuff to https://github.com/cadaver/c64gameframework/blob/master/loader.s |
| Previous - 1 | 2 | 3 - Next |
