[Coco] Re: MESS mouse and keyboard question

[Gene Heskett]

On Thursday 30 October 2003 01:20, Robert Gault wrote:
>The 6309 rbf has the following stats:
>ed $23
>size $1267
>crc $AF8A8D

I believe that one is clean.  If indeed we've found a new bug, let me 
say that I used that one, and the FD.SEG busted one for several 
years.  I used the dmode call that expanded the minimum size to open 
a new file to either $80 or $FF, (SAS=80 etc IIRC) which prevented 
the FD.SEG bug from attacking my own system.  Except once :(

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

The Tandy distro'd modules as issued almost worked, but KD's Christmas 
present broke the ability to use clusters unequal to 1 which was the 
reason I dug into it in the first place.  I spent several months 
dissing the by then several versions extant and comparing operations 
and ended up restoring some of the original code KD took out.  There 
is one hard coded def in it, a define that couldn't be found in any 
rbf.def or os9def file I've come across.  A very carefull read of the 
brown book (Inside os9) gave me enough info to figure out how to fix 
it, but never did give me a name for that definition.  The assembly 
sources out and about that came from me have rather liberal comments 
in that fix area.  Without that code, using multiple sector clusters 
works, except for deleting files, it doesn't free all of that files 
allocated space, so you soon wind up with a full disk on an active 
system.

Let me know if and when you find this one, please.

>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

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