x86 Bridgeboard problems writing to floppy

[superfrog]

Hi Toni,



I've been having a lot of different issues when trying to write to floppy disk images from x86 PC emulation with the Bridgeboards. In general, floppy writing seems to be more reliable using WinUAE 4.0.1 and earlier. In versions 4.1.0 and later (after the switch to PCem core) writing to floppy seems almost totally broken.


Reading from floppy seems to always work; I've had no problems at all reading floppies (except those written to by Bridgeboard.)



The problems vary with different combinations of disk formats (low/high density, size) and Bridgeboard model. Sometimes the format command reports a high number of bad sectors. Other times the disk files or FAT become corrupted after writing files to the disk from DOS. Other times WinUAE completely locks up altogether when attempting to write to floppy, and I have to kill it from the Task Manager (especially when writing to low-density image in high-density drive.)



Have you (or anyone else) noticed these kinds of issues with writing to floppies from PC side before?


If you want more details, I can provide a rundown of which specific configs lead to what problems, and provide my test configs, etc. But I wanted to check and see if you are already aware of these problems first.


Thanks as always!

[Toni Wilen]

I don't think anyone has written to floppies much..

Try to make it lock up, open task manager but don't kill it, select "create dump file" and compress (7zip preferably, it usually compresses extremely well) and upload it somewhere. Make sure both Amiga and PC side memory settings are low to keep dump file small. (don't use winuae.7z, it must be official final or beta)

[Toni Wilen]

Dump file can be removed now, it helped a bit

Does http://www.winuae.net/files/b/winuae.7z fix it? (or at least fix the hang). There was no check for disk write no more data DMA condition. (Disk read checked it)

[superfrog]

I'll give it a shot and get back to you. The particular condition that caused the crash in this case was attempting to write files to a 360K or 720K disk in a high-density drive on an A2286. Writing to a 1.2M disk also failed the same way. Only writing to a 1.44M disk didn't crash (but still corrupted the image.)

[superfrog]

Writing to all sizes/formats in DOS 6.22 with A2286 seems to work now. I'll test the other BB models and let you know results soon...

[superfrog]

Okay, no more emulator crashes! I tested all 4 BB models (but not the Sidecar), and all drive/disk sizes/densities.

There are still a couple of issues though, and they appear to have existed in versions 4.0.1 and earlier. So it looks like your most recent fix addressed the new issues that were introduced in version 4.1.0.

The first issue affects 360K drive/images only, with A2088 and A2088T. To reproduce, format a "blank" disk, then run scandisk on it. Scandisk will report 2 errors in the FAT: missing media byte, and incorrect backup copy (see attached screenshots.)

If you tell Scandisk to fix these errors, the disk can be used normally and seems to have no further issues; any existing data on the disk is preserved, and future writes don't seem to lead to more errors.

The second issue is that all disk types, when formatted on A2386SX, yield an extremely high number of bad sectors (see third screenshot.)

[superfrog]

I've uploaded my test configs and HDFs for floppy testing to The Zone:

http://eab.abime.net/zone/x86%20brid...ppy%20tests.7z

It pretty much provides a single-click turnkey solution for testing all the various BB models and floppy drive/image types. Hope this helps!

[superfrog]

Oh, one more issue:

On A2088, A2088T, and A2386SX, with 2 floppy drives attached, all track stepper activity on Drive B: is mirrored on Drive A:. So for example, if you format disk in Drive B:, drive A: will step through tracks 0-79 in sequence while Drive B: is doing same. A2286 doesn't seem to do this.

[Toni Wilen]

Some of these need real hardware test, for example I can't see how floppy controller emulation can modify single byte (FAT error). It sounds like (yet another) bridgeboard bios weirdness.

A2386SX: redownload winuae.7z, format disk and attach log. It should contain lots of floppy related messages. It is also possible this is not fixable, format command gets floppy "geometry" related bytes that can't be stored in normal floppy images. EDIT: I assume all normal disk writes do work?

EDIT: too lazy to do this test yet..

[superfrog]

Ok, here's the log output after I formatted a 1.44M disk.

[Toni Wilen]

Thanks. All format parameters look normal but I found one bug in returned status (wrong end sector count).

Probably makes no difference but you never know without testing. Please test (and make sure winuae.exe date has changed, sometimes cached version is returned if it was already updated recently).

