| |
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....
|
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
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: 2822 |
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: 2822 |
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: 1153 |
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: 1153 |
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: 1153 |
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: 2822 |
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: 2822 |
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: 1153 |
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: 1153 |
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. |
| Previous - 1 | 2 | 3 - Next |
