File Command Errors

[Mike]

Update: I just ran tests with today's build of "GTK3VICE 3.7.1 win64 r44603".

• With True Drive Emulation OFF and Virtual Device Traps ON, in a PC directory, with FILE1 and FILE2 missing, VDrive errorneously reports "62,FILE NOT FOUND,00,00" for both Scratch commands (should be 01,FILES SCRATCHED,00,00) and writes FILE1 and FILE2. Renaming FILE2 into FILE1 results in FILE2 overwriting FILE1. FILE1 now contains the contents of FILE2, FILE2 is evidently missing and the test program bails out at line 71 with "62, FILE NOT FOUND,00,00".
• With True Drive Emulation OFF and Virtual Device Traps ON, in a PC directory, with FILE1 and FILE2 present, VDrive errorneously reports "01,FILES SCRATCHED,00,00" (should be "01,FILES SCRATCHED,01,00"), and later bails out again at line 71 for the same reasons as above.
• With True Drive Emulation OFF and Virtual Device Traps ON, in a *.d64 disk image, with FILE1 and FILE2 missing, VDrive dies either on the first or second Scratch command: reading the status does not terminate, with a ?STRING TOO LONG error in line 87.
• With True Drive Emulation ON (1541) and Virtual Device Traps OFF, in a *.d64 disk image, with FILE1 and FILE2 missing, VICE correctly reports "01,FILES SCRATCHED,00,00" for both Scratch commands and writes FILE1 and FILE2. Renaming FILE2 into FILE1 is correctly faulted with "63,FILE EXISTS,00,00". Both FILE1 and FILE2 are retained and read and display the expected contents.
• With True Drive Emulation ON (1541) and Virtual Device Traps OFF, in a *.d64 disk image, with FILE1 and FILE2 present, VICE correctly reports "01,FILES SCRATCHED,01,00" for both Scratch commands and writes FILE1 and FILE2. The rest of the program positively continues as expected.

In r44603, running the test program with VDrive within a *.d64 disk image yields a working result. The S command correctly reports the number of scratched files for the first run (with FILE1, FILE2 missing) and the second run (with FILE1, FILE2 present). The R command is correctly faulted with "63,FILE EXISTS,00,00", there is not anymore the above mentioned overwrite-on-rename behaviour.

However, somewhat unexpectedly, running the test program with VDrive with a mounted PC directory, the Scratch command incorrectly reports the number of scratched files as 0 with "01,FILES SCRATCHED,00,00" even though the files have been deleted (if they were present), and then stops at the R command with "62,FILE NOT FOUND,00,00" even though both FILE1 and FILE2 are there (having been newly written by the program).

I have filed this as bug #1956 in the VICE tracker.

[chysn]

In the test program below, all the command channel operations (send command, read status) operate with a previously opened logical file with secondary address 15, which is never closed in-between.

Wow, thank you for doing all that. A very thorough treatment!

Only the behaviour with True Drive Emulation ON and Virtual Device Traps OFF is correct. You see the same behaviour on real hardware, with a 1541. I will test with my SD2IEC in a directory and in a disk image later the day.

You'll probably find, as I did, that SD2IEC behaves like VDrive, in terms of erroneous reporting. I also found that SD2IEC does not support rename. If your findings are different, please let me know. My SD2IEC is very old, and there may have been updates.

In short - as I wrote in the previous posts -, at least with older versions of VICE, VDrive is seriously broken. It doesn't make much sense to (try to) guard own programs against that (i.e. "program around" a fault in emulation).

I'm using the latest version of VICE and seeing these issues. If it were "TDE vs. VDrive," I'd gladly just say, "Status reporting works only with TDE or a real 1541 (which I can not yet verify first-hand)." However, apparently, SD2IEC's status reporting behaves more like VDrive than like a 1541. Since people use SD2IEC's out there in the real world, it might be best to succeed and fail silently. Commands that are supported, formatted properly, and meet the conditions of success, will succeed.

I may defer this decision until I get a newer SD2IEC. Meanwhile, I'm personally willing to abandon VDrive. I just use it because it's easy to send programs to VICE with a Bash build script via cp.

[Mike]

You'll probably find, as I did, that SD2IEC behaves like VDrive, in terms of erroneous reporting. I also found that SD2IEC does not support rename. If your findings are different, please let me know. My SD2IEC is very old, and there may have been updates.

I just did the tests with my VC-20 + C64SD V2 with current sd2iec firmware (1.0.0atentdead0-36-g7e7be29 2023-01-19).

All four test runs (within a *.d64/in a SD card directory vs FILE1/FILE2 absent or present) ran fine with a "63,FILE EXISTS,00,00" on the R command and the correct number of scratched files reported by the S commands. Also, the R command on its own works as expected (i.e. it does its assigned job).

However, the sd2iec firmware seems to retain the current status even upon closing and re-opening the command channel. When I manually deleted FILE1 and FILE2 beforehand for the 'initial' run (with OPEN15,8,15,"S0:FILE1":CLOSE15 in direct mode, same for FILE2), the program stops unexpectedly with the "01,FILES SCRATCHED,00,00" message directly in line 14.

That behaviour can though be rectified by using OPEN15,DN,15,"I0" instead of just a plain OPEN15,DN,15 - doing a drive init to re-read BAM, etc. on program start does do no harm.

You might want to take a look at https://sd2iec.de/nightlies/ to see if your SD2IEC drive is still supported with newer firmware.

[chysn]

You might want to take a look at https://sd2iec.de/nightlies/ to see if your SD2IEC drive is still supported with newer firmware.

