[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 10:57:40 -0500
>
>Bill Nobel wrote:
>
>>I also discovered on a reset the FIRQ lines aren't reset to null as they 
>>should be, the code resets IRQ twice.  I don't think this is a problem but 
>>it should be addressed.
>
>Can you elaborate on this?  To my knowledge, the call to pia_reset() in
>generic_init_machine() should invoke the callbacks that reset both FIRQ
>and IRQ.
>
>
  This is a mistake on my part.  I didn't have the code fully deciphered in 
my head as to the flow of Mess's functionality.  I read the code further and 
discovered that it is NOT a mistake.

  Through much debugging though I have discovered that the error is not RBF 
in any way.  I have tested it fully on all RBF devices and found that the 
bug only exists in the virtual drive system (DSK and VHD devices).  The Ram 
drives do not have this problem.  I have tried to make the ram drive fail, 
but to no avail.

I have traced each of these routines to find that these sources have the 
file handling routines:

  formats/coco_dsk.c               DSK (No trace of these functions being 
used)
  devices/basicdsk.c                 DSK handling (virtual only)
  devices/coco_vhd.c               VHD handling
  src/fileio.c                            Mame file handling (DSK and VHD 
calls come here)
  src/windows/fileio.c               Base OS file handling (called from 
above)

Below you can see the error in action.  I started with a blank VHD and built 
6 zero length files, all is fine.  on the 7th build it needs to expand the 
directory to another sector and this is what happens:

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

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

  The only place I can see the bug existing (if any) is the 
windows/fileio.c, as basicdsk.c and coco_vhd.c just pass the parameters down 
the tree to these functions: osd_fseek(), osd_fread() and osd_fwrite().  
These functions manipulate the buffer/file to update files.

  Now the bad news,  RS-DOS uses these same routines for disk access.  
RS-DOS has to my knowledge no problems.

-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