Understanding the differences

[Zalorpas]

Hello all,

I have an arcade system that is using a FDD to store the games. The original FDD is an old Mitsumi D357.
When I am reading the disk with this drive (using Greaseweazle) I am able to read the whole disk (good dump).

In the oposite sense, if I am doing the same with another FDD, a Samsung SFD-321B, then I am not able to get data of the track 58.1 (hopefully I have flux)

This issue is just happening with this disk and this track... I tested +10 disks and everything seems to be ok with the others.

I analysed both reads with HxC and it seems that there is a delay of 1us between both dumps and I am wondering if there is any way to edit the RAW to reduce the gap of 1us to get the data or even, if there is any workaround to force the read (like in the original drive)

For the sake of the preservation, it is very important to have a workaround with another FDD, as we only have one Mitsumi drive to read disks (the other original FDD died), and we need alternatives to keep it working.

I add two snapshots to show how it looks like.
I'll really appreciate any feedback

Thank you very much for your support.

[Jeff]

Please show the stream views (with "fat" pixels) instead.

[Zalorpas]

Attached you can find the requested files.

Thanks for your support

[Jeff]

Attached you can find the requested files.

Thanks for your support

it seems you are reading this 360 RPM HD disk with a 300 RPM drive in DD mode. The drive filters are altering the timings.
Maybe you can try to change the density mode on the drive ?

[Zalorpas]

Hi Jeff,

Thanks for your reply. This is not an HD disk, it's a 720k DD disk.

It's true that this is a weird disk because the company that wrote it did not follow the standards. As far as I know, the disk was recorded at 80% of the standard speed with two purposes, inserting more data in a DD disk and, as a collateral, adding a copy protection method. Also they used blocks of 1024k despite they are marked as 512k. They also changed the sector IDs...

The issue is... I am able to see the ASM code stored in all the other tracks and sectors of this disk with no issues.
Also, I am able to read all the other disks without issues...

Not sure if I am following you, but I tried to get the RAW data with GreaseWeazel by using the "--dd H" and "--dd L" flags and the result is exactly the same.

So, I am wondering if there is any way to tweak HxC to read a track when this issue happens.
So far it just happened with this disk, but I am trying to find another drive to read disks because we only have one original drive and, if it dies, we won't be able to preserve any other disk.

Thanks

[Jeff]

i will implement a compensation curve setting to deal with such cases. there is similar cases with people using pc drive to read macintosh gcr disks.

[Zalorpas]

That's really good news!
I'll stay tuned. Thanks for your amazing job!

BTW, if you need my support to test this new feature, please, let me know.


I would like to take advantage of this conversation to check if it might be possible to add a parameter to hxcfe.
As I mentioned, the disk has blocks of 1024k but the header has been recorded with blocks of 512k to protect it.

To break the protection, we compiled a version of hxcfe to force reading blocks of 1024 (ignoring the header), otherwise it is taking just 512k.
So, would it be possible adding a parameter to override the sector size by a customized one?

It will be really appreciated.
Thank you very much