[Coco] Nitros9 & Mess
Nathan Woods
npwoods at cybercom.net
Mon Feb 2 19:33:00 EST 2004
Bill Nobel wrote:
>>> * read original file descriptor of Directory
>>> vhd seek: 0000B5 0000B500
>>> read dump: 00FD00
>>> BF 00 00 04 02 01 16 19 02 00 00 01 00 00 00 00
>>> 00 00 B6 00 07 00 00 00 00 00 00 00 00 00 00 00
>>> .....(extra cut)
>>>
>>> * write file descriptor (file size expanded by 32 bytes)
>>> vhd seek: 0000B5 0000B500
>>> write dump: 00FD00
>>> BF 00 00 04 02 01 16 19 02 00 00 01 20 00 00 00
>>> 00 00 B6 00 07 00 00 00 00 00 00 00 00 00 00 00
>>> ....(extra cut)
>>>
>
> The above sector dump is when RBF updates the file descriptor for the
> directory. It's given to show the directory entries are expanded as
> RBF requested. This is correct and proper.
When I was observing the problem, the actual directory update was
working properly, and the problem occured when RBF flushed its cache. I
wasn't trying to say that the problem was in RBF per se (after all, it
works on the real thing); it was just that by my observations, the
earliest discernable manifestation of the problem was the result of an
RBF cache flush operation (L1205 in rbf.asm in the NitrOS9 source.)
Then again, it is always possible that I was chasing phantoms. I seem
to have lost my notes from last September; Robert Gault, do you remember
anything?
> I think so as well, but I am concerned about a sign issue. When you
> look at the code in fileio.c you will find it uses the Windows calls
> to SetFilePointer(), ReadFile() and WriteFile(). My concern is
> SetFilePointer, it uses a bit shift on a 32 bit number (file
> position) to get a high order 32bit number for the
> lpDistanceToMoveHigh parameter. It is possible this is where the
> problem is, but as yet I am unsure.
Actually, the file positions are 64 bits, because the same code is also
used to support 20GB hard drives.
> I havn't yet, as OS-9 is a OS that is moduler and can place modules
> anywhere in memory. Although the bootfile is contiguous in memory,
> finding RBF in that memory is a chore.
Yeah it is a chore. If you have added debugging code to coco_vhd.c, you
can add calls to activecpu_get_pc() to obtain the contents of the PC
register when those calls are made.
More information about the Coco
mailing list