| |
Bacchus
Registered: Jan 2002
Posts: 155 |
Drive code: Detect missing disk...
I have detecting missing *device* covered. This logics work really well:https://codebase64.org/doku.php?id=base:reading_the_error_chann..
Also, checking if a file exists, one would expect that a plain Open would do the job, but you basically need to read the first byte and checking the Status. But then you have established that.
But what is the easiest way to detect if the device contains a disk? Let's say we have established that there is a disk in the drive. I can start reading a file, but then I don't know if the error will tell me if the file or the entire disk is missing.
Should I do a block read, start reading the directory or what is the general suggestion?
/Bacchus |
|
| |
Comos
Registered: May 2004
Posts: 73 |
If you rely on the kernal calls, then using a directory routine and to read a valid byte and check $90 might do the trick. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
When using KERNAL calls only, reading the device's error channel is the only way to reliably tell the kind of error.
This is something else than "drive code", though. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11290 |
Turn on the motor and wait for a sync (with timeout) - should be easy enough :) |
| |
Count Zero
Registered: Jan 2003
Posts: 1878 |
Quote: Turn on the motor and wait for a sync (with timeout) - should be easy enough :)
Zibri approves! *SCNR* |
| |
Bacchus
Registered: Jan 2002
Posts: 155 |
Quote: If you rely on the kernal calls, then using a directory routine and to read a valid byte and check $90 might do the trick.
So basically a getbyte from the filename "$", and one could tell already from the first byte if there was a byte or not?
I do know how to drivecode, but I want to select the route of the least resistance here.
/Bacchus |
| |
Comos
Registered: May 2004
Posts: 73 |
Quote: So basically a getbyte from the filename "$", and one could tell already from the first byte if there was a byte or not?
I do know how to drivecode, but I want to select the route of the least resistance here.
/Bacchus
Read just one byte and check bit 1 of $90, 1 = Timeout on read, which in simple would mean there is no disk inserted since we are accessing the lower level - the directory.
If you do this check on a file, then you won't be able to determinate, if the file is simply not present or there is no disk inserted,since in both cases you'll get the same bit set.
Ofcourse this method is not perfect for some detailed error handling.
If you would like to go the way to read out the error channel, then you have to do something in advance like running the init "I" command and then read out the error channel. |
| |
Count Zero
Registered: Jan 2003
Posts: 1878 |
Quoting BacchusSo basically a getbyte from the filename "$", and one could tell already from the first byte if there was a byte or not?
A drive such as a SD2IEC could easily fool for an inserted disc in such a case - so it likely depends on the used loader/saver compatibility in the end unless you determine the drivetype as well or stick to plain kernal routines. hm? |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
The clean way is still to read the error channel.
Why is this not an option? :) |
| |
Mason
Registered: Dec 2001
Posts: 461 |
Sorry for my vague memory, but it's many years ago I did it
I reckon you can load a byte from a file or the directory. If it doesn't work I reckon $90 is set as a status |
| |
chatGPZ
Registered: Dec 2001
Posts: 11290 |
Quote:Why is this not an option?
head bump? |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting GroepazQuote:Why is this not an option? head bump? If head bump is to be avoided, actual drive code is required*. =) (And then you'll run into problems on exotic drives.)
* Turn on motor, wait for sync, stop on timeout. |
| |
Bacchus
Registered: Jan 2002
Posts: 155 |
Quote: Read just one byte and check bit 1 of $90, 1 = Timeout on read, which in simple would mean there is no disk inserted since we are accessing the lower level - the directory.
If you do this check on a file, then you won't be able to determinate, if the file is simply not present or there is no disk inserted,since in both cases you'll get the same bit set.
Ofcourse this method is not perfect for some detailed error handling.
If you would like to go the way to read out the error channel, then you have to do something in advance like running the init "I" command and then read out the error channel.
This is a Kernal only scenario. Would love to see it work on any drive. Codebase has a routine for device detection that it claim is less portable, which I guess means that it risk not working on alternative Kernals, but I would like to assume it works on exotic drives. ($BA is assumed to be right when calling this)
My conclusion here is basically;
jsr TestDevice // Should detect Device not found
bcc !+
jmp DeviceNotPresent // Device not present
!: jsr TestDisk // Should detect Disk not present
bcc !+
jmp DiskNotPresent // Disk not present
!: jsr TestFiles // Load the filenames - Handle file not found
The routines that are used would be:
TestDevice:
lda #$00
sta $02a1
sta $90 // clear status flags
lda $ba // device number
jsr $ffb1 // call listen
lda #$6f // secondary address 15 (command channel)
jsr $ff93 // call seclsn (second)
jsr $ffae // call unlsn
lda $90 // get status flags
bne NotPresent // device not present
clc
rts
NotPresent: sec
rts
TestDisk: lda #1
ldx #<DirName
ldy #>DirName
jsr setnam
lda #$02
ldx $ba // last used device number
// bne !+
// ldx #$08 // default to device 8
!: ldy #$02 // $01 means: load to address stored in file
jsr setlfs // call SETLFS - OK with no vectors
jsr open
ldx #$02
jmp chkin
jsr chrin // Get a byte
jsr readst
jsr DoClose
bne Error
clc // Directory - first byte - loaded fine
rts
Error: sec // DIrectory - first byte - didn't load properly
rts
DoClose: pha
lda #$02
jsr close
jsr clrchn
pla
rts
.encoding "screencode_mixed"
DirName: .text "$"
.encoding "screencode_mixed"
=> Any errors found in that?
=> Should I call to init the drive at any point? If so, would that be the command "U:", "UJ", "U9" or a "plain" "I"?
/Bacchus |
| |
Bacchus
Registered: Jan 2002
Posts: 155 |
@krill Ok, gotch - this is not "drive code" - it's computer code, accessing the drive. I know how to push stuff to the drive end execute it and this is not that.
This is Pure computer, pure kernal and working with data on the drive, ensuring I capture ALL and ANY relevant error scenario, and also make it work across as many drives as possibly.
I know the stuff that you make in relations to drives. This is not making the fastest sport car. This is making the Volvo totally solid. ;-)
/Bacchus |
| |
Bacchus
Registered: Jan 2002
Posts: 155 |
Bugger - there was a jmp chkin that should be a jsr. Sorry about that...
/Bacchus |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
What do you actually want to achieve?
Why does there need to be a distinction between file not found and no disk inserted? |
| |
Comos
Registered: May 2004
Posts: 73 |
@Bacchus,
the test device routine you have is serial dependant, if you want to have it universal, it can be rewritten in kernal aswell. |
| |
Bacchus
Registered: Jan 2002
Posts: 155 |
@krill I want to load and save stuff to disk as part of a program, and that program needs to handle the situations where there is a save problem. Formally no need to differentiate between the two cases, but if you select a device you might want to capture that this is a device not available and I am also keen to capture no disk in the drive before I start the actual save.
@cosmos The use case is serial with a drive. No need to generalize it beyond the actual use case.
I did a test program where I implemented the above, but there is still issues when the same code is implemented in the program. :-P
/Bacchus |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting Bacchusif you select a device you might want to capture that this is a device not available and I am also keen to capture no disk in the drive before I start the actual save. What would be the difference between erroring out after an init command before saving vs. attempting to save and then erroring out? |
| |
Bacchus
Registered: Jan 2002
Posts: 155 |
Gunnar, you come from a different perspective.
You do your thing and put the loader out for others to use. I am retrofitting stuff, meaning I need to wedge in my stuff as smoothly as possible. I might also not control what happens after a certain point unless I open up more patching with potential side effects.
So I prefer to do my stuff and secure things are as good as I can make them, and then I release the thing, not being sure I can regain control if it bugs out at a later stage.
Not sure that argument holds water, but also there is an inner loop loading five different files. Letting them all fail will take a long time. Wedging in stuff there is tricky so I prefer to do it this way this time ...
The things with that piece of code I have done is that it tells "device not present" from "disk not present", and that *looks* nice :-)
/Bacchus |
| |
Comos
Registered: May 2004
Posts: 73 |
Quoting Bacchus
I did a test program where I implemented the above, but there is still issues when the same code is implemented in the program. :-P
What kind of a issue? |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting Bacchusthere is an inner loop loading five different files. Letting them all fail will take a long time. Wedging in stuff there is tricky so I prefer to do it this way this time ... Retrofitting or not, what i was saying is that i see no advantage of checking for disk-not-present prior to saving, as saving itself does that check implicitly, too.
This is also independent from any inner loops handling multiple files. |
| |
Bacchus
Registered: Jan 2002
Posts: 155 |
Quote: Quoting Bacchus
I did a test program where I implemented the above, but there is still issues when the same code is implemented in the program. :-P
What kind of a issue?
@Cosmos Can't really describe it perfectly but it feels like the commands aren't concluded properly, and the drive isn't ready to accept new commands. The detect disk command works arbitrarily. Sometimes it does and sometimes not (possibly depending on what happened before). Trying to send an "I" commands after my detection routines, I simply get an error. In VICE I can switch to DEV 8: and do M 0200 to see the status message, and sometimes that is Syntax error. That could sometimes happen if I send commands in the wrong case (common issue I have when messing with drive code).
@Krill I fully sympathize with this point of view and I will onboard it when considering the task ahead. Would be stupid not to :-)
Can be agree that if $98 is $00, then I have closed all files I have opened, right?
/Bacchus |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting BacchusCan't really describe it perfectly but it feels like the commands aren't concluded properly, and the drive isn't ready to accept new commands. The detect disk command works arbitrarily. Sometimes it does and sometimes not (possibly depending on what happened before). I think it's important to error out at the earliest possible chance. So i'd check $90 after every command that might fail, plus OPEN returns an error flag via the C flag. On error, of course, need to properly clean up, too. |
| |
Comos
Registered: May 2004
Posts: 73 |
Quoting KrillI think it's important to error out at the earliest possible chance. So i'd check $90 after every command that might fail, plus OPEN returns an error flag via the C flag. On error, of course, need to properly clean up, too.
Besides $90 it's possible to readout accu for error code aswell in certain calls. |