I'm not sure which SD2IEC I have. It doesn't really say anything on it except for "sd2iec". When I run the command "X?" it returns

Code: Select all

03,J-:C157,08,00

I removed the lone screw in the thing in hopes of peeking at the PCB, and it didn't open. I didn't feel like forcing it, it's like the shell is glued together or something.

I tried putting the most recent firmware files in an SD root, and my SD2IEC did exactly nothing with those files when powered up.

I changed my status-grabbing code to match what you're doing in your BASIC program, so:

Code: Select all

disk_cmd:   ldx DEVICE
            lda #15
            tay
            jsr SETLFS
            jsr OPEN
            ldx #15
            jsr CHKOUT
            ldy #0
-loop:      lda INBUFFER,y
            beq show_st
            jsr CHROUT
            iny 
            bne loop
show_st:    jsr CLRCHN          ; Execute command         
            ldx #15             ; Show command status
            jsr CHKIN           ;   Set the channel for command status input
-loop:      jsr CHRIN
            jsr CHROUT          ; OK to use CHROUT, input is back to normal
            cmp #$0d            ; CR terminates status
            bne loop            ; ,,
            jsr CLRCHN          ; Close command channel out
            lda #15             ; ,,
            jmp CLOSE           ; ,,

It saves a couple bytes compared to the TALK/UNTALK method, but otherwise performs about the same.

I think I'll buy a new SD2IEC, probably from TFW8B rather than Random Ebay Vendor. I'll learn a lot more once I'm up-to-date. I should really have more than one, anyway. I have seven VICs in case one dies for good, I shouldn't permit such a bottleneck!

[chysn]

That behaviour [persisting messages] can though be rectified by using OPEN15,DN,15,"I0" instead of just a plain OPEN15,DN,15 - doing a drive init to re-read BAM, etc. on program start does do no harm.

I did add the drive init to my command-execution code. This actually fixes just about every wrong message in VDrive (with still some modest weirdness with reporting number of scratched files). I'm at the point where I'm comfortable releasing the feature with largely-reliable status messages.

Thanks for your help, once again, both Mike and wimoos!

I'm always internally enraged when someone says, "My problem's solved!" on a forum without posting the solution. So the updated code is here:

Code: Select all

            ; Execute disk command          
disk_cmd:   ldx DEVICE          ; Get current device number
            lda #15             ; Set file number and secondary address
            tay                 ; ,,
            jsr SETLFS          ; Set logical file
            jsr OPEN            ; And open it
            ldx #15             ; Redirect CHROUT to command
            jsr CHKOUT          ; ,,
            lda #"I"            ; Send initialize command to make sure
            jsr CHROUT          ;   status is updated
            jsr CLRCHN          ;   ,,
            ldx #15             ; Re-redirect CHROUT to command
            jsr CHKOUT          ; ,,
            ldy #0              ; Now send the specified command from the
-loop:      lda INBUFFER,y      ;   input buffer, terminated by 0
            beq show_st         ;   ,,
            jsr CHROUT          ;   ,,
            iny                 ;   ,,
            bne loop            ;   ,,
show_st:    jsr CLRCHN          ; Execute command         
            ldx #15             ; Show command status
            jsr CHKIN           ;   Set the channel for command status input
-loop:      jsr CHRIN           ; Get status text from output channel
            jsr CHROUT          ; OK to use CHROUT, input is back to normal
            cmp #CR             ; CR terminates status
            bne loop            ; ,,
            jsr CLRCHN          ; Close command channel out
            lda #15             ; ,,
            jmp CLOSE           ; ,,

[groepaz]

Just committed a fix for that bug, have a look

[chysn]

Just committed a fix for that bug, have a look

Thank you! So I don’t have to re-read this whole thing, which bug do you mean?

[pixel]

Thanks a lot for your thorough explorations!

Am hoping that all that disk science will form bug tickets for VICE as programming file system stuff with it has been confusing me a bit, trying to get low-level and creating an UltiMem file system driver for example.

[groepaz]

Thank you! So I don’t have to re-read this whole thing, which bug do you mean?

The wrong behaviour in VICE when a host directory is mounted via vdrive. Scratch reports one file scratched now, and the rename command reports file exists as it should.

[chysn]

Thank you! So I don’t have to re-read this whole thing, which bug do you mean?

The wrong behaviour in VICE when a host directory is mounted via vdrive. Scratch reports one file scratched now, and the rename command reports file exists as it should.

Awesome, I appreciate that! I'm not sure what the build process is for VICE, so I'll probably have to wait for it to trickle into the released binaries, but I wish SD2IEC was so responsive!

[srowe]

I'm not sure which SD2IEC I have. It doesn't really say anything on it except for "sd2iec". When I run the command "X?" it returns

Read the command channel immediately after boot, it returns the firmware version.

[groepaz]

Awesome, I appreciate that! I'm not sure what the build process is for VICE, so I'll probably have to wait for it to trickle into the released binaries, but I wish SD2IEC was so responsive!

You can always grab development builds from here: https://github.com/VICE-Team/svn-mirror/releases - they will appear about half an hour after the commit

[chysn]

You can always grab development builds from here: https://github.com/VICE-Team/svn-mirror/releases - they will appear about half an hour after the commit

It looks like these are only for Windows and Linux?

[groepaz]

Yes, macOS requires binary signing, which we can not do automatically. (You can use homebrew to install the svn-head revision though)

[chysn]

Yes, macOS requires binary signing, which we can not do automatically. (You can use homebrew to install the svn-head revision though)

I might give this a shot!