[superfrog]

Still same result with new binary. I've attached an updated log, if that helps any.

[superfrog]

Regarding normal disk writes on A2386SX, all data copied to floppy, regardless of size/format, gets severely corrupted. Only very small files (<1k) get copied intact. All other BB models copy data with integrity using all floppy formats (I verified using FC utility.)

Also, A2386SX does not read 1.2M 5.25" disk images at all. Attempting to gets "Sector not found error" This behavior goes back to WinUAE versions 4.0.1 and earlier.

[superfrog]

Also, regarding the 360K disk FAT media byte and secondary FAT copy issue reported by Scandisk, I've pegged this as a disk reading issue, not a writing issue. It has nothing to do with the disk format process.

On any BB with a 40-track 5.25" drive, Scandisk will report the FAT issues even on disk images that were formatted completely outside of WinUAE. On A2286 and A2386SX, Scandisk will report errors if the drive is 40-track, but scanning same disk in 80-track drive produces no errors.

[Toni Wilen]

This is quite strange problem. PC floppy access is relatively simple (vs Amiga), you tell the controller what to do, then it does it and returns status information. You can't do any kind of raw low level access.

One possible test is to format image with confirmed working program. (for example PC0: in Amiga side). Make copy of it. Copy one large enough file using A2386SX and A2286, using exact same DOS version and then compare differences in image files.

[superfrog]

Okay, here are two disk images. They started out as identical blank, formatted floppies. One had a small file copied to it on the A2286 and the other by the A2386SX. The results reveal that the A2386SX is not corrupting file data, it just isn't writing any file data at all.

The blank newly-formatted disk is made up of almost entirely F6 bytes. As you can see in the screenshot I took from a hex editor after running a comparison between the two files, the segment of the file that contains actual data on the image written by the A2286 is still completely unmodified on the A2386SX image.

Curiously, however, the copy operation does correctly update the FAT on the A2386SX, as the file is visible in the directory listing with the correct size and time stamp information, and it passes a Scandisk check.

[Toni Wilen]

Thanks, now I understand the problem. I thought it was format command but it was actually both read and write problem if MT ("Multitrack", can read both sides using same command) bit was not set. Previous bridgeboard variants BIOS always set MT bit but A2386SX only sets it when needed.

A2386SX formatting and writing works now. Please confirm that I didn't break anything else. A2286 and older uses Faraday chip which apparently implements most PC features, A2386SX uses actual WD37C65 FDC chip.

[superfrog]

Excellent!

Floppy formatting and writing on A2386SX now seems to work perfectly, and nothing seems broken that wasn't before.

Only 3 minor things are still broken:

1. On 40-track 5.25" (360K) drive, Scandisk still reports incorrect FAT media byte and mismatched 2nd FAT copy (see posts #6 and #14 in this thread for further details.) This does not seem to affect usability or reliability of disk in any way. Telling Scandisk to fix these problems makes them go away, but there does not seem to be any problem if they are ignored. As noted in post #14, this seems to be a reading issue, as disks formatted outside WinUAE still report the error when scanned in WinUAE.

2. Cannot read 1.2M 5.25" disk images on A2386SX. Always returns "Sector not found" error. You can format a blank 1.2M image on A2386SX and copy some data to it, and FC verifies data copied ok. If you eject the image, then re-insert it, read will fail. But if you read this same image on A2286, it works fine.

3. On A2088T only, Drive B: does not detect disk changes properly. If you insert an image, list its directory, then eject and insert a different image, the same files from the first image are listed if you try to list the directory of the second image. If you eject the first image, then attempt to read from the empty drive B: (or drive A: ), and then insert a second image, it will read the directory from the second image correctly. This happens with both 360K and 720K drives attached as Drive B:.

I think (and hope) that's it for Bridgeboard floppy issues. Thanks for all your help so far in squashing the bugs from this part of the BB emulation!

[Toni Wilen]

I'll leave remaining issues for later updates because density checks are not as simple as in normal PCs because of floppy switcher hardware which is custom bridgeboard specific and partially unknown.

[superfrog]

Ok no problem, the remaining issues are pretty minor, can be easily worked around, and most importantly, don't cause loss of data. Thanks for fixing the big ones!