salfter/fluxengine
1
0
Fork 0
mirror of https://github.com/davidgiven/fluxengine.git synced 2025-10-31 11:17:01 -07:00
Code Issues Packages Projects Releases Wiki Activity

Adjust default Brother head_bias, and fix the documentation.

Browse Source 
Fixes: #768
This commit is contained in:
David Given
2024-09-10 18:32:03 +02:00
parent 3c3d8d080c
commit ec3b5b10df
2 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
src/formats/brother.textpb
View File

@@ -9,21 +9,21 @@ Brother word processor disks are weird, using custom tooling and chipsets.
They are completely not PC compatible in every possible way other than the
size.
Different word processors use different disk formats --- the only ones
supported by FluxEngine are the 120kB and 240kB 3.5" formats. The default
options are for the 240kB format. For the 120kB format, which is 40 track, do
`fluxengine read brother -s :t=1-79x2`.
Different word processors use different disk formats --- the only ones supported
by FluxEngine are the 120kB and 240kB 3.5" formats. Use the `--120` and `--240`
options to select which one.
Apparently about 20% of Brother word processors have alignment issues which
means that the disks can't be read by FluxEngine (because the tracks on the
disk don't line up with the position of the head in a PC drive). The word
processors themselves solved this by microstepping until they found where the
real track is, but normal PC drives aren't capable of doing this. Particularly
with the 120kB disks, you might want to fiddle with the start track (e.g.
`:t=0-79x2`) to get a clean read. Keep an eye on the bad sector map that's
dumped at the end of a read. My word processor likes to put logical track 0 on
physical track 3, which means that logical track 77 is on physical track 80;
luckily my PC drive can access track 80.
means that the disks can't be read by FluxEngine (because the tracks on the disk
don't line up with the position of the head in a PC drive). The word processors
themselves solved this by microstepping until they found where the real track
is, but normal PC drives aren't capable of doing this. Particularly with the
120kB disks, you might want to fiddle with the head bias (e.g.
`--drive.head_bias=3`) to get a clean read. Keep an eye on the bad sector map
that's dumped at the end of a read. My word processor likes to put logical track
0 on physical track 3, which means that logical track 77 is on physical track
80, so I need that `head_bias` value of 3; luckily my PC drive can access track
80.
Using FluxEngine to *write* disks isn't a problem, so the
simplest solution is to use FluxEngine to create a new disk, with the tracks
@@ -192,7 +192,7 @@ option_group {
}
drive {
head_bias: 3
head_bias: 0
}
filesystem {