[Coco] Re: MESS mouse and keyboard question

[Robert Gault]

The 6309 rbf has the following stats:
ed $23
size $1267
crc $AF8A8D

This should be the one to match as the 6809 versions tend to be backports and
won't match Tandy modules.

Gene Heskett wrote:
> 
> 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.
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco