[Coco] Nitros9 & Mess

[Bill Nobel]

>From: Nathan Woods <npwoods at cybercom.net>
>Reply-To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>Subject: Re: [Coco] Nitros9 & Mess
>Date: Mon, 02 Feb 2004 14:25:24 -0500
>
>
>Do you base this conclusion on the fact that RAM drives have no problem?  
>Or is there more to it?
>

  I have tried endlessly to generate the error on ram drives, no errors.  
Ram drives also use RBF as drives do, the difference is Ram drives do not 
use Mess's virtual drive code, they just use memory copies.  Which proves to 
me that RBF is not the problem.

>When I was debugging through NitrOS-9, I found that the orders to write 
>invalid data into the sectors camefrom RBF, and cc3disk and the below 
>layers in MESS seemed to be faithfully carrying out that order.  It is also 
>possible that the true bug is elsewhere, and somehow it causes RBF to write 
>the invalid data.  On the other hand, I have no explaination as to why the 
>RAM drives do not have the problem.
>

  In my case study here,  I have found RBF to be issuing the commands 
correctly and normally.

>>* 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.

>>* read empty directory sector
>>* This should be all 00's on a freshly formatted disk
>>* Doing a check with a windows file editor, it is all 00's before 
>>occurance
>>vhd seek: 0000B7 0000B700
>>read dump: 00FD00
>>2E AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B5
>>AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B5
>>E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BD
>>....(extra cut)
>>
>>* update and write directory entry (from this point the directory is now 
>>trashed)
>>vhd seek: 0000B7 0000B700
>>write dump: 00FD00
>>E7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C3
>>AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B5
>>E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BD
>>....(extra cut)
>

  These dumps are when RBF writes out the new directory expanded sector.  
The read sector seek to LSN $0000B7 is correct to RBF's request.  The actual 
data read from the VHD is _NOT_ correct, the sector should be filled with 
$00's, hence the write sector puts the wrong data onto the sector @ $0000B7.

  The given dumps are from debug code I added into coco_vhd.c on all 
transactions to disk.

>
>I do not think that the bug exists in windows/fileio.c, simply because 
>these functions are very low level and are shared by all of the other MESS 
>and MAME drivers.  Not only does RS-DOS not have problems, but earlier 
>NitrOS-9 versions do not have problems either.
>
>When I was working on this four months ago, I noticed that RBF (when run 
>under MESS) was issuing the orders to mangle the appropriate sectors, and 
>MESS was simply faithfully executing these orders.  Obviously at some level 
>this must be a bug in the emulation for the simple reason that the same 
>code works just dandy on a real CoCo.

  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.

>Have you tried using the MESS debugger to debug the emulated CoCo and 
>stepped through RBF to try to observe this?
>

  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.

>Another approach would be do test this against a VHD (so you can bypass all 
>of the ugly FDC crud) and hack in debugging code into devices/coco_vhd.c.  
>This should show that the invalid writes seem to originate from the 
>emulated CoCo.

  Already in process,  I am trying to bypass all of Mame code and directly 
access the file without Mame's buffering.  I also have a hunch it could be 
in Mames buffering code, but it's unproven yet.

-Bill

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail  
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca