[Coco] Re: NitrOS9 on MESS?

[Gene Heskett]

On Thursday 04 December 2003 19:55, Robert Gault wrote:
>Nathan Woods wrote:
>> Roger Taylor writes:
>>> At least you know that it's occuring while RBF is writing out to
>>> a storage device.  So if this does not happen on a real CoCo, and
>>> the code is  exactly the same, then it's M.E.S.S... probably a
>>> timing issue or the index hole signal code.  ??
>>
>> Truthfully, I do not know.  This particular bug defied almost all
>> of my assumptions.  At first, I assumed that it was either a FDC
>> timing bug or a 6309 core bug.  However in my investigations, it
>> seems that the orders to write to the bad sector come from outside
>> cc3disk.  The fact that the bug occurs when used with a VHD - thus
>> bypassing cc3disk - confirms this observation.  Since this bug
>> also occurs with NitrOS-9 6809, the 6309 core is not to blame.
>> Generally any bug that appears in MESS but not the real hardware
>> is by definition, a MESS bug.  Probably the only bugs for which
>> this is not the case is if some CoCo code was relying on something
>> totally whacked out, such as reading from undefined IO memory or
>> the contents of memory when power is turned on.  I'm inclined to
>> believe that the latter is not the case.  It could be a timing
>> bug, but what kind of timing bug would cause this bug.  As for
>> "index hole signal code", can you elaborate on what that is?
>
>The controller reports the passing of the floppy disk index hole
> past the drive detector as a bit in Status for type I commands. It
> also would be used by the Western Digital controller to synchronize
> read/writes in some fashion.
>
>The only time this info was used in Coco code was in programs that
>tested drive rotational speed. So, it would be invisible to Disk
> Basic or OS-9.

Humm...  Thats a roundabout way of saying that sector 1 is not the 
next sector under the heads after the index pulse.

I'd almost argue that non-use thing because I once had a dyson floppy 
disk calibration disk that, among other things, measured the timing 
from the index pulse to the first sector.  I'd borrowed it from a 
friend because I was having weird problems with one of my first ever 
floppy drives.  I figured the drive was out of track zero alignment, 
but that checked spot on.  The next test on that disk was for index 
timing, and it was way short according to the test.  So I broke the 
glue holding the photocell, and moved it as far as I could in the 
direction that should have fixed it, but overshot it.  Moving it very 
slowly I finally got that program happy.  It turned out to be a very 
critical adjustment.  So was the drive(happy).  Now if the index 
pulse doesn't count, the track could start and stop at any location 
on the disk and my adjustment wouldn't have been required, or made 
any difference.

I only know of one drive and driver that ignores the index pulse, and 
thats all 68k based amigas ever built, because they do read, and 
write, a whole track at a time with no regard to the index pulse.  It 
reads the whole track and a bit more into a buffer, and searches the 
buffer for the right "sector" address. 

>It might be an issue with the MESS emulation of the controller. It
> would be most likely to show up in NitrOS-9 operations because of
> tighter timing during disk I/O. However, the bug in question does
> not depend on the floppy controller and is also present in .vhd
> use.

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