Home Page Forums MAME MAME Disk image oddity.

Hi all,

I'm experiencing strange behavior with raw disk images with the RM nimbus driver. Through a process of illimination I think I've ruled out the actual nimbus driver code.

What I'm getting is infrequent, though pridictable CRC errors reading sectors from the floppy image.

So I can replicate as follows :

insert a raw disk image into a floppy drive (I'm using B: as then the machine won't try and boot from it!), this image is 737280 bytes 80 double sided tracks of 9 x 512 byte sectors.
Having booted from the hard disk do the following :

copy c:\dos\*.* b:\

This will copy the files *UNTIL* it gets to copying print.exe where it will error out.

Tracing this error from dos, back through the Nimbus's sub-bios, back to the WD1793, it's reporting a CRC error reading the sector data.

Now this is a mystery, because if I understand correctly the image / floppy emulation code must be faking this data up because it doesn't exist in the image.
So the floppy emulation must be reading the raw 512 byte sector data from the image file and building header info / crc data for it.

The other odd thing is if I eject the image using the mame menu, and then re-insert it into the same drive and copy c:\dos\print.exe b:\ it succeeds.
This suggests maybe that something is not getting re-initialized where it should and that the eject/insert cycle rectifys this.

Does anyone have any thoughts on this or where I should go looking for the error? I've done a troll of the crc code in wd_fdc.cpp and compared it to the upd765.cpp code and
the two seem mostly consistent.

Cheers.

Phill.

I tried to format a disk to repo this and got a crc error after the format so I made a mfm image instead which preserves the crcs and here's the result.

The data crc is 0xc03e when it should be 0xc026.

Writing is broken somehow. The last raw mfm value it tries to write is 0xa494.



But the file ends up with 0xa554



https://github.com/mamedev/mame/blob/master/src/devices/machine/wd_fdc.cpp#L2148 looks a bit suspicious. The datasheet says there should be a bunch of 0x4e written but it's only doing one 0xff and that doesn't appear to happen.

I did try replacing that with a single 0x4e, but that didn't appear to fix it. Maybe the if (cur_live.byte_counter < sector_size + 16+3) needs the +3 increasing.....

Cheers.

Phill.

What might be happening is the dma is finished and then the machine does a wd_fdc interrupt command which halts the write before it's done.

I wondered about that too, I did try playing with the delays but again couldn't get that to work

It could of course be that the emulated floppy code is taking slightly longer to execute than on the real hardware, and the forced interrupt is causing the problem.

Cheers.

Phill.

Not sure what you looked at, but the "write sector sequence" graph ends with "write one byte of 0xff" after the data crc.

That interrupt thing otoh, that's probably the cause right there. Annoyingly, I don't know what the wd actually does in that situation.

The emulated floppy code tries to work in real time, following the simulated physical rotation of the floppy. So that part of the timing should be correct.

Ok after some further studying of the RM technical manual and the schematic for the floppy controller, I found that the controller is actually operted at 2MHz, with ENMF grounded.

However implementing the changes on my local copy of the source and I still get the same result with the CRC errors.

Cheers.

Phill.

Aggreed, it's not clear from the datasheet, especially as it's using the write multiple sectors command which according to the datasheet will keep
polling for data until it gets a force interrupt. This would imply to me that any complete sectors it has up until this point should be written, before
acting on the interrupt.

cheers.

Phill.