wayne.hortensiu@canremote.uucp (WAYNE HORTENSIU) (09/22/89)
There is a serious bug in Novados release H (and possibly earlier
releases as well) that crops up when the number of entries used in your
disk's directory becomes a multiple of 256. Symptoms include: all files
disappearing that are after then first 256 entries, being able to open
files that disappear when you try to close them, and two copies of a
file showing up in the directory, one with 0 blocks used. To make
matters worse, when the NovaDOS fast boot option was used, the problem
would vanish if the directory had fewer then 256 entries used when it
was initally logged in at startup. You could add files to your heart's
content until you crossed the 512 entry boundary, when half of your
files would promptly vanish. The incorrect code, taken from NVDS-2.Z80,
is shown below:
;
; NOVADOS CODE -- INCORRECT -- Set last file
;
setlf: call tstlf ; Test last file
ret c ; No then exit
inc de ; Increment last file
ld (hl),e ; << Save it in temp0
inc hl ; << -- argh! temp0+1
ld (hl),d ; << & temp0+2 !!
ret ; And exit
;
; Test last file
;
tstlf: ld hl,(temp0) ; Get pointer to last file
ld de,(filcnt) ; Get file counter
ld a,e ; Subtract de-(hl)
sub (hl)
inc hl ; <<-- now (hl) points to
ld a,d ; to temp0+1 !!
sbc a,(hl)
ret ; Exit
The correction is simple; store the hi byte first, decrement the
pointer, and store the low byte. The correct code is shown below (this
fragment was extracted from Z80DDISK.ZZ0, release 24).
;
; Z80DOS CODE -- CORRECT -- Set last file
;
setlf: call tstlf ; Test last file
ret C ; No then exit
inc de ; Increment last file
ld (hl),d ; Save it in temp0
dec hl
ld (hl),e
ret ; Andd exit
;
; Test last file
;
tstlf: ld hl,(temp0) ; Get pointer to last file
ld de,(filcnt) ; Get file counter
ld a,e ; Subtract filcnt-(temp0)
sub (hl)
inc hl
ld a,d
sbc a,(hl) ; Carry means (temp0) > filcnt
ret ; Exit
I went back to the old SUPRBDOS code to see if this bug could have
manifested itself in other derivates, including (shudder) ZRDOS, ZSDOS
or ZDDOS. The SUPRBDOS code was correct; so this appears to be a bug
localized to NOVADOS.
This has been driving me <<nuts>> for about a month now. Since I've
made extensive mods to NovaDOS to support some Z80DOS style
datestamping features (notably get/use file datestamps), I wasn't sure
if the problem was in NovaDOS itself, or my mods. Now I am! I found
it by painstakingly tracing through the reset disk, select disk BDOS
call sequence and narrowing down which piece of code was going awry.
Wayne Hortensius
Canada Remote Systems
September 21, 1989
---
* Via ProDoor 3.1aR