-
|
Hello all, I have an arcade system that is using a FDD to load the games. The original FDD is an old Mitsumi D357. In the oposite sense, if I am doing the same with another FDD, a Samsung SFD-321B, then I am not able to get any 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 FDD to get some data (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 the raw data looks like. Thank you very much for your support. Read using Mitsumi Read using Samsung |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 4 replies
-
|
The timings on this track seem strange, being a 300rpm dump but the bit bands are at about 3.2us, 4.8us, 6.4us rather than the usual 4/6/8us. Some drives may not like that. Is this a copy protection track do you think? I would still imagine that drives other than that specific Mitsumi can read this track okay, it's just that not every PC drive will be able to do so. I don't understand the 1us delay of which you speak. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Keirf, If you compare the bit band of the Mitsumi, it is around 3.2us, 4.8us, 6.4us as you mentioned, while the bitband of the Samsung drive is around 3.8us, 5.8us, 7.8us. Maybe I am wrong, but I think that this is the reason why I do not get data with HxC using the Samsung drive. Regarding the protection you mentioned... well... you are partially right, as these disks were written out of the standard specification (we guess they wrote it at 240 RPMs or so) with two purposes... first, record more data in a DD disk, and as a collateral effect, they got a kind of protection. They also wrote the disks in blocks of 1024kb but the checksums are calculated using 512kb, and the sectors are starting at 200... Despite of all these details, we were able to get the ASM code written in this disk... The problem I have now is related to the FDD... because the RAW files that I am generating with the Samsung drive (just for this track, and disk) are not valid for HxC, but the ones using Mitsumi are OK. Do you have any ideas? Maybe by tweaking any GW parameter? Or even, as I mentioned, by editing the RAW file with any tool to modify the bitbands? Any support with that will be really appreciated. P.D: Thanks for this amazing app. |
Beta Was this translation helpful? Give feedback.
-
|
Oh I see. Well those bitbands are after post-processing by HxC tools. The true flux dumped from disk are the stream views which you helpfully also attached. As you can see, the flux-stream views are much "fuzzier" and the Samsung has fuzzy bands quite close to 3/4/6us. I don't know how or why HxC has filtered these to post-PLL bands of 4/6/8us. It's also clear that the Samsung flux bands are wider than from Mitsumi, and therefore noise immunity will be lower. That's probably why the Samsung has not given you a good read. I would suggest you get yourself a few more 3.5-inch drives, as you will find that most drives probably handle the weird timings better than your Samsung. Also, if the track format here is fully understood (is it?), then the track could be perfectly reconstructed from your Mitsumi dump. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Keirf, I confirm you that we got the full dump by using the original Mitsumi drive. I'll keep on testing with other drives. Thanks for your prompt answer. |
Beta Was this translation helpful? Give feedback.
-
|
You should know that any PC drive should be electrically compatible with your machine, except that you may need to simulate a ready signal in pin 34 and switch dskchg to pin 2, and also change the drive select pin. These are the only interface variations between 3.5 inch drives. |
Beta Was this translation helpful? Give feedback.
-
|
You are totally right. I chose the Samsung drive because it is unexpensive and it is not so complex to modify... Unfortunatelly, I found just that issue, impacting in just one disk and just one track :( .... but it should work with the others... :) But for preservation purposes, that's another topic... as I must ensure that we can read any other (lost) disk without any issues. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, Just for your information (and if someone else is facing the same issue), I put the same question in the HxC forum, and they went back to me saying that they will implement a new feature (compensation curve) to try to fix it. It seems that there are more people having the same issue with Macintosh disks. |
Beta Was this translation helpful? Give feedback.
-
|
Yes it's common with GCR. Some PC drives are more tolerant than others. |
Beta Was this translation helpful? Give feedback.
Hello,
Just for your information (and if someone else is facing the same issue), I put the same question in the HxC forum, and they went back to me saying that they will implement a new feature (compensation curve) to try to fix it.
https://torlus.com/floppy/forum/viewtopic.php?p=25794#p25794
It seems that there are more people having the same issue with Macintosh disks.
Best regards