Intercept BDOS1 16h create file error

Resident (34)

03-02-2016, 15:34

Under disk basic I hook the DOS1 kernel style errorhandlers. I use the address F323 and F1e6 to catch, for example, disk offline errors. The errors are redirected to a custom handler. This works fine.
http://map.grauw.nl/articles/dos-error-handling.php

A unsuccessful file create wasn't intercepted. It took me quite a while to figure out why a file create was unsuccessful. The directory was full... A disassembly of 16h, helps to understand the problem.

ld de, FCB
ld c, CREATE
call BDOS ; BDOS EQU 0f37dh ( Basic Disk OS)
or a ; 000h if successful
jp nz, @Error ; 0ffh if unsuccessful

; Subroutine BDOS 16 (create file)
A461D: push de
T461E: call A440E ; validate FCB drive and filename
jr c,A464D ; invalid, quit with error
inc hl
inc hl
ld (hl),0 ; clear S2 byte
ld hl,YF2B9
ld a,"?"
ld bc,11
cpir ; wildcard char in filename ?
jr z,A464D ; yep, quit with error
call A42B5 ; find first directoryentry
jr nc,A4651 ; found, special actions for existing file/device
ld a,(YF2FE)
cp 0FFH ; found free direntry ?
jr z,A464D ; nope, quit with error (directory is full)
call A4317 ; get direntry
push hl
pop iy
jr A4669 ; setup direntry

A464D: pop de
ld a,0FFH
ret

Address F2FE, first free direntry (0FFH if none found)
Address F2B8, current direntry number

What is the best way to intercept these kinds of errors? I could check F2FE. Are there any other options?

By hit9918

Prophet (2932)

03-02-2016, 16:59

so, you get no jump to the handler, but the function returns with 255?

Is "disk full" maybe the only error that can happen with function 16h?
Then you know the error when it returns 255.
The "harder" kind of errors like disk offline should still be told by the error handler.

The source seems to say that 255 can also happen with funny characters in the filename, but one can filter that before calling 16h.

what else could go wrong.
"file already exists" - I think then bdos just wipes over that old file.
so that error is made on a higher level with extra code looking whether the file already exists.

Maybe when writing to disk returns 255, it too means disk full?

By Bit Addict

Resident (34)

03-02-2016, 17:39

Correct. No jump to the handler. Function 16h returns 255. The disk is not full, FAT (bdos1) can only handle 254 entries. On a 720k FDD you can have only 112 files.

I could check wild chars etc. but what else could go wrong, for example writing a file? I hoped that the error (abort) handler will intercept everything.

By flyguille

Prophet (3031)

03-02-2016, 19:14

jump handle, is only for I/O errors, not for disk full, bad file name, etc.

By hit9918

Prophet (2932)

03-02-2016, 19:35

With file write I would expect that 255 means "disk full".
And other things are the "hard errors" told by the error handler, disk broken, disk offline.
The only possible way for a 255 is "disk full". Except there is again an unexpected surprise