[Coco] Re: MESS mouse and keyboard question

Gene Heskett gene.heskett at verizon.net
Wed Oct 29 23:58:00 EST 2003


On Wednesday 29 October 2003 19:50, Nathan Woods wrote:
>> Yes, I believe I've seen this. Most, but not everytime,I try to
>> move a
>>
>> file from a virtual floppy to another floppy or the virtual HD, I
>> get error 242 (write protection), however the file does show up,
>> albeit messed up (Ident reports bad CRC.) Sometimes if you delete
>> the 'bad'
>
>file
>
>> and retry the copy procedure it works. My guess is that the
>> problem resides with the RBF module, because if I try copying from
>> the ramdisk
>
>to
>
>> the harddisk I have the same errors. As far as I know CC3disk has
>
>nothing
>
>> to do with the ramdisk or the harddisk.
>
>Robert and I came to a similar conclusion.  I've run more traces
> than I can count and the orders to corrupt the sector definitely
> appear to be issued by the RBF module.  Apparently, somehow these
> corruptions occur because a sector gets written to but is somehow
> incorrectly cached and subsequently written to the disk.
>
>> I'll try grabbing an older version of Nitros and see if it goes
>> away.
>
>From what I understand, older versions of NitrOS do not have this
>problem.  I'm inclined to believe that the best way to solve the
> problem would be to track down exactly what change created the bug.
>
>I do have to say that it seems very odd to me that the RBF module
> would cause the bug.  For the most part MESS emulation bugs tend to
> be hardware oriented; in other words they are things like "the
> timing for XYZ is off by a few microseconds", or "IO address $FFxx
> is not working correctly".  RBF doesn't appear to do anything like
> this directly.  At one point, I suspected that it could be a 6309
> specific bug, just because that code is less time tested then the
> 6809 core (which is used by 400+ MAME emulations).  That idea got
> nixed when Robert repro'd the bug in NitrOS-9 6809.  I guess time
> will tell.

Humm, I never saw this bug in the versions I worked on years ago.  
AFAIK, the last real bug was a feature I'd built in for BackAR, which 
turned into a cast iron bitch if the segment table in a file 
descriptor sector got full.  The last release of rbf.mn from me was a 
fixed version that removed the segment list full bug.

I do not know what the edition number is for the version that Boisy 
merged up from my 6309 code and the 6809 equ code, which was then 
built for one or the other by switching a conditional variable.  I 
started it, but frankly got lost as it had been too many years since 
I'd walked around in that code, but from what I've been told, the 
finished code assembled to the same length and crc for each original 
version.  That was about a year ago, but I've no recent history 
since, so I don't know if any "new" features have been added since.

I did have at one time a situation where a fat sector would be read 
from the disk and come back as all zero's.  That of course played 
seventy kinds of hell with the filesystem, but that was hardware, a 
very early B&B hard drive interface.  Without changeing anything 
else, that problem totally went away when a scsi drive and a disto 
4n1 replaced the old B&B.

-- 
Cheers, Gene
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.




More information about the Coco mailing list