Rollback broken data problem with an error rate format.

[SuperTurboZ]

The cause of the problem in the previously posted SMC-70/777. SMC-70 / 777 drives FDC at 2.0139875MHz and has a data rate of 503.496875kbps. When a 500.0Kbps .HFE image is mounted and formatted, the data pointer is adjusted and advances faster than actual. So the ID of last sector is written later than the actual. Then when writing the data block of the last sector, overwrite the first ID and destroy it.

It is a problem of image data rate and an emulate limitations. There seems to be no problem with the correct data rate image. However, I think this is a difficult problem to find the cause.

[keirf]

Yes you have indeed put your finger on a weakness in HFE write handling :) This is particularly an issue for index-to-index writes (ie. the type most systems generate when formatting a track).

The issue is that the INDEX is generated according to the data-rate and length of the track (as specified in the HFE image), whereas if the host writes a bit faster or slower, he ought to hit the INDEX correspondingly sooner or later.

Here are some possible fixes and improvements. Let me know what you think.

1. Generate HFE images that better match the host data rate. For example:

   python scripts/mk_hfe.py --rate=504

2. I actually already anticipate this problem and log it. If you run the logfile alternative firmware, attempt a format, then eject the image, then pull the USB stick, you should find messages like Wrapped (200 > 2) in FFLOG.TXT. Instead of warning, we could actually truncate the write. Would you like to test that if I implement it?

3. The gold-plated morally-correct fix is to sync generation of INDEX pulse to the host's write progress (ie. position of its data pointer and its rate of advancement). Since FlashFloppy buffers writes this is potentially a bit hard.... So option 2 above is probably better (perhaps disabled for certain machines which rarely care about INDEX, like Commodore Amiga).

[SuperTurboZ]

Basically, the image should match the host data rate. So there is no problem with INDEX to INDEX write. I think that would be enough if it could output a write bit rate mismatch error to the log and screen.

BTW, many Japanese 8-bit PCs game software use the difference bit rate sectors for copy protection. And some copy tools reduce RPM and write a little higher bit rate to write it. Inserted folding paper increases media friction and reduces rotation speed.

I don't know how to make an HFE V3 image with the correct bit rate information embedded from the media yet. The write emulation of FlashFloppy doesn't support dynamic bit rate adjustment, but I think full HFE V3 support is difficult because it's VBR. So,is that possible by converting Kryoflux stream to HFE V3?

[Volutar]

It's not that hard to hexedit existing image, to make F-F firmware move virtual head not that far from expected position, considering drifted timings. The offset is 0x0b-0x0c. But the specs say max value is 500kb/s. But from the F-F code I see no clamp values, so you can change 0x01f4 to 0x01f7.

I don't think that HFEv3 is necessary in this case. VBR of HFEv3 is mostly the "feature in advance", and not used that "dynamic" way along the track.

[SuperTurboZ]

Static bit rate error does not require HFE V3. But , rotational speed protection requires it.

Some differential bit rate copy protections compare the time difference from the first byte to the last byte of a sector block for different sectors in a track. Therefore, it is necessary to change the bit rate for each sector in the track. Since those tracks are not overwritten, it can be handled by pre-generating images.

The issue is that I don't know the process of creating images from real media with accurate bit rate information. Even if GOTEK-FlashFloppy is connected to the destination of the duplicating machine, it cannot be generated. It is another issue outside FlashFloppy.

The problem with SMC-777 has been resolved. Thank you.

[keirf]

I am happy to close this ticket unless anyone wishes to pursue the truncate-on-wraparound approach to sidestepping this issue?