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

Fix bad documentation which got checked in somehow.

Browse Source
This commit is contained in:
David Given
2024-10-16 21:17:43 +02:00
parent 6d3969ab79
commit 4bcbf2b089
36 changed files with 1699 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
doc/disk-40track_drive.md
View File

@@ -1,2 +1,15 @@
-d
\r
40track_drive
====
## Adjust configuration for a 40-track drive
<!-- This file is automatically generated. Do not edit. -->
This is an extension profile; adding this to the command line will configure
FluxEngine to read from 40-track, 48tpi 5.25" drives. You have to tell it because there is
no way to detect this automatically.
For example:
```
fluxengine read ibm --180 40track_drive
```

41
doc/disk-acornadfs.md
View File

@@ -1,2 +1,39 @@
-d
\r
acornadfs
====
## BBC Micro, Archimedes
<!-- This file is automatically generated. Do not edit. -->
Acorn ADFS disks are used by the 6502-based BBC Micro and ARM-based Archimedes
series of computers. They are yet another variation on MFM encoded IBM scheme
disks, although with different sector sizes and with the 0-based sector
identifiers rather than 1-based sector identifiers. The index hole is ignored
and sectors are written whereever, requiring FluxEngine to do two revolutions
to read a disk.
There are various different kinds, which should all work out of the box.
Be aware that Acorn logical block numbering goes all the way up side 0 and
then all the way up side 1. However, FluxEngine uses traditional disk images
with alternating sides, with the blocks from track 0 side 0 then track 0 side
1 then track 1 side 0 etc. Most Acorn emulators will use both formats, but
they might require nudging as the side order can't be reliably autodetected.
## Options
- Format variants:
- `160`: 160kB 3.5" or 5.25" 40-track SSDD; S format
- `320`: 320kB 3.5" or 5.25" 80-track SSDD; M format
- `640`: 640kB 3.5" or 5.25" 80-track DSDD; L format
- `800`: 800kB 3.5" 80-track DSDD; D and E formats
- `1600`: 1600kB 3.5" 80-track DSHD; F formats
## Examples
To read:
- `fluxengine read acornadfs --160 -s drive:0 -o acornadfs.img`
- `fluxengine read acornadfs --320 -s drive:0 -o acornadfs.img`
- `fluxengine read acornadfs --640 -s drive:0 -o acornadfs.img`
- `fluxengine read acornadfs --800 -s drive:0 -o acornadfs.img`
- `fluxengine read acornadfs --1600 -s drive:0 -o acornadfs.img`

40
doc/disk-acorndfs.md
View File

