Brother 160Kb

[jam-international]

Hi, I recently connected a USB floppy emulator on my Brother machine, from the emulator I extracted a 160kb img file. Now I would like to prepare a hardware to read floppy disks. I have a Greaseweazle F7 Plus and with your FluxEngine Gui I have tried to read with the various discs but without obtaining acceptable data. The data are in side1. disk_from_emulatore.zip

[davidgiven]

There's nothing on the image you sent me other than a little garbage --- it's mostly all zeroes. There's certainly nothing which looks like a filesystem. The settings in the screenshot are confusing because I'm not aware of any Brother machines which use FM encoding; it's either MFM IBM-compatible, or their own custom GCR. Which machine is it?

[davidgiven]

Actually, taking another look at the screenshot: the Brother stores its data on side zero (the bottom). I think that HXC is failing to parse the Brother GCR data on side 0, showing nothing, and is showing old data which hasn't been writter over from side 1.

[jam-international]

I confirm that the data are only on side 1 at the following addresses. 1) 800 2) 4000 3) 7800 4) b000 5) e800 6) 12000 7) 15800 8) 19000 9) 1c800 0) 20000

you can see machine from my chanel, https://www.youtube.com/watch?v=SQ_zPqKAsVM&t=235s.

[davidgiven]

Oh, it's a CNC machine! I thought you were talking about the Brother word processors...

So, assuming that the image is correct, it looks like this is a simple variation on the IBM encoding scheme, although with all the data on the wrong side. Can you do:

fluxengine read ibm1440 --decoder.retries=0 --copy-flux-to=output.flux

...and then attach the resulting output.flux file? That will let me see what's actually on the disk.

[jam-international]

Hi, entering your command from CommandPrompt the floppy motor does not start maybe it wants a Motor On command? I then used the FluxEngine Gui setting ibm1440 and I was able to read the flux that I am attaching to you ibm1440.zip

[jam-international]

this is error from CommandPrompt

[davidgiven]

Try adding:

-s drive:1

[jam-international]

Thank you, is working. This is result. output.zip

[davidgiven]

Thanks!

I think I have a working configuration, which I've attached. Unzip this into the fluxengine directory, and then you can use it with:

fluxengine read brother160.textpb -s drive:1

config.zip

(You can't use it in the GUI yet --- sorry.)

It's an exceptionally weird format. As far as I can tell there are 70 tracks of 16 sectors of 128 bytes each, except only six of every seven tracks are formatted. I assume that these correspond to ten programs on the real machine.

The disk read you sent me is very bad, with 21% bad sectors. Using the configuration I sent you should produce better results as this will let FluxEngine retry bad tracks. If this machine was used in an industrial environment it's possible that the drive has been knocked out of alignment, which will make the disks hard to read in other machines (but the machine itself is capable of reading its own disks).

Let me know if that works for you.

[davidgiven]

Addendum: if you still have the floppy drive you took out of the sewing machine, try using it with the Greaseweazle to see if that improves the disk reads.

[jam-international]

something we read, add. 800 data ok add. 4000 data ok add.7800 data are incorrect (strange, equal to the incorrect data of add.e800 and add.15800) add.b000 data ok add.e800 data is incorrect add. 12000 data ok add.15800 data is incorrect add.19000 data is wrong (strange, same as wrong data of add.20000) add. 1c800 data is incorrect add.20000 data are wrong but the same as add.19000

I confirm that the disk in the machine is read well even if there are some damaged tracks. What is strange is that the incorrect programs are the same! For further tests I try to look for a new driver

brother160.zip

[davidgiven]

That's actually worse than my reads (265 bad sectors vs my 243). You might want to try setting something like --decoder.retries=10 to force it to keep retrying bad sectors.

There are some settings which you can tweak in http://cowlark.com/fluxengine/doc/problems.html which might help, but TBH it usually doesn't help much.

[jam-international]

i try to use: decoder.retries = 10 --decoder.bit_error_threshold = 0.4 (0.1 0.2 0.3 0.4 0.5) but the result hasn't changed. I then tried with --decoder.clock_interval_bias but I get the error that clock_interval_bias does not exist in decoder.

I wonder, how does the CNC read it well? i try to use: decoder.retries = 10 --decoder.bit_error_threshold = 0.4 (0.1 0.2 0.3 0.4 0.5) but the result hasn't changed. I then tried with --decoder.clock_interval_bias but I get the error that clock_interval_bias does not exist in decoder.

I wonder, how does the CNC read it well? Surely you are an expert and you know why

[davidgiven]

My best guess is alignment. If the drive's out of alignment, it'll read and write its own disks, but the disks won't be readable anywhere else. Try plugging the old drive into the Greaseweazle.

[jam-international]

1) on the machine I wrote 10 programs on a disk. 2) I disassembled the driver and connected it to the greaseweazle 3) I ran fluxengine read brother160.textpb -s drive: 1 but the motor didn't start 4) I ran fluxen brother160.zip

brother160.zip gine read brother160.textpb -s drive: 0 but the same did not start 5) I moved the driver SD jumper from SD1 to SD0 and the motor started. Strange.

The result is similar to the other drivers, there are always 70 bad tracks and img in some parts is incorrect

[davidgiven]

Interesting. Okay, not an alignment issue. (I'm also surprised by the jumper issue. PC drives are always jumpered as drive 1, so that's strange.)

One question: are you using an HD disk (two square holes in the corners) or a DD disk (one square hole in the corner)? Using the wrong disk can cause problems. And: how are you powering the drive? I've seen very odd behaviour if the power supply voltage isn't precisely right, and USB is frequently at the wrong voltage.

[jam-international]

I have tried with both DD and HD but the result does not change. I tried to power both with USB and with external power supply but even so I don't have a good result. If you are interested (and available) I could send you some disks to study. For me it would be important to solve.

[davidgiven]

Very belatedly: sorry, I got distracted by another project!

Did you get any further with this? If not, I would be interested in getting a disk, as long as you're aware that I'm a hobbyist, not a data recovery service, which means that results are not guaranteed (and you may not even get your disk back)...