| |
cadaver
Registered: Feb 2002
Posts: 1160 |
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 :) |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
You shouldnt use the drive message for detection anyway, its extremely unreliable :) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Assume 1541 if unidentified :)
In seriousness, the ID string method is nice for not needing to push the detection / drivecode patching code to the drive first, which results in faster startup. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yeah ok, that could work good enough in practise.
the problem you are describing seems kinda odd though. is it really a AR issue? would be really weird :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I'm reading the drive ROM at strategic places using M-R to detect the model, seems to work fine (and shouldn't be noticably slower than sending UI = drive reset, then reading and parsing the init string).
Any better methods? :) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
groepaz: It looks like the combination of AR/RR loader and the device number, and should be possible to reproduce in VICE too.
The code reading the cmd channel shouldn't be anything special, SETNAM with 'UI', SETLFS 15,<devicenum>,15, OPEN, CHKIN, then CHRIN until status bit $40 is set. I'm running it inside stack but it shouldn't be a stack overwrite issue.
Krill: that's probably the most optimal. I used to send the whole drivecode, doing all detection on drive side, and then seeing if it actually starts to run (by checking if the lines change state). But the ID method is needed for SD2IEC in any case.
Btw. it seems that on 1541 the reset is very fast. On 1581 and above it takes noticeable time. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
beware: depending on the ROM in the 1541 you need to wait a bit before issueing any commands or it will indeed hang and wait forever |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting cadaverBut the ID method is needed for SD2IEC in any case. How does SD2IEC respond to M-R or M-E? My method so far has been to M-R $0300 in drive RAM, then upload and execute a small routine to flip (EOR #$FF) the value at $0300 and then M-R it again. If no change, fallback to KERNAL API. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
M-R on SD2IEC returns bytes from the drive ROM. M-E initiates one of the firmware fastloader implementations if the data checksum / address from M-W matches.
In my case I need to know that it's specifically SD2IEC, to know I can send the "eload1" string to get a somewhat sane timed 2-bit fastload protocol. Your method would be good for getting a negative result (as intended for the fallback) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
In my loader i use the "UJ" command to reset drive then, after a delay to wait drive reset, i read the error channel and i can found which drive is by pattern matching the string drive send...
Seems to work also on devices !=8 even if ar/rr fastload is enabled. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting cadaverIn my case I need to know that it's specifically SD2IEC, to know I can send the "eload1" string to get a somewhat sane timed 2-bit fastload protocol. Can you read the error channel after sending the "eload1" string to SD2IEC? Because any other drive would return error 31, syntax error. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting FlaviowebIn my loader i use the "UJ" command to reset drive then, after a delay to wait drive reset, i read the error channel and i can found which drive is by pattern matching the string drive send...
Seems to work also on devices !=8 even if ar/rr fastload is enabled. That seems to be pretty much exactly what cadaver does. Except it works with AR/RR and devices on #9 and up. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Thanks. I have the drive stuck in the idle loop and computer also waiting after CHKIN, so I'll check my sequence of calls, possibly a better idea to close the command channel first, then reopen before reading. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Quote: Quoting cadaverIn my case I need to know that it's specifically SD2IEC, to know I can send the "eload1" string to get a somewhat sane timed 2-bit fastload protocol. Can you read the error channel after sending the "eload1" string to SD2IEC? Because any other drive would return error 31, syntax error.
Sorry, that's bytes sent in a M-W command, so an actual drive would accept it just fine. The bytes need to also be executed (M-E), so a drive would crash.. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
OK.. seems I have a minimal repro case which can be done in BASIC. Load any file with fastloader on drive 9, then
NEW
1 OPEN15,9,15,"UI"
2 GET #15,A$:PRINT A$;:GOTO2
Should get stuck without printing anything.
I'm using Retro Replay 3.8Q. Though I believe I got the same result with AR6. Will do further testing. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting cadaverSorry, that's bytes sent in a M-W command, so an actual drive would accept it just fine. The bytes need to also be executed (M-E), so a drive would crash.. Sigh. That's a pretty poor design committed by the ELoad inventor. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting cadaverYour method [of seeing whether the drive can execute uploaded code] would be good for getting a negative result (as intended for the fallback) The only other "drive" than SD2IEC that can't execute custom code i came across is VICE with disabled true drive emulation. The latter might probably survive uploading the "eload" string and "executing" it just fine (after the initial safe M-E check). If so... :) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yeah, but in case the drive is an actual SD2IEC, then you'd want to continue with the ELoad protocol. And with VICE fast emu or IDE64, you'd want to continue with Kernal calls, so you'd still need to distinguish between.
You kind of can do this, by watching the $a5 serial bus variable, if that is unchanged (or also if you get an error at any point while sending M-W etc.), you know it's not an actual serial device. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Hmm.. probably I'll just reverse my detection sequence. I was trying to be (too) clever by having multiple loader implementation files and choosing them with an initial bootpart, which uses the UI command.
But if I just load the full loader first, I can try uploading the drivecode first, and if that fails, proceeding to the ELoad / Kernal load decision.
It appears I get the drive 9 lockup on using the UI command after AR turbo load, even if I load a file byte-by-byte (CHRIN) inbetween. So yeah, best to use it only after verifying the drive isn't arbitrary drivecode capable. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
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: 463 |
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: 1160 |
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: 463 |
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: 1160 |
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: 1160 |
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: 2980 |
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: 1160 |
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: 2980 |
That seems like a sane thing to do. :)
How do you detect the real-drive model now? |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
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 |
