Love to help with Brother

[david-schmidt]

I have a large and growing collection of 120 and 240k Brother disks. I also write drivers for the FC5025 flux reader (http://www.deviceside.com/fc5025.html). I'd love to help with your Brother support.

[davidgiven]

Strangely enough I was just contacted by the Swiss National Library, who have some 120kB Brother disks. Both formats should now work fine and if you look in the tools/ directory there's a reverse-engineered program for pulling files off the 120kB Brother filesystems. (The 240kB ones can be read with mtools.)

Will the FC5025 generate raw flux dumps? If so, it's probably possible to add support to FluxEngine for reading them (it'll read Kryoflux dumps).

[david-schmidt]

The FC5025 makes some assumptions about data patterns that preclude it from successfully producing a good flux read of Brother disks. The Kryoflux and Catweasel of course don't have that limitation.

I'm curious about mtools and the ability to read Brother 240k disks - is that fed by a Kryoflux image as well?

[edit: after reading through the doc, I see what you mean... after reading a 240k disk into a flux image using the reader (and maybe also using a kryoflux), and thebn converting the crazy, dual-GCR scheme into sane bits, you end up with an image that is decently mtools-friendly.]

[davidgiven]

Re the FC5025: that's a shame.

I actually have a LW-30 Brother word processor, which is why it was one of my first targets. I originally thought the format was nuts but since then I've seen Macintosh disks and I now think it's quite sensible! I didn't reverse engineer it by myself, though, and got a lot of useful pointers from someone on the vcfed forums who used to do floppy disk data recovery for a living and could remember some of the details.

So, I've actually scanned and decoded the 240kB disks with FluxEngine, so I know that works natively. The 120kB disks are via Kryoflux streams that I got sent.

The 240kB disks use MSX-DOS FAT with a 256-byte sector size, which is very weird. Once decoded to sector images mtools is quite happy with them, although you need to patch the media byte first.

I wrote some stuff down about the Brother formats here:

http://cowlark.com/fluxengine/brother.html

[david-schmidt]

Ah, Chuck(G). I call him my Fairy Godfather. He knows all things. I've gotten some really, really obscure help on some really, really far-flung things from him.

[davidgiven]

Yup, that's him! I kind of want to dump his brain and make a backup, just in case...

PS. I've suddenly just got a tonne of traffic and none of my analytic tools will tell me where from (no referrer links). Where did you find out about FluxEngine?

[roybaer]

https://hackaday.com/2019/02/19/flux-engine-reads-floppies/

[david-schmidt]

We have a retro slack channel. apple2infinitum.slack.com

[david-schmidt]

So I have a kryoflux - what's the command invocation you'd recommend to capture brother disks with?

[edit: for posterity, you just run the dtc tool (command line or with the UI) and ask for image type 0, plain old Kryoflux stream. It outputs a directory full of stream files, one per track/side).]

[davidgiven]

I can't help there --- I don't actually have a Kyroflux. Otherwise I wouldn't have built the FluxEngine...

There's probably an archival configuration somewhere; the images I've found have all been 80 track, double sided, 8 revolutions, so I think there's probably some standard. The important thing is that for Brother disks I need at least two revolutions.

[david-schmidt]

You don't make mention of it anywhere, so it makes me think it's not FM encoded, but... Of the bit transitions, is there anything FM-ish that does 1-bit insertions, or does the encoding scheme fully encapsulate all necessary transitions as-is?

[davidgiven]

It's GCR encoded, using two different GCR encoding schemes (8-in-16 for sector headers, 5-in-8 for data), plus a couple of out-of-band markers to indicate the start of records. See http://cowlark.com/fluxengine/brother.html in the 'low level format' section.

The results of the GCR encoding can be safely written directly to disk. Or have I misunderstood your question?

[david-schmidt]

My question was formulated badly; I was under the mistaken impression that there was still a need for bit stuffing, but GCR will already take care of those situations (except maybe that place where you say a number is "unencoded" - what was that, the sector number?

[david-schmidt]

Here's a Brother image: disk is blank-from-the-factory that seems to have fared badly; I can't guarantee it hasn't been re-written by a machine somewhere down the line - though it is devoid of files, according to mdir:

H.SS Tracks --->
0. 0 ..XBB....XBB..BB.....B...........B.....BBB........BXXB...BBBBBXB....XX.XB.....
0. 1 .BBX.....B.....B.......................B.B....B....XXB....BX.BXX....XB.BBBX...
0. 2 .BXBX....B.X.........B...........B.....BB....B.....XX.....XXXBBBB....B.XXB...B
0. 3 ..XX.....XB..........B...........B.....B.B.........XXB...XBBXBBB....XB.BB.B...
0. 4 .BBXB....XBB.........B...........B.....X..........XXXX...XBB.XXX....BX.XXB....
0. 5 ..BX.....XXB...B.....X...........B.....XBB...B....BXXB...BXXBBXBB...BB.BXX....
0. 6 .BBB.....BBB...B......B................B.B........BXXX....BX.XXX....XX.XX.....
0. 7 .BXBX....B.X.........X...........B.....X..B..B....BXXB....BXB.XBB...BX.BXBB...
0. 8 .BBX.....XXB...B.......................X...........XXB....XBBBXB....BB..BB....
0. 9 .BBBB....XBX.........B..........BB.....X.B...B.....XXX...XBX.BXB.....XBBXB....
0.10 .BXXB....XX..........B.................B.B.........XXB....XXBBXXB...BXBBB.....
0.11 .BXX.....BBX...B.....X.................X.X.........XXB....XX.XBBB...XX.XXB....
Good sectors: 638/936 (68%)
Missing sectors: 127/936 (13%)
Bad sectors: 171/936 (18%)
78 tracks, 1 heads, 12 sectors, 256 bytes per sector, 234 kB total

Brother-Blank.zip

[davidgiven]

That's a very unhappy disk. It looks like all the tracks line up, so it could be they're simply misaligned a little, giving bad reads. If I look at a pulse interval histogram (--show-clock-histogram, try it on one track at a time) I can see fairly low mounds where there should be sharp spikes, indicating that the intervals are very imprecise. It could just be that it's faded with time; factory formatted disks were made by stamping a magnetic image onto the entire disk in one go, and they were notoriously unreliable.

I found a couple of tiny buglets, but nothing that made any difference, but I can't find anything obviously wrong at my end --- I suspect this image is just beyond my help.

[davidgiven]

I know this is late, but I'm pretty sure I know what's wrong now: the alignment on your disk doesn't match the alignment of a PC drive. So the PC drive is only seeing part of a track.

There's nothing to be done about this other than adjusting the alignment of your drive, which is very scary, but if you have access to Brother hardware you can read the disk there, copy it to a properly aligned disk, and then read that with FluxEngine.

I wrote it up: http://cowlark.com/fluxengine/doc/disk-brother.html

[david-schmidt]

Thanks! It's always going to come up, so there's definitely value in recording this for posterity. It will forever be the problem with Brother disks - they can self-align, and PC drives can't!