@@ -1,2 +1,38 @@
-d
\r
acorndfs
====
## Acorn Atom, BBC Micro series
<!-- This file is automatically generated. Do not edit. -->
Acorn DFS disks are used by the Acorn Atom and BBC Micro series of computers.
They are pretty standard FM encoded IBM scheme disks, with 256-sectors and
0-based sector identifiers. There's nothing particularly special here.
DFS disks are all single-sided, but allow the other side of the disk to be
used as another volume.
They come in two varieties, 40 track and 80 track. These should both work.
Some rare disks are both at the same time. FluxEngine can read these but it
requires a bit of fiddling as they have the same tracks on twice.
## Options
- Format variants:
- `100`: 100kB 40-track SSSD
- `200`: 200kB 80-track SSSD
## Examples
To read:
- `fluxengine read acorndfs --100 -s drive:0 -o acorndfs.img`
- `fluxengine read acorndfs --200 -s drive:0 -o acorndfs.img`
To write:
- `fluxengine write acorndfs --100 -d drive:0 -i acorndfs.img`
- `fluxengine write acorndfs --200 -d drive:0 -i acorndfs.img`
## References
- [The Acorn DFS disc format](https://beebwiki.mdfs.net/Acorn_DFS_disc_format)

50
doc/disk-aeslanier.md
View File

@@ -1,2 +1,48 @@
-d
\r
aeslanier
====
## 616kB 5.25" 77-track SSDD hard sectored
<!-- This file is automatically generated. Do not edit. -->
Back in 1980 Lanier released a series of very early integrated word processor
appliances, the No Problem. These were actually [rebranded AES Data Superplus
machines](http://vintagecomputers.site90.net/aes/). They were gigantic,
weighed 40kg, and one example I've found cost ꆲ5bb4
of nearly ㇢1a6e
8080 machines with 32kB of RAM, they ran their own proprietary word
processing software off twin 5.25" drive units, but apparently other software
was available.
The disk format is exceptionally weird. They used 77 track, 32 sector, single-sided
_hard_ sectored disks, where there were multiple index holes,
indicating to the hardware where the sectors start. The encoding scheme
itself is [MMFM (aka
M2FM)](http://www.retrotechnology.com/herbs_stuff/m2fm.html), an early
attempt at double-density disk encoding which rapidly got obsoleted by the
simpler MFM --- and the bytes are stored on disk _backwards_. Even aside from
the encoding, the format on disk was strange; unified sector header/data
records, so that the sector header (containing the sector and track number)
is actually inside the user data.
FluxEngine can read these, but I only have a single, fairly poor example of a
disk image, and I've had to make a lot of guesses as to the sector format
based on what looks right. If anyone knows _anything_ about these disks,
[please get in touch](https://github.com/davidgiven/fluxengine/issues/new).
## Options
(no options)
## Examples
To read:
- `fluxengine read aeslanier -s drive:0 -o aeslanier.img`
## References
* [SA800 Diskette Storage Drive - Theory Of
Operations](http://www.hartetechnologies.com/manuals/Shugart/50664-1_SA800_TheorOp_May78.pdf):
talks about MMFM a lot, but the Lanier machines didn't use this disk
format.

38
doc/disk-agat.md
View File

@@ -1,2 +1,36 @@
-d
\r
agat
====
## 840kB 5.25" 80-track DS
<!-- This file is automatically generated. Do not edit. -->
The Agat (Russian: ↊fd74
1983. These were based around a 6502 and were nominally Apple II-compatible
although with enough differences to be problematic.
They could use either standard Apple II 140kB disks, or a proprietary 840kb
MFM-based double-sided format. FluxEngine supports both of these; this profile
is for the proprietary format. for the Apple II format, use the `apple2`
profile.
## Options
(no options)
## Examples
To read:
- `fluxengine read agat -s drive:0 -o agat.img`
To write:
- `fluxengine write agat -d drive:0 -i agat.img`
## References
- [Magazine article on the
Agat](https://sudonull.com/post/54185-Is-AGAT-a-bad-copy-of-Apple)
- [Forum thread with (some) documentation on the
format](https://torlus.com/floppy/forum/viewtopic.php?t=1385)

43
doc/disk-amiga.md
View File

@@ -1,2 +1,41 @@
-d
\r
amiga
====
## 880kB 3.5" DSDD
<!-- This file is automatically generated. Do not edit. -->
Amiga disks use MFM, but don't use IBM scheme. Instead, the entire track is
read and written as a unit, with each sector butting up against the previous
one. This saves a lot of space which allows the Amiga to not just store 880kB
on a DD disk, but _also_ allows an extra 16 bytes of metadata per sector.
This metadata is mostly unused, so the default for FluxEngine is to ignore it
and just use the 512 bytes of main sector data. If you want it, specify a
528-byte sector size. The metadata will come after the user data.
Bizarrely, the data in each sector is stored with all the odd bits first, and
then all the even bits. This is tied into the checksum algorithm, which is
distinctly subpar and not particularly good at detecting errors.
## Options
- Sector size:
- `without_metadata`: 512-byte sectors
- `with_metadata`: 528-byte sectors
## Examples
To read:
- `fluxengine read amiga -s drive:0 -o amiga.adf`
To write:
- `fluxengine write amiga -d drive:0 -i amiga.adf`
## References
- [The Amiga Floppy Boot Process and Physical
Layout](https://wiki.amigaos.net/wiki/Amiga_Floppy_Boot_Process_and_Physical_Layout)
- [The Amiga Disk File FAQ](http://lclevy.free.fr/adflib/adf_info.html)

54
doc/disk-ampro.md
View File

@@ -1,2 +1,52 @@
-d
\r
ampro
====
## CP/M
<!-- This file is automatically generated. Do not edit. -->
The Ampro Little Board was a very simple and cheap Z80-based computer from
1984, which ran CP/M. It was, in fact, a single PCB which you could mount
on the bottom of a 5.25" drive.
[All about the Ampro Little Board](http://oldcomputers.net/ampro-little-board.html)
It stored either 400kB on a double-sided 40-track drive or 800kB on a
double-sided 80 track drive. The disk format it used was a slightly quirky
variation of the standard MFM IBM scheme --- sector numbering starts at 17
rather than 1 (or Acorn's 0). FluxEngine supports this.
FluxEngine has direct filesystem support for these disks, or you can pass the
disk images into [cpmtools](http://www.moria.de/~michael/cpmtools/):
```
$ cpmls -f ampdsdd ampro.img
0:
-a60014.e
amprodsk.com
bitchk.doc
bitchk.mac
cpmmac.mac
dir.com
himem.doc
himem.mac
kaydiag.lbr
kayinfo.lbr
...etc...
```
## Options
- Format variants:
- `400`: 400kB 40-track DSDD
- `800`: 800kB 80-track DSDD
## Examples
To read:
- `fluxengine read ampro --400 -s drive:0 -o ampro.img`
- `fluxengine read ampro --800 -s drive:0 -o ampro.img`
## References
- [The Ampro Little Board](http://oldcomputers.net/ampro-little-board.html)

76
doc/disk-apple2.md
View File

@@ -1,2 +1,74 @@
-d
\r
apple2
====
## Prodos, Appledos, and CP/M
<!-- This file is automatically generated. Do not edit. -->
Apple II disks are nominally fairly sensible 40-track, single-sided, 256
bytes-per-sector jobs. However, they come in two varieties: DOS 3.3/ProDOS and
above, and pre-DOS 3.3. They use different GCR encoding systems, dubbed
6-and-2 and 5-and-3, and are mutually incompatible (although in some rare
cases you can mix 6-and-2 and 5-and-3 sectors on the same disk).
The difference is in the drive controller; the 6-and-2 controller is capable
of a more efficient encoding, and can fit 16 sectors on a track, storing
140kB on a disk. The 5-and-3 controller can only fit 13, with a mere 114kB.
Both formats use GCR (in different varieties) in a nice, simple grid of
sectors, unlike the Macintosh. Like the Macintosh, there's a crazy encoding
scheme applied to the data before it goes down on disk to speed up
checksumming.
In addition, a lot of the behaviour of the drive was handled in software.
This means that Apple II disks can do all kinds of weird things, including
having spiral tracks! Copy protection for the Apple II was even madder than
on other systems.
FluxEngine can only read well-behaved 6-and-2 disks. It doesn't even try to
handle the weird stuff.
Apple DOS also applies logical sector remapping on top of the physical sector
numbering on the disk, and this _varies_ depending on what the disk is for.
FluxEngine can remap the sectors from physical to logical using modifiers. If
you don't specify a remapping modifier, you get the sectors in the order they
appear on the disk.
If you don't want an image in physical sector order, specify one of the
filesystem ordering options. These also select the appropriate file system;
FluxEngine has read-only support for all of these.
In addition, some third-party systems use 80-track double sides drives, with
the same underlying disk format. The complication here is that the AppleDOS
filesystem only supports up to 50 tracks, so it needs tweaking to support
larger disks. It treats the second side of the disk as a completely different
volume.
## Options
- Format variants:
- `140`: 140kB 5.25" 35-track SS
- `640`: 640kB 5.25" 80-track DS
- Filesystem and sector skew:
- `nofs`: use physical CHS sector order and no file system
- `appledos`: use AppleDOS soft sector skew and file system
- `prodos`: use ProDOS soft sector skew and filesystem
- `cpm`: use CP/M soft sector skew and filesystem
- `side1`: for AppleDOS file system access, read the volume on side 1 of a disk
## Examples
To read:
- `fluxengine read apple2 --140 -s drive:0 -o apple2.img`
- `fluxengine read apple2 --640 -s drive:0 -o apple2.img`
To write:
- `fluxengine write apple2 --140 -d drive:0 -i apple2.img`
- `fluxengine write apple2 --640 -d drive:0 -i apple2.img`
## References
- [Beneath Apple DOS](https://fabiensanglard.net/fd_proxy/prince_of_persia/Beneath%20Apple%20DOS.pdf)
- [MAME's ap2_dsk.cpp file](https://github.com/mamedev/mame/blob/4263a71e64377db11392c458b580c5ae83556bc7/src/lib/formats/ap2_dsk.cpp)

18
doc/disk-apple2_drive.md
View File

@@ -1,2 +1,16 @@
-d
\r
apple2_drive
====
## Adjust configuration for a 40-track Apple II drive
<!-- This file is automatically generated. Do not edit. -->
This is an extension profile; adding this to the command line will configure
FluxEngine to adjust the pinout and track spacing to work with an Apple II
drive. This only works on Greaseweazle hardware and requires a custom
connector.
For example:
```
fluxengine read apple2 --160 apple2_drive
```

63
doc/disk-atarist.md
View File

@@ -1,2 +1,61 @@
-d
\r
atarist
====
## Almost PC compatible
<!-- This file is automatically generated. Do not edit. -->
Atari ST disks are standard MFM encoded IBM scheme disks without an IAM header.
Disks are typically formatted 512 bytes per sector with between 9-10 (sometimes
11!) sectors per track and 80-82 tracks per side.
For some reason, occasionally formatting software will put an extra IDAM record
with a sector number of 66 on a disk, which can horribly confuse things. The
Atari profiles below are configured to ignore these.
Be aware that many PC drives (including mine) won't do the 82 track formats.
## Options
- Format variants:
- `360`: 360kB 3.5" 80-track 9-sector SSDD
- `370`: 370kB 3.5" 82-track 9-sector SSDD
- `400`: 400kB 3.5" 80-track 10-sector SSDD
- `410`: 410kB 3.5" 82-track 10-sector SSDD
- `720`: 720kB 3.5" 80-track 9-sector DSDD
- `740`: 740kB 3.5" 82-track 9-sector DSDD
- `800`: 800kB 3.5" 80-track 10-sector DSDD
- `820`: 820kB 3.5" 82-track 10-sector DSDD
## Examples
To read:
- `fluxengine read atarist --360 -s drive:0 -o atarist.img`
- `fluxengine read atarist --370 -s drive:0 -o atarist.img`
- `fluxengine read atarist --400 -s drive:0 -o atarist.img`
- `fluxengine read atarist --410 -s drive:0 -o atarist.img`
- `fluxengine read atarist --720 -s drive:0 -o atarist.img`
- `fluxengine read atarist --740 -s drive:0 -o atarist.img`
- `fluxengine read atarist --800 -s drive:0 -o atarist.img`
- `fluxengine read atarist --820 -s drive:0 -o atarist.img`
To write:
- `fluxengine write atarist --360 -d drive:0 -i atarist.img`
- `fluxengine write atarist --370 -d drive:0 -i atarist.img`
- `fluxengine write atarist --400 -d drive:0 -i atarist.img`
- `fluxengine write atarist --410 -d drive:0 -i atarist.img`
- `fluxengine write atarist --720 -d drive:0 -i atarist.img`
- `fluxengine write atarist --740 -d drive:0 -i atarist.img`
- `fluxengine write atarist --800 -d drive:0 -i atarist.img`
- `fluxengine write atarist --820 -d drive:0 -i atarist.img`
## References
- [Atari ST Floppy Drive Hardware
Information](https://info-coach.fr/atari/hardware/FD-Hard.php) by Jean
Louis-Guerin
- [Atari ST Floppy Drive Software
Information](https://info-coach.fr/atari/software/FD-Soft.php) by Jean
Louis-Guerin

32
doc/disk-bk.md
View File

@@ -1,2 +1,30 @@
-d
\r
bk
====
## 800kB 5.25"/3.5" 80-track 10-sector DSDD
<!-- This file is automatically generated. Do not edit. -->
The BK (an abbreviation for 1ba9
is a Soviet era personal computer from Elektronika based on a PDP-11
single-chip processor. It was the _only_ official, government approved home
computer in mass production at the time.
It got a floppy interface in 1989 when the 128kB BK-0011 was released. This
used a relatively normal double-sided IBM scheme format with 80 sectors and ten
sectors per track, resulting in 800kB disks. The format is, in fact, identical
to the Atari ST 800kB format. Either 5.25" or 3.5" drives were used depending
on what was available at the time, with the same format on both.
## Options
(no options)
## Examples
To read:
- `fluxengine read bk -s drive:0 -o bk800.img`
To write:
- `fluxengine write bk -d drive:0 -i bk800.img`

130
doc/disk-brother.md
View File

@@ -1,2 +1,128 @@
-d
\r
brother
====
## GCR family
<!-- This file is automatically generated. Do not edit. -->
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. 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 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
aligned properly, and then use a word processor to copy the files you want
onto it. The new disk can then be read and you can extract the files.
Obviously this sucks if you don't actually have a word processor, but I can't
do anything about that.
If you find one of these misaligned disks then *please* [get in
touch](https://github.com/davidgiven/fluxengine/issues/new); I want to
investigate.
## Options
- Format variants:
- `120`: 120kB 3.5" 39-track SS GCR
- `240`: 240kB 3.5" 78-track SS GCR
## Examples
To read:
- `fluxengine read brother --120 -s drive:0 -o brother.img`
- `fluxengine read brother --240 -s drive:0 -o brother.img`
To write:
- `fluxengine write brother --120 -d drive:0 -i brother.img`
- `fluxengine write brother --240 -d drive:0 -i brother.img`
Dealing with misaligned disks
-----------------------------
While FluxEngine can't read misaligned disks directly, Brother word processors
_can_. If you have access to a compatible word processor, there's a fairly
simple workaround to allow you to extract the data:
1. Format a disk using FluxEngine (by simply writing a blank filesystem image
to a disk). This will have the correct alignment to work on a PC drive.
2. Use a word processor to copy the misaligned disk to the newly formatted
disk. The machine will happily adjust itself to both sets of alignments.
3. Use FluxEngine to read the data off the correctly aligned disk.
I realise this is rather unsatisfactory, as the Brother hardware is becoming
rarer and they cope rather badly with damaged disks, but this is a limitation
of the hardware of normal PC drives. (It _is_ possible to deliberately misalign
a drive to make it match up with a bad disk, but this is for experts only --- I
wouldn't dare.)
Low level format
----------------
The drive is a single-sided 3.5" drive spinning at not 300 rpm (I don't know
the precise speed yet but FluxEngine doesn't care). The 240kB disks have 78
tracks and the 120kB disks have 39.
Each track has 12 256-byte sectors. The drive ignores the index hole so they're
lined up all anyhow. As FluxEngine can only read from index to index, it
actually reads two complete revolutions and reassembles the sectors from that.
The underlying encoding is exceptionally weird; they use two different kinds of
GCR, one kind for the sector header records and a completely different one for
the data itself. It also has a completely bizarre CRC variant which a genius on
StackOverflow reverse engineered for me. However, odd though it may be, it does
seem pretty robust.
See the source code for the GCR tables and CRC routine.
Sectors are about 16.2ms apart on the disk (at 300 rpm). The header and
data records are 0.694ms apart. (All measured from the beginning of the
record.) The sector order is 05a3816b4927, which gives a sector skew of 5.
High level format
-----------------
Once decoded, you end up with a file system image. FluxEngine supports direct
filesystem access for both kinds of disks.
### 120kB disks
These disks use a proprietary and very simple file system. It's FAT-like
with an obvious directory and allocation table. It's supported by FluxEngine.
Any files whose names begin with an asterisk (`*`) will be marked as hidden. If
the file is named `*boot`, then a boot sector will be created which will load
and run the file at 0x7000 if the machine is started with CODE+Q pressed. So
far this has only been confirmed to work on a WP-1.
### 240kB disks
Conversely, the 240kB disks turns out to be a completely normal Microsoft FAT
file system with a media type of 0x58 --- did you know that FAT supports 256
byte sectors? I didn't --- of the MSX-DOS variety. There's a faint
possibility that the word processor is based on MSX-DOS, but I haven't
reverse engineered it to find out.
Standard Linux mtools will access the filesystem image and allow you to move
files in and out. However, you'll need to change the media type bytes at
offsets 0x015 and 0x100 from 0x58 to 0xf0 before mtools will touch it. The
supplied `brother240tool` will do this. Additionally, FluxEngine's own FAT
file system supports this.

76
doc/disk-commodore.md
View File

@@ -1,2 +1,74 @@
-d
\r
commodore
====
## 1541, 1581, 8050 and variations
<!-- This file is automatically generated. Do not edit. -->
Commodore 8-bit computer disks come in two varieties: GCR, which are the
overwhelming majority; and MFM, only used on the 1571 and 1581. The latter were
(as far as I can tell) standard IBM PC format disks with a slightly odd sector
count.
The GCR disks are much more interesting. They could store 170kB on a
single-sided disk (although later drives were double-sided), using a proprietary
encoding and record scheme; like [Apple Macintosh disks](macintosh.md) they
stored varying numbers of sectors per track to make the most of the physical
disk area, although unlike them they did it by changing the bitrate rather than
adjusting the motor speed.
The drives were also intelligent and ran DOS on a CPU inside them. The
computer itself knew nothing about file systems. You could even upload
programs onto the drive and run them there, allowing all sorts of custom disk
formats, although this was mostly used to compensate for the [cripplingly
slow connection to the
computer](https://ilesj.wordpress.com/2014/05/14/1541-why-so-complicated/) of
300 bytes per second (!). (The drive itself could transfer data reasonably
quickly.)
- a 1541 disk has 35 tracks of 17 to 21 sectors, each 256 bytes long
(sometimes 40 tracks), and uses GCR encoding.
- a standard 1581 disk has 80 tracks and two sides, each with 10 sectors, 512
bytes long, and uses normal IBM encoding.
- an 8050 disk has 77 tracks and two sides, with four speed zones; the number
of sectors varies from 23 to 29, using GCR encoding. These will store
1042kB. These drives are peculiar because they are 100tpi and therefore the
disks cannot be read in normal 96tpi drives.
- a CMD FD2000 disk (a popular third-party Commodore disk drive) has 81
tracks and two sides, each with 10 1024-byte sectors, for a massive 1620kB
of storage. This also uses IBM encoding.
A CMD FD2000 disk (a popular third-party Commodore disk drive)
## Options
- Format variants:
- `171`: 171kB 1541, 35-track variant
- `192`: 192kB 1541, 40-track variant
- `800`: 800kB 3.5" 1581
- `1042`: 1042kB 5.25" 8051
- `1620`: 1620kB, CMD FD2000
## Examples
To read:
- `fluxengine read commodore --171 -s drive:0 -o commodore.d64`
- `fluxengine read commodore --192 -s drive:0 -o commodore.d64`
- `fluxengine read commodore --800 -s drive:0 -o commodore.d64`
- `fluxengine read commodore --1042 -s drive:0 -o commodore.d64`
- `fluxengine read commodore --1620 -s drive:0 -o commodore.d64`
To write:
- `fluxengine write commodore --171 -d drive:0 -i commodore.d64`
- `fluxengine write commodore --192 -d drive:0 -i commodore.d64`
- `fluxengine write commodore --800 -d drive:0 -i commodore.d64`
- `fluxengine write commodore --1620 -d drive:0 -i commodore.d64`
## References
- [Ruud's Commodore Site: 1541](http://www.baltissen.org/newhtm/1541c.htm):
documentation on the 1541 disk format.

44
doc/disk-eco1.md
View File

@@ -1,2 +1,42 @@
-d
\r
eco1
====
## CP/M; 1210kB 77-track mixed format DSHD
<!-- This file is automatically generated. Do not edit. -->
The Eco1 is a Italian CP/M machine produced in 1982. It had 64kB of RAM, in
later models expandable up to 384kB, and _two_ Z80 processors. One of these was
used solely for managing the twin 8" drives, each storing 1.2MB, which was
quite impressive for a CP/M machine in those days. Visually it is best
described as 'very brown'.
<div style="text-align: center">
<a href="vds-eco1.jpg"> <img src="vds-eco1.jpg" style="width:80%" alt="A contemporary advert for the Eco1"/></a>
</div>
Its format is standard IBM scheme, but with an interesting wrinkle: there are
_three_ different formatting zones on the disk:
- Track 0 side 0: 26 sectors, 128 bytes per sector (3296 bytes)
- Track 0 side 1: 26 sectors, 256 bytes per sector (6656 bytes)
- All others: 16 sectors, 512 bytes per sector (8192 bytes)
The standard `read ibm` command will autodetect and read these disks, but due
to the format confusing the size autodetection the images need postprocessing
to be useful, so there's a custom profile for the Eco1 which produces sensible
images.
## Options
(no options)
## Examples
To read:
- `fluxengine read eco1 -s drive:0 -o eco1.img`
## References
- [Apulio Retrocomputing's page on the
Eco1](https://www.apuliaretrocomputing.it/wordpress/?p=8976)

21
doc/disk-epsonpf10.md
View File

@@ -1,2 +1,19 @@
-d
\r
epsonpf10
====
## CP/M; 3.5" 40-track DSDD
<!-- This file is automatically generated. Do not edit. -->
The Epson PF10 is the disk unit for the Epson Z80 series of 'laptops', running
CP/M. It uses a single-sided 40-track 3.5" format, which is unusual, but the
format itself is yet another IBM scheme variant.
## Options
(no options)
## Examples
To read:
- `fluxengine read epsonpf10 -s drive:0 -o epsonpf10.img`

49
doc/disk-f85.md
View File

@@ -1,2 +1,47 @@
-d
\r
f85
====
## 461kB 5.25" 77-track SS
<!-- This file is automatically generated. Do not edit. -->
The Durango F85 was an early office computer based around a 5MHz 8085 processor,
sold in 1977. It had an impressive 64kB of RAM, upgradable to 128kB, and ran
its own multitasking operating system call DX-85M, as well as CP/M. It had an
interesting electric-typewriter form factor, with a little monitor sitting on
the side of it --- in operation you were facing the 14" printer.
It was touted as being portable. Which it was, if you were strong; the story
is that they had to do an extensive search to find someone capable of lifting
it for the following photo...
<div style="text-align: center">
<img src="durangof85.jpg" style="max-width: 60%" alt="A Durango F85, held precariously">
</div>
...and even then, they had to airbrush out the tendons in her neck from the
effort!
It used 5.25 soft-sectored disks storing an impressive-for-those-days
480kBish on a side, using a proprietary 4-in-5 GCR encoding. They used 77
tracks, 12 sectors and 512 bytes per sector. Later models used double-sided
disks; I don't have access to an image of one so don't know how they work
(there's a suspicious looking spare byte in the sector header which could
store the side). As always, if you have one, please [get in
touch](https://github.com/davidgiven/fluxengine/issues/new).
## Options
(no options)
## Examples
To read:
- `fluxengine read f85 -s drive:0 -o f85.img`
## References
There's amazingly little information about these things.
* [Chuck Guzis' F85 page](http://www.sydex.com/durango/durango.html) with
lots of pictures

50
doc/disk-fb100.md
View File

@@ -1,2 +1,48 @@
-d
\r
fb100
====
## 100kB 3.5" 40-track SSSD
<!-- This file is automatically generated. Do not edit. -->
The Brother FB-100 is a serial-attached smart floppy drive used by a several
different machines for mass storage, including the Tandy Model 100 and
clones, the Husky Hunter 2, and (bizarrely) several knitting machines. It was
usually rebadged, sometimes with a cheap paper label stuck over the Brother
logo, but the most common variant appears to be the Tandy Portable Disk Drive
or TPDD:
<div style="text-align: center">
<a href="http://www.old-computers.com/museum/computer.asp?c=233&st=1"> <img src="tpdd.jpg" alt="A Tandy Portable Disk Drive"/></a>
</div>
It's a bit of an oddball: the disk encoding is FM with a very custom record
scheme: 40-track single-sided 3.5" disks storing 100kB or so each. Each track
had only _two_ sectors, each 1280 bytes, but with an additional 12 bytes of
ID data used for filesystem management.
There was also apparently a TPDD-2 which could store twice as much data, but
I don't have access to one of those disks.
## Options
(no options)
## Examples
To read:
- `fluxengine read fb100 -s drive:0 -o fb100.img`
## References
- [Tandy Portable Disk Drive operations
manual](http://www.classiccmp.org/cini/pdf/Tandy/Portable%20Disk%20Drive%20Operation%20Manual.pdf)
- [Tandy Portable Disk Drive service
manual](https://archive.org/details/TandyPortableDiskDriveSoftwareManual26-3808s)
- [TPDD design notes (including a dump of the
ROM)](http://bitchin100.com/wiki/index.php?title=TPDD_Design_Notes)
- [Knitting machine FB-100
resources](http://www.k2g2.org/wiki:brother_fb-100)

44
doc/disk-hplif.md
View File

@@ -1,2 +1,42 @@
-d
\r
hplif
====
## a variety of disk formats used by HP
<!-- This file is automatically generated. Do not edit. -->
LIF, a.k.a. Logical Interchange Format, is a series of formats used by
Hewlett-Packard across their entire range of computers, from calculators to
modern servers. It also defines a simple non-hierarchical filesystem which is
bizarrely _still_ supported by HP-UX systems.
Floppy-disk wise, they're yet more variations of the standard IBM floppy
encoding scheme.
## Options
- Format variants:
- `264`: 264kB 3.5" 66-track SSDD; HP9121 format
- `608`: 608kB 3.5" 76-track DSDD; HP9122 format
- `616`: 616kB 3.5" 77-track DSDD
- `770`: 770kB 3.5" 77-track DSDD
## Examples
To read:
- `fluxengine read hplif --264 -s drive:0 -o hplif.img`
- `fluxengine read hplif --608 -s drive:0 -o hplif.img`
- `fluxengine read hplif --616 -s drive:0 -o hplif.img`
- `fluxengine read hplif --770 -s drive:0 -o hplif.img`
To write:
- `fluxengine write hplif --264 -d drive:0 -i hplif.img`
- `fluxengine write hplif --608 -d drive:0 -i hplif.img`
- `fluxengine write hplif --616 -d drive:0 -i hplif.img`
- `fluxengine write hplif --770 -d drive:0 -i hplif.img`
## References
* [A summary of the Hewlett Packard floppy disk
formats](http://www.bitsavers.org/pdf/hp/disc/912x/HP_Flexible_Disk_Formats.pdf)

124
doc/disk-ibm.md
View File

@@ -1,2 +1,122 @@
-d
\r
ibm
====
## Generic PC 3.5"/5.25" disks
<!-- This file is automatically generated. Do not edit. -->
IBM scheme disks are _the_ most common disk format, ever. They're used by a
huge variety of different systems, and they come in a huge variety of different
forms, but they're all fundamentally the same: either FM or MFM, either single-
or double-sided, with distinct sector header and data records and no sector
metadata. Systems which use IBM scheme disks include but are not limited to:
- IBM PCs (naturally)
- Atari ST
- late era Apple machines
- Acorn machines
- the TRS-80
- late era Commodore machines (the 1571 and so on)
- most CP/M machines
- NEC PC-88 series
- NEC PC-98 series
- Sharp X68000
- Fujitsu FM Towns
- VAX & PDP-11
- etc
FluxEngine supports reading these. However, some variants are more peculiar
than others, and as a result there are specific decoders which set the defaults
correctly for certain formats (for example: on PC disks the sector numbers
start from 1, but on Acorn disks they start from 0). The IBM decoder described
here is the generic one, and is suited for 'conventional' PC disks. While you
can read all the variant formats with it if you use the right set of arguments,
it's easier to use the specific decoder.
There is a generic decoder which should adjust automatically to whichever disk
format you are using, but it's unreliable and not recommended. This format
should also be used if you are writing images such as DIM which specify the
image format. FluxEngine will use these parameters.
## Options
- Format variants:
- `auto`: try to autodetect the format (unreliable)
- `160`: 160kB 5.25" 40-track 8-sector SSDD
- `180`: 180kB 5.25" 40-track 9-sector SSDD
- `320`: 320kB 5.25" 40-track 8-sector DSDD
- `360`: 360kB 5.25" 40-track 9-sector DSDD
- `720_96`: 720kB 5.25" 80-track 9-sector DSDD
- `720_135`: 720kB 3.5" 80-track 9-sector DSDD
- `1200`: 1200kB 5.25" 80-track 15-sector DSHD
- `1232`: 1232kB 5.25" 77-track 8-sector DSHD
- `1440`: 1440kB 3.5" 80-track 18-sector DSHD
- `1680`: 1680kB 3.5" 80-track 21-sector DSHD; DMF
## Examples
To read:
- `fluxengine read ibm --auto -s drive:0 -o ibm.img`
- `fluxengine read ibm --160 -s drive:0 -o ibm.img`
- `fluxengine read ibm --180 -s drive:0 -o ibm.img`
- `fluxengine read ibm --320 -s drive:0 -o ibm.img`
- `fluxengine read ibm --360 -s drive:0 -o ibm.img`
- `fluxengine read ibm --720_96 -s drive:0 -o ibm.img`
- `fluxengine read ibm --720_135 -s drive:0 -o ibm.img`
- `fluxengine read ibm --1200 -s drive:0 -o ibm.img`
- `fluxengine read ibm --1232 -s drive:0 -o ibm.img`
- `fluxengine read ibm --1440 -s drive:0 -o ibm.img`
- `fluxengine read ibm --1680 -s drive:0 -o ibm.img`
To write:
- `fluxengine write ibm --160 -d drive:0 -i ibm.img`
- `fluxengine write ibm --180 -d drive:0 -i ibm.img`
- `fluxengine write ibm --320 -d drive:0 -i ibm.img`
- `fluxengine write ibm --360 -d drive:0 -i ibm.img`
- `fluxengine write ibm --720_96 -d drive:0 -i ibm.img`
- `fluxengine write ibm --720_135 -d drive:0 -i ibm.img`
- `fluxengine write ibm --1200 -d drive:0 -i ibm.img`
- `fluxengine write ibm --1232 -d drive:0 -i ibm.img`
- `fluxengine write ibm --1440 -d drive:0 -i ibm.img`
- `fluxengine write ibm --1680 -d drive:0 -i ibm.img`
Mixed-format disks
------------------
Some disks, such as those belonging to early CP/M machines, or N88-Basic disks
(for PC-88 and PC-98), have more than one format on the disk at once. Typically,
the first few tracks will be low-density FM encoded and will be read by the
machine's ROM; those tracks contain new floppy drive handling code capable of
coping with MFM data, and so the rest of the disk will use that, allowing them
to store more data.
FluxEngine can read these fine, but it tends to get a bit confused when it sees
tracks with differing numbers of sectors --- if track 0 has 32 sectors but
track 1 has 16, it will assume that sectors 16..31 are missing on track 1 and
size the image file accordingly. This can be worked around by specifying the
size of each track; see the `eco1` read profile for an example.
N88-Basic format floppies can be written by either specifying the `n88basic`
format, or by using D88 or NFD format images which include explicit sector
layout information.
Writing other formats can be made to work too, by creating a custom format
specifier, using the `n88basic` format as an example.
Please [get in touch](https://github.com/davidgiven/fluxengine/issues/new) if
you have specific requirements.
360rpm 3.5" disks
-----------------
Japanese PCs (NEC PC-98, Sharp X68000, Fujitsu FM Towns) spin their floppy
drives at 360rpm rather than the more typical 300rpm. This was done in order
to be fully backwards compatible with 5.25" disks, while using the exact
same floppy controller. Later models of the PC-9821, as well as most USB floppy
drives, feature "tri-mode" support which in addition to normal 300rpm modes,
can change their speed to read and write 360rpm DD and HD disks.
Neither the FluxEngine or Greaseweazle hardware can currently command a
tri-mode drive to spin at 360rpm. However on both devices the FluxEngine
software is capable of both reading and writing 300rpm disks at 360rpm and vice
versa, so it shouldn't matter.

21
doc/disk-icl30.md
View File

@@ -1,2 +1,19 @@
-d
\r
icl30
====
## CP/M; 263kB 35-track DSSD
<!-- This file is automatically generated. Do not edit. -->
The ICL Model 30 is a reasonably standard CP/M machine using 35-track single
density disks and the traditional CP/M 128-byte secotrs --- 30 of them per
track! Other than that it's another IBM scheme variation.
## Options
(no options)
## Examples
To read:
- `fluxengine read icl30 -s drive:0 -o icl30.img`

75
doc/disk-mac.md
View File

@@ -1,2 +1,73 @@
-d
\r
mac
====
## 400kB/800kB 3.5" GCR
<!-- This file is automatically generated. Do not edit. -->
Macintosh disks come in two varieties: the newer 1440kB ones, which are
perfectly ordinary PC disks you should use the `ibm` profile to read them, and
the older 800kB disks (and 400kB for the single sides ones). They have 80
tracks and up to 12 sectors per track.
They are also completely insane.
It's not just the weird, custom GCR encoding. It's not just the utterly
bizarre additional encoding/checksum built on top of that where [every byte
is mutated according to the previous bytes in the
sector](https://www.bigmessowires.com/2011/10/02/crazy-disk-encoding-schemes/).
It's not just the odd way in which disks think they have four sides, two on one
side and two on the other, so that the track byte stores only the bottom 6 bits
of the track number. It's not just the way that Macintosh sectors are 524 bytes
long. No, it's the way the Macintosh drive changes speed depending on which
track it's looking at, so that each track contains a different amount of data.
The reason for this is actually quite sensible: the tracks towards the centre
of the disk are obviously moving more slowly, so you can't pack the bits in
quite as closely (due to limitations in the magnetic media). You can use a
higher bitrate at the edge of the disk than in the middle. Many platforms, for
example the Commodore 64 1541 drive, changed bitrate this way.
But Macintosh disks used a constant bitrate and changed the speed that the disk
spun instead to achieve the same effect...
_Anyway_: FluxEngine will read them fine on conventional drives. Because it's
clever.
Macintosh computers never really used the twelve bytes of metadata and the
standard for disk images is to omit it. If you want them, specify that you want
524-byte sectors. The metadata will follow the 512 bytes of user data.
## Options
- Format variants:
- `400`: 400kB 80-track SSDD
- `800`: 800kB 80-track DSDD
- `metadata`: read/write 524 byte sectors
## Examples
To read:
- `fluxengine read mac --400 -s drive:0 -o mac.dsk`
- `fluxengine read mac --800 -s drive:0 -o mac.dsk`
To write:
- `fluxengine write mac --400 -d drive:0 -i mac.dsk`
- `fluxengine write mac --800 -d drive:0 -i mac.dsk`
## References
- [MAME's ap_dsk35.cpp file](https://github.com/mamedev/mame/blob/4263a71e64377db11392c458b580c5ae83556bc7/src/lib/formats/ap_dsk35.cpp),
without which I'd never have managed to do this
- [Crazy Disk Encoding
Schemes](https://www.bigmessowires.com/2011/10/02/crazy-disk-encoding-schemes/), which made
me realise just how nuts the format is
- [Les Disquettes et le drive Disk II](http://www.hackzapple.com/DISKII/DISKIITECH.HTM), an
epicly detailed writeup of the Apple II disk format (which is closely related)
- [The DiskCopy 4.2
format](https://www.discferret.com/wiki/Apple_DiskCopy_4.2), described on
the DiskFerret website.

89
doc/disk-micropolis.md
View File

@@ -1,2 +1,87 @@
-d
\r
micropolis
====
## 100tpi MetaFloppy disks
<!-- This file is automatically generated. Do not edit. -->
Micropolis MetaFloppy disks use MFM and hard sectors. Mod I was 48 TPI and
stored 143k per side. Mod II was 100 TPI and stored 315k per side. Each of the
16 sectors contains 266 bytes of "user data," allowing 10 bytes of metadata for
use by the operating system. Micropolis DOS (MDOS) used the metadata bytes, but
CP/M did not.
Some later systems were Micropolis-compatible and so were also 100 TPI, like
the Vector Graphic Dual-Mode Disk Controller which was paired with a Tandon
drive.
**Important note:** You _cannot_ read these disks with a normal PC drive, as
these drives are 96tpi. The track spacing is determined by the physical geometry
of the drive and can't be changed in software. You'll need to get hold of a
100tpi Micropolis drive. Luckily these seem to use the same connector and
pinout as a 96tpi PC 5.25" drive. In use they should be identical.
While most operating systems use the standard Micropolis checksum, Vector
Graphic MZOS uses a unique checksum. The decoder will automatically detect
the checksum type in use; however, a specific checksum type may be forced
using the `--decoder.micropolis.checksum_type=TYPE` where TYPE is one of:
| Checksum | Description |
|------------|-----------------------------------------|
| AUTO | Automatically detect |
| MICROPOLIS | Standard Micropolis (MDOS, CP/M, OASIS) |
| MZOS | Vector Graphic MZOS |
Later versions of the Micropolis format supported ECC, especially in
controllers with HDD support. The ECC can detect and correct errors. However,
it is unclear what ECC algorithm was used by each vendor. ECC is disabled by
default, but available for checking and correcting using
`--decoder.micropolis.ecc_type=TYPE` and for writing from IMG files using
`--encoder.micropolis.ecc_type=TYPE`, where TYPE is one of:
| ECC | Description |
|--------|------------------------------------------|
| NONE | No ECC processing enabled |
| VECTOR | Vector Graphic Dual-Mode Disk Controller |
The [CP/M BIOS](https://www.seasip.info/Cpm/bios.html) defined SELDSK, SETTRK,
and SETSEC, but no function to select the head/side. Double-sided floppies
could be represented as having either twice the number of sectors, for CHS, or
twice the number of tracks, HCS; the second side's tracks in opposite order
logically followed the first side (e.g., tracks 77-153). Micropolis disks
tended to be the latter. FluxEngine always emits CHS format disks, so you may
need to apply extra options to change the format if desired.
## Options
- :
- `143`: 143kB 5.25" SSDD hard-sectored; Micropolis MetaFloppy Mod I
- `287`: 287kB 5.25" DSDD hard-sectored; Micropolis MetaFloppy Mod I
- `315`: 315kB 5.25" SSDD hard-sectored; Micropolis MetaFloppy Mod II
- `630`: 630kB 5.25" DSDD hard-sectored; Micropolis MetaFloppy Mod II
- `vgi`: Read/write VGI format images with 275 bytes per sector
## Examples
To read:
- `fluxengine read micropolis -s drive:0 -o micropolis.img`
To write:
- `fluxengine write micropolis -d drive:0 -i micropolis.img`
## References
- [Micropolis 1040/1050 S-100 Floppy Disk Subsystems User's Manual][micropolis1040/1050].
Section 6, pages 261-266. Documents pre-ECC sector format. Note that the
entire record, starting at the sync byte, is controlled by software
- [Vector Graphic Dual-Mode Disk Controller Board Engineering Documentation][vectordualmode].
Section 1.6.2. Documents ECC sector format
- [AltairZ80 Simulator Usage Manual][altairz80]. Section 10.6. Documents ECC
sector format and VGI file format
[micropolis1040/1050]: http://www.bitsavers.org/pdf/micropolis/metafloppy/1084-01_1040_1050_Users_Manual_Apr79.pdf
[vectordualmode]: http://bitsavers.org/pdf/vectorGraphic/hardware/7200-1200-02-1_Dual-Mode_Disk_Controller_Board_Engineering_Documentation_Feb81.pdf
[altairz80]: http://www.bitsavers.org/simh.trailing-edge.com_201206/pdf/altairz80_doc.pdf

35
doc/disk-ms2000.md
View File

@@ -1,2 +1,33 @@
-d
\r
ms2000
====
## MS2000 Microdisk Development System
<!-- This file is automatically generated. Do not edit. -->
The RCA MicroDisk Development System MS2000 is a highly obscure (i.e. I gather
that single digit numbers of original machines exist) development system for the
RCA1802 series of CPUs, as made famous by the Cosmac ELF. It was a fairly
straightforward big bag o'RAM system with a 2kB boot ROM, 62kB of RAM, twin
floppy drives and a serial terminal --- CP/M users will find it very familiar.
Read and writing disks is currently not supported by FluxEngine, but there is
basic support for the MicroDisk operating system's file system. This should
allow files to be read from MS2000 disk images.
The disks are normal DD 3.5" disks, using a 70-track, single sided variation of
the venerable IBM floppy disk scheme, so allowing 315kB of storage per disk.
If you have access to flux files for MS2000 disks, please [get in
touch](https://github.com/davidgiven/cpm65/issues/new) --- I would like to add
better support for these.
## Options
(no options)
## Examples
## References
- [The EMMA-02 emulator](https://www.emma02.hobby-site.com/ms2000.html), which
supports the MS2000 and provides information on it.

71
doc/disk-mx.md
View File

@@ -1,2 +1,69 @@
-d
\r
mx
====
## Soviet-era PDP-11 clone
<!-- This file is automatically generated. Do not edit. -->
The DVK (in Russian, 沾7d65
Computing Complex) was a late 1970s Soviet personal computer, a cut-down
version of the professional SM EVM (ⵁ241c
--- literally System of Mini Computers), which _itself_ was an unlicensed
clone of the PDP-11. The MX board was an early floppy drive controller board
for it.
<div style="text-align: center">
<a href="http://www.leningrad.su/museum/show_big.php?n=1006"><img src="dvk3m.jpg" style="max-width: 60%" alt="A DVK computer"></a>
</div>
The MX format is interesting in that it has to be read a track at a time. The
format contains the usual ID prologue at the beginning of the track, then
eleven data blocks and checksums, then the epilogue, then it stops. The
actual encoding is normal FM. There were four different disk variants, in all
combinations of single- and double-sided and 40- and 80-tracked; but every
track contained eleven 256-byte sectors.
The format varies subtly depending on whether you're using the 'new' driver
or the 'old' driver. FluxEngine should read both.
A track is:
* 8 x 0x0000 words (FM encoded as 01010101...)
* 1 x 0x00F3 --- start of track
* 1 x 0xnnnn --- track number
* 11 of:
* 128 words (256 bytes) of data
* 16 bit checksum
* **if 'new' format:**
* 3 x 0x83nn --- `n = (track_number<<1) + side_number`
* **if 'old' format:**
* 3 x 0x8301
The checksum is just the unsigned integer sum of all the words in the sector.
Words are all stored little-endian.
## Options
- Format variants:
- `110`: 110kB 5.25" 40-track SSSD
- `220ds`: 220kB 5.25" 40-track DSSD
- `220ss`: 220kB 5.25" 80-track SSSD
- `440`: 440kB 5.25" 80-track DSSD
## Examples
To read:
- `fluxengine read mx --110 -s drive:0 -o mx.img`
- `fluxengine read mx --220ds -s drive:0 -o mx.img`
- `fluxengine read mx --220ss -s drive:0 -o mx.img`
- `fluxengine read mx --440 -s drive:0 -o mx.img`
## References
- [The Soviet Digital Electronics
Museum](http://www.leningrad.su/museum/main.php) (source of the image
above)
- [a random post on the HxC2001 support
forum](http://torlus.com/floppy/forum/viewtopic.php?t=1384) with lots of
information on the format

28
doc/disk-n88basic.md
View File

@@ -1,2 +1,26 @@
-d
\r
n88basic
====
## PC8800/PC98 5.25" 77-track 26-sector DSHD
<!-- This file is automatically generated. Do not edit. -->
The N88-BASIC disk format is the one used by the operating system of the same
name for the Japanese PC8800 and PC98 computers. It is another IBM scheme
variant, and is very similar to some mixed-format CP/M disk formats, where
track 0 side 0 uses 128-byte single density sectors and the rest of the disk
uses 512-byte double density sectors. (The reason for this is that the PC8800
boot ROM could only read single density data.)
## Options
(no options)
## Examples
To read:
- `fluxengine read n88basic -s drive:0 -o n88basic.img`
To write:
- `fluxengine write n88basic -d drive:0 -i n88basic.img`

52
doc/disk-northstar.md
View File

@@ -1,2 +1,50 @@
-d
\r
northstar
====
## 5.25" hard sectored
<!-- This file is automatically generated. Do not edit. -->
Northstar Floppy disks use 10-sector hard sectored disks with either FM or MFM
encoding. They may be single- or double-sided. Each of the 10 sectors contains
256 (FM) or 512 (MFM) bytes of data. The disk has 35 cylinders, with tracks 0-
34 on side 0, and tracks 35-69 on side 1. Tracks on side 1 are numbered "back-
wards" in that track 35 corresponds to cylinder 34, side 1, and track 69
corresponds to cylinder 0, side 1.
The Northstar sector format does not include any head positioning information.
As such, reads from Northstar floppies need to by synchronized with the index
pulse, in order to properly identify the sector being read. This is handled
automatically by FluxEngine.
Due to the nature of the track ordering on side 1, an .nsi image reader and
writer are provided for double-sided disks. The .nsi image writer supports
both single- and double-sided disks; however single-sided .nsi images are
equivalent to .img images.
## Options
- Format variants:
- `87`: 87.5kB 5.25" 35-track SSSD hard-sectored
- `175`: 175kB 5.25" 40-track SSDD hard-sectored
- `350`: 350kB 5.25" 40-track DSDD hard-sectored
## Examples
To read:
- `fluxengine read northstar --87 -s drive:0 -o northstar.nsi`
- `fluxengine read northstar --175 -s drive:0 -o northstar.nsi`
- `fluxengine read northstar --350 -s drive:0 -o northstar.nsi`
To write:
- `fluxengine write northstar --87 -d drive:0 -i northstar.nsi`
- `fluxengine write northstar --175 -d drive:0 -i northstar.nsi`
- `fluxengine write northstar --350 -d drive:0 -i northstar.nsi`
## References
- [MICRO-DISK SYSTEM MDS-A-D DOUBLE DENSITY Manual][northstar_mds].
Page 33 documents sector format for single- and double-density.
[northstar_mds]: http://bitsavers.org/pdf/northstar/boards/Northstar_MDS-A-D_1978.pdf

34
doc/disk-psos.md
View File

@@ -1,2 +1,32 @@
-d
\r
psos
====
## 800kB DSDD with PHILE
<!-- This file is automatically generated. Do not edit. -->
pSOS was an influential real-time operating system from the 1980s, used mainly
on 68000-based machines, lasting up until about 2000 when it was bought (and
cancelled) by Wind River. It had its own floppy disk format and file system,
both of which are partially supported here.
The PHILE file system is almost completely undocumented and so many of the data
structures have had to be reverse engineered and are not well known. Please
[get in touch](https://github.com/davidgiven/fluxengine/issues/new) if you know
anything about it.
The floppy disk format itself is an IBM scheme variation with 1024-byte sectors
and, oddly, swapped sides.
## Options
(no options)
## Examples
To read:
- `fluxengine read psos -s drive:0 -o pme.img`
To write:
- `fluxengine write psos -d drive:0 -i pme.img`

50
doc/disk-rolandd20.md
View File

@@ -1,2 +1,48 @@
-d
\r
rolandd20
====
## 3.5" electronic synthesiser disks
<!-- This file is automatically generated. Do not edit. -->
The Roland D20 is a classic electronic synthesiser with a built-in floppy
drive, used for saving MIDI sequences and samples.
Weirdly, it seems to use precisely the same format as the Brother word
processors: a thoroughly non-IBM-compatible custom GCR system.
FluxEngine supports both reading and writing D20 disks, as well as basic support
for the filesystem, allowing files to be read from and written to D20 disks.
Note that the D20 was never intended to support arbitrary files on its disks and
is very likely to crash if you put unexpected files on a disk. In addition,
while the file format itself is currently unknown, there is a header at the top
of the file containing what appears to be the name shown in the D20 file
browser, so the name by which you see it is not necessarily the filename.
A word of warning --- just like the Brother word processors, the D20 floppy
drive isn't very well aligned. The drive itself uses quarter-stepping to
automatically adapt to whatever alignment the disk was formatted with. This
means that trying to read such a disk on a PC drive, which does _not_ have
adjustable alignment, may not work very well. In these situations it is possible
to adjust the alignment of most modern drives, but this is a somewhat risky
process and may result in permanently wrecking the drive alignment.
Please [get in touch](https://github.com/davidgiven/fluxengine/issues/new) if
you know anything about it.
Many thanks to trondl [on the VCF
forums](https://forum.vcfed.org/index.php?threads/roland-d-20-decoding-the-mysterious-floppy-format.1243226/)
for assistance with this!
## Options
(no options)
## Examples
To read:
- `fluxengine read rolandd20 -s drive:0 -o rolandd20.img`
To write:
- `fluxengine write rolandd20 -d drive:0 -i rolandd20.img`

25
doc/disk-rx50.md
View File

@@ -1,2 +1,23 @@
-d
\r
rx50
====
## 400kB 5.25" 80-track 10-sector SSDD
<!-- This file is automatically generated. Do not edit. -->
The Digital RX50 is one of the external floppy drive units used by Digital's
range of computers, especially the DEC Rainbow microcomputer. It is a fairly
vanilla single-sided IBM scheme variation.
## Options
(no options)
## Examples
To read:
- `fluxengine read rx50 -s drive:0 -o rx50.img`
To write:
- `fluxengine write rx50 -d drive:0 -i rx50.img`

17
doc/disk-shugart_drive.md
View File

@@ -1,2 +1,15 @@
-d
\r
shugart_drive
====
## Adjust configuration for a Shugart drive
<!-- This file is automatically generated. Do not edit. -->
This is an extension profile; adding this to the command line will configure
FluxEngine to adjust the pinout to work with a Shugart drive. This only works
on Greaseweazle hardware.
For example:
```
fluxengine read ibm --720 shugart_drive
```

36
doc/disk-smaky6.md
View File

@@ -1,2 +1,34 @@
-d
\r
smaky6
====
## 308kB 5.25" 77-track 16-sector SSDD, hard sectored
<!-- This file is automatically generated. Do not edit. -->
The Smaky 6 is a Swiss computer from 1978 produced by Epsitec. It's based
around a Z80 processor and has one or two Micropolis 5.25" drives which use
16-sector hard sectored disks. The disk format is single-sided with 77 tracks
and 256-byte sectors, resulting in 308kB disks. It uses MFM with a custom
sector record scheme. It was later superceded by a 68000-based Smaky which used
different disks.
FluxEngine supports these, although because the Micropolis drives use a 100tpi
track pitch, you can't read Smaky 6 disks with a normal PC 96tpi drive. You
will have to find a 100tpi drive from somewhere (they're rare).
There is experimental read-only support for the Smaky 6 filesystem, allowing
the directory to be listed and files read from disks. It's not known whether
this is completely correct, so don't trust it!
## Options
(no options)
## Examples
To read:
- `fluxengine read smaky6 -s drive:0 -o smaky6.img`
## References
- [Smaky Info, 1978-2002 (in French)](https://www.smaky.ch/theme.php?id=sminfo)

50
doc/disk-tartu.md
View File

@@ -1,2 +1,48 @@
-d
\r
tartu
====
## The Palivere and variations
<!-- This file is automatically generated. Do not edit. -->
The Tartu Palivere is a 1988 Z80-based computer from Estonia. It is a CP/M
machine with 64kB of RAM, running off a 2MHz ꃣ0e30
clone; it operated off punched tape, cassette, external hard drive or floppy, and was notable as being the first ever computer with an Estonian keyboard.
<div style="text-align: center">
<img src="tartu.jpg" alt="The Tartu computer's developer Leo Humal working with one."/>
</div>
From a floppy disk perspective, it is interesting because the floppy drive
interface is almost entirely handled in software --- necessary at the time as
the usual floppy disk interface chip at the time, the ⎲fba5
of the WD1793), was hard to find. Instead, the floppy controller board was
implemented entirely using TTL logic. Despite this, the encoding is fairly high
density, using MFM and with up to 780kB on a double-sided 80 track disk.
<div style="text-align: center">
<img src="tartu-fdc.jpg" alt="The Tartu FDC with Soviet TTL logic chips."/>
</div>
FluxEngine supports reading and writing Tartu disks with CP/M filesystem access.
## Options
- Format variants:
- `390`: 390kB 5.25" 40-track DSDD
- `780`: 780kB 5.25" 80-track DSDD
## Examples
To read:
- `fluxengine read tartu --390 -s drive:0 -o tartu.img`
- `fluxengine read tartu --780 -s drive:0 -o tartu.img`
To write:
- `fluxengine write tartu --390 -d drive:0 -i tartu.img`
- `fluxengine write tartu --780 -d drive:0 -i tartu.img`
## References
- [The Estonia Museum of Electronics](https://www.elektroonikamuuseum.ee/tartu_arvuti_lugu.html)

41
doc/disk-tids990.md
View File

@@ -1,2 +1,39 @@
-d
\r
tids990
====
## 1126kB 8" DSSD
<!-- This file is automatically generated. Do not edit. -->
The Texas Instruments DS990 was a multiuser modular computing system from 1998,
based around the TMS-9900 processor (as used by the TI-99). It had an 8" floppy
drive module, the FD1000, which was a 77-track, 288-byte sector FM/MFM system
with 26 sectors per track. The encoding scheme was very similar to a simplified
version of the IBM scheme, but of course not compatible. A double-sided disk
would store a very satisfactory 1126kB of data; here's one at <a
href="https://www.old-computers.com/museum/computer.asp?st=1&c=1025">old-computers.com</a>:
<div style="text-align: center">
<a href="https://www.old-computers.com/museum/computer.asp?st=1&c=1025">
<img src="tids990.jpg" style="max-width: 60%" alt="A DS990 at old-computers.com"></a>
</div>
FluxEngine will read and write these (but only the DSDD MFM variant).
## Options
(no options)
## Examples
To read:
- `fluxengine read tids990 -s drive:0 -o tids990.img`
To write:
- `fluxengine write tids990 -d drive:0 -i tids990.img`
## References
- [The FD1000 Depot Maintenance
Manual](http://www.bitsavers.org/pdf/ti/990/disk/2261885-9701_FD1000depotVo1_Jan81.pdf)

29
doc/disk-tiki.md
View File

@@ -1,2 +1,27 @@
-d
\r
tiki
====
## CP/M
<!-- This file is automatically generated. Do not edit. -->
The Tiki 100 is a Z80-based Norwegian microcomputer from the mid 1980s intended
for eductional use. It mostly ran an unbranded CP/M clone, and uses fairly
normal CP/M disks --- IBM scheme and from 128 to 512 bytes per sector depending
on the precise format.
## Options
- Format variants:
- `90`: 90kB 40-track 18-sector SSSD
- `200`: 200kB 40-track 10-sector SSDD
- `400`: 400kB 40-track 10-sector DSDD
- `800`: 800kB 80-track 10-sector DSDD
## Examples
To read:
- `fluxengine read tiki --90 -s drive:0 -o tiki.img`
- `fluxengine read tiki --200 -s drive:0 -o tiki.img`
- `fluxengine read tiki --400 -s drive:0 -o tiki.img`
- `fluxengine read tiki --800 -s drive:0 -o tiki.img`

64
doc/disk-victor9k.md
View File

@@ -1,2 +1,62 @@
-d
\r
victor9k
====
## 1224kB 5.25" DSDD GCR
<!-- This file is automatically generated. Do not edit. -->
The Victor 9000 / Sirius One was a rather strange old 8086-based machine
which used a disk format very reminiscent of the Commodore format; not a
coincidence, as Chuck Peddle designed them both. They're 80-track, 512-byte
sector GCR disks, with a variable-speed drive and a varying number of sectors
per track --- from 19 to 12. Disks can be double-sided, meaning that they can
store 1224kB per disk, which was almost unheard of back then. Because the way
that the tracks on head 1 are offset from head 0 (this happens with all disks),
the speed zone allocation on head 1 differs from head 0...
| Zone | Head 0 tracks | Head 1 tracks | Sectors | Original period (ms) |
|:----:|:-------------:|:-------------:|:-------:|:--------------------:|
| 0 | 0-3 | | 19 | 237.9 |
| 1 | 4-15 | 0-7 | 18 | 224.5 |
| 2 | 16-26 | 8-18 | 17 | 212.2 |
| 3 | 27-37 | 19-29 | 16 | 199.9 |
| 4 | 38-47\* | 30-39\* | 15 | 187.6 |
| 5 | 48-59 | 40-51 | 14 | 175.3 |
| 6 | 60-70 | 52-62 | 13 | 163.0 |
| 7 | 71-79 | 63-74 | 12 | 149.6 |
| 8 | | 75-79 | 11 | 144.0 |
(The Original Period column is the original rotation rate. When used in
FluxEngine, the disk always spins at 360 rpm, which corresponds to a rotational
period of 166 ms.)
\*The Victor 9000 Hardware Reference Manual has a bug in the documentation
and lists Zone 4 as ending with track 48 on head 0 and track 40 on head 1.
The above table matches observed data on various disks and the assembly
code in the boot loader, which ends Zone 4 with track 47 on head 0
and track 39 on Head 1.
FluxEngine can read and write both the single-sided and double-sided variants.
## Options
- Format variants:
- `612`: 612kB 80-track DSHD GCR
- `1224`: 1224kB 80-track DSHD GCR
## Examples
To read:
- `fluxengine read victor9k --612 -s drive:0 -o victor9k.img`
- `fluxengine read victor9k --1224 -s drive:0 -o victor9k.img`
To write:
- `fluxengine write victor9k --612 -d drive:0 -i victor9k.img`
- `fluxengine write victor9k --1224 -d drive:0 -i victor9k.img`
## References
- [The Victor 9000 technical reference manual](http://bitsavers.org/pdf/victor/victor9000/Victor9000TechRef_Jun82.pdf)
- [DiskFerret's Victor 9000 format guide](https://discferret.com/wiki/Victor_9000_format)

44
doc/disk-zilogmcz.md
View File

@@ -1,2 +1,42 @@
-d
\r
zilogmcz
====
## 320kB 8" 77-track SSSD hard-sectored
<!-- This file is automatically generated. Do not edit. -->
The Zilog MCZ is an extremely early Z80 development system, produced by
Zilog, which came out in 1976. It used twin 8-inch hard sectored floppy
drives; here's one at the <a
href="http://www.computinghistory.org.uk/det/12157/Zilog-Z-80-Microcomputer-System/">Centre
for Computing History</a>:
<div style="text-align: center">
<a href="http://www.computinghistory.org.uk/det/12157/Zilog-Z-80-Microcomputer-System/">
<img src="zilogmcz.jpg" style="max-width: 60%" alt="A Zilog MCZ at the Centre For Computing History"></a>
</div>
The MCZ ran Zilog's own operating system, Z80-RIO, and used 77 track
single-sided disks, with 32 sectors (each marked by an index hole), with 132
bytes per sector --- 128 bytes of user payload plus two two-byte metadata
words used to construct linked lists of sectors for storing files. These
stored 320kB each.
FluxEngine has read support for these, including support for RIO's ZDOS file
system.
## Options
(no options)
## Examples
To read:
- `fluxengine read zilogmcz -s drive:0 -o zilogmcz.img`
## References
* [About the Zilog MCZ](http://www.retrotechnology.com/restore/zilog.html),
containing lots of useful links
* [The hardware user's manual](https://amaus.org/static/S100/zilog/ZDS/Zilog%20ZDS%201-25%20Hardware%20Users%20Manual.pdf)