Previous Thread
Next Thread
Print Thread
Page 1 of 2 1 2
#119884 10/21/21 01:10 PM
Joined: Nov 2003
Posts: 186
Likes: 1
P
PhillHS Offline OP
Senior Member
OP Offline
Senior Member
P
Joined: Nov 2003
Posts: 186
Likes: 1
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.

1 member likes this: exidyboy
Joined: Jan 2012
Posts: 881
Likes: 10
C
Senior Member
Offline
Senior Member
C
Joined: Jan 2012
Posts: 881
Likes: 10
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.
[Linked Image from i.imgur.com]
The data crc is 0xc03e when it should be 0xc026.

Last edited by crazyc; 10/21/21 04:54 PM.
1 member likes this: exidyboy
Joined: Jan 2012
Posts: 881
Likes: 10
C
Senior Member
Offline
Senior Member
C
Joined: Jan 2012
Posts: 881
Likes: 10
Writing is broken somehow. The last raw mfm value it tries to write is 0xa494.

[Linked Image from i.imgur.com]

But the file ends up with 0xa554

[Linked Image from i.imgur.com]

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.

Last edited by crazyc; 10/21/21 08:01 PM.
Joined: Nov 2003
Posts: 186
Likes: 1
P
PhillHS Offline OP
Senior Member
OP Offline
Senior Member
P
Joined: Nov 2003
Posts: 186
Likes: 1
Originally Posted by crazyc
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.

Joined: Jan 2012
Posts: 881
Likes: 10
C
Senior Member
Offline
Senior Member
C
Joined: Jan 2012
Posts: 881
Likes: 10
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.
[Linked Image from i.imgur.com]

Last edited by crazyc; 10/21/21 09:58 PM.
Joined: Nov 2003
Posts: 186
Likes: 1
P
PhillHS Offline OP
Senior Member
OP Offline
Senior Member
P
Joined: Nov 2003
Posts: 186
Likes: 1
I wondered about that too, I did try playing with the delays but again couldn't get that to work frown

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.

Joined: Jun 2001
Posts: 484
Likes: 4
O
Senior Member
Online Content
Senior Member
O
Joined: Jun 2001
Posts: 484
Likes: 4
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.

Joined: Jun 2001
Posts: 484
Likes: 4
O
Senior Member
Online Content
Senior Member
O
Joined: Jun 2001
Posts: 484
Likes: 4
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.

Joined: Nov 2003
Posts: 186
Likes: 1
P
PhillHS Offline OP
Senior Member
OP Offline
Senior Member
P
Joined: Nov 2003
Posts: 186
Likes: 1
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.

Joined: Nov 2003
Posts: 186
Likes: 1
P
PhillHS Offline OP
Senior Member
OP Offline
Senior Member
P
Joined: Nov 2003
Posts: 186
Likes: 1
Originally Posted by Olivier Galibert
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.

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.

Page 1 of 2 1 2

Link Copied to Clipboard
Who's Online Now
2 members (Vas Crabb, Olivier Galibert), 22 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,131
Posts119,647
Members5,029
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com