| |
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. |
... 18 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
