<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Fri, 22 Sep 1989 02:23:00 GMT
From   : mnetor!tmsoft!masnet!canremote!wayne.hortensiu@uunet.uu.net (WAYNE HORTENSIU)
Subject: NOVADOS bug report

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 


End of INFO-CPM Digest V89 Issue #176
*************************************
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>