[Coco] MAME FDC Issue that can cause corruption

[David Ladd]

Allen,

Sadly this issue is not limited to Disk Basic as I found this problem to
start with when I was using two drives in NitrOS-9 and OS-9 L2.

I spent many hours of testing and the problem never showed up till version
0.163 of MAME when new code base for WD FDC code was being used.

This is also how I corrupted my Cave Walker disk as I was doing stuff on
drive 0 that was reading and writing on drive 0 at the same time I was on
VDG screen on drive 1 loading Cave Walker when system crashed hard.

And thus this is a real issue. Especially if it causes a risk for disk
corruption if the emulation isn't switching to the correct image to write
the data.

+-----------------------------------------------------------------------+
| David Ladd a.k.a. PacoOtaktay a.k.a. Drencor                          |
| YouTube: http://www.youtube.com/user/PacoOtaktay                      |
| YouTube Gaming Live: https://gaming.youtube.com/user/PacoOtaktay/live |
| Websites: http://dwladd.com     &     http://www.theterrorzone.com    |
| G+:  https://plus.google.com/113262444659438038657                    |
| G+:  https://plus.google.com/+DavidLaddPacoOtaktay                    |
|                                                                       |
| Do you have your CoCo 3 yet?                                          |
+-----------------------------------------------------------------------+


On Wed, Aug 2, 2017 at 8:20 AM, Allen Huffman <alsplace at pobox.com> wrote:

> > On Aug 2, 2017, at 3:31 AM, Ciaran Anscomb <cocomalt at 6809.org.uk> wrote:
> >
> > So what's the behaviour of real drives?  Is there really a delay before
> > the ready signal is updated on switching drives?
>
> This reminds me of an issue with the old Mac Virtual PC from Connectix
> (before Microsoft bought them). The floppy driver worked fine for DOS, but
> wouldn't boot OS-9000. I worked for Microware at the time, and somehow got
> in touch with a lead engineer there (I don't think it was Microsoft yet,
> but maybe it was).
>
> There was some status bit OS-9000 was reading and using which the emulator
> did not implement because DOS did not use it. Microware coded to spec,
> while the emulator coded to usage.
>
> I send them a boot disk with the "ROM" debugger available and they were
> able to figure this out and fix it.
>
> I wonder now if RS-DOS isn't the "DOS" in this MAME example and the MAME
> contributors are the "Microware" (coding to spec).
>
>                 -- A
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>