keirf / greaseweazle

Tools for accessing a floppy drive at the raw flux level
The Unlicense
984 stars 98 forks source link

HFE output is hardcoded to double density #36

Closed Octoate closed 4 years ago

Octoate commented 4 years ago

Hi, I just build the Greaseweazel board and used an adapter board for this. Flashing the software was no problem and the device gets recognized on my Windows 10 system. I also can read and write disks with the software, but reading does not work. To test the device, I used the DSKA0000.hfe from the HxC floppy emulator software and wrote it to a 3.5" disk. After that, I checked that the disk is readable with an USB floppy drive and it works fine. However, when I read it back, the HFE file is not readable in the HxC floppy emulator software. Also writing it back to a 3.5" disk and testing it with the USB drive does not work. I used the simple command "gw.exe read test.hfe" to read the disk on my system. Do you have any ideas or a hint for my what might cause the problem? I have attached the hfe file that I read back on my system (it should contain the DSKA0000.hfe content). testhfe.zip

keirf commented 4 years ago

GW tool is not switching to HD rate to decode the flux and write the HFE. It's actually hardcoded at double density. I will work out a way to let you specify HD on the command line, and also add some sanity checking or auto-detection for the usual case that it is pretty easy to distinguish DD from HD (number of flux samples per track is usually enough!) Thanks!

Octoate commented 4 years ago

Hi, great, thanks a lot for your fast reply and of course for your work on the Greaseweazle :-)! Can't wait to test it.

keirf commented 4 years ago

Latest v0.18 release fixes this. Specify --rate 500 on the gw read command line to create a HD HFE image file.

keirf commented 4 years ago

Let me know how you get on!

d235j commented 4 years ago

@keirf would it be better to have a way of converting scp to HFE? An issue with the HFE approach to imaging is that it can't represent fluctuating bitrates well — that would require lots and lots of bitrate-change opcodes, or imaging at a bitrate a few orders of magnitude higher than the disk's bitcell width. Some Apple II software uses copy protection that depends on such fluctuations.

M1kerochip commented 4 years ago

Just to chime in: --rate 500 produces a hd .hfe for me, but HxC Floppy Emulator doesn't show any of the files on the disk in the disk browser, and the Track format: says UNKNOWN_ENCODING. (I also tried --rate 512, same result)

Disk was a brand new sealed floppy (driver disk), opened to try this out! The disk I used reads fine in a standard PC drive, and an external PC usb drive.

The drive on the GW is an Alps DF334. I can test on another disk drive, if needed.

3.zip

keirf commented 4 years ago

@d235j I will implement transcoding in future so you can convert between image formats with no physical disk access involved. I will also implement a sensible flux format for storing incremental disk dumps, and provide tools for transcoding that too.

keirf commented 4 years ago

@M1kerochip A failed test, how sad. I will have a look. It did work for me earlier today!

keirf commented 4 years ago

If you rip to SCP does that look OK in hxc?

M1kerochip commented 4 years ago

The HD disk? No. Same. Shows up as a blank 1.39mb disk. 0kb used. Unknown encoding format.

If you explore the tracks, it's showing data in there. I can see some filenames etc. It's just not recognised.

keirf commented 4 years ago

The problem isn't directly related to the new --rate option then. Try another drive and/or upload the bad scp somewhere.

M1kerochip commented 4 years ago

Same result, but a bit better. At least this drive picked it up as ISOIBM_MFM_ENCODING.

https://mega.nz/file/EWI0mSzK#TOTxhjcXYzLXEKG1L5WWHqI1tiZwbouLV-HtTwc0hHU

Using different drive, hxc reports:

Track RPM : 300 RPM Bitrate : VARIABLE Track format : ISOIBM_MFM_ENCODING Track len : 199450 cells Number of side : 2 Interface mode: GENERIC_SHUGART_DD_FLOPPYMODE Shugart Interface

keirf commented 4 years ago

I just looked at your SCP and it is perfect? All sectors are there. So presumably something was up with the previous drive you used.

M1kerochip commented 4 years ago

Yeah, maybe! Maybe it was just having a bad day :)

HxC still can't see any of the files on the disk though, using the disk browser. (That's what I usually use to check an IBM image is ok)

keirf commented 4 years ago

There are a couple of extra sectors at cylinder 80, which might have confused the browser. If I decode cyls 0-79 only, I see a FAT12 FS, but the filenames are garbage. Maybe this is not a standard FAT-formatted disk? All I can say is the sectors are okay as they are CRC validated. So there's nothing wrong with the dump.

M1kerochip commented 4 years ago

Fair enough.

I've dumped 3 more disks, all the same. Each disk reads fine in a older normal PC drive connected to a PC under windows, and a usb drive on my main PC, none show in HxC browser. (And all files can be copied off, etc, fine)

I'll try writing that disk image back to a blank, and see if it's picked up ok in windows.

And I'll try a new read and write ending on track 80.

keirf commented 4 years ago

Sure. Make another one available for download and tell me what files you expect to see on it.

keirf commented 4 years ago

Oh hang on, I see the problem. You are reading side 0 twice! So either this drive is bad too, or you have a bad cable or something, such that the side-select signal is being ignored.

When you view the SCP in HxC 'Track Analyzer' note that sector header contains 'H:0' for all sectors on side 1. In fact side 1 is just a re-dump of side 0!

M1kerochip commented 4 years ago

Ah! Excellent.

Yup, that was the problem. There must be something up with my cable.

keirf commented 4 years ago

Ok, I think this ticket is done.