mirror of
https://github.com/davidgiven/fluxengine.git
synced 2025-10-31 11:17:01 -07:00
First pass at automatic document generation.
This commit is contained in:
dg
2
Makefile
2
Makefile
@@ -98,7 +98,7 @@ $(2): private CFLAGS += $(shell $(PKG_CONFIG) --cflags $(3))
|
||||
endef
|
||||
|
||||
.PHONY: all binaries tests clean install install-bin
|
||||
all: binaries tests
|
||||
all: binaries tests docs
|
||||
|
||||
PROTOS = \
|
||||
arch/aeslanier/aeslanier.proto \
|
||||
|
||||
@@ -1,39 +0,0 @@
|
||||
Disk: Acorn ADFS
|
||||
================
|
||||
|
||||
Acorn ADFS disks are pretty standard 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.
|
||||
Tested ones are:
|
||||
|
||||
- ADFS L: 80 track, 16 sector, 2 sides, 256 bytes per sector == 640kB.
|
||||
- ADFE D/E: 80 track, 5 sector, 2 sides, 1024 bytes per sector == 800kB.
|
||||
- ADFS F: 80 track, 10 sector, 2 sides, 1024 bytes per sector == 1600kB.
|
||||
|
||||
I expect the others to work, but haven't tried them; [get in
|
||||
touch](https://github.com/davidgiven/fluxengine/issues/new) if you have any
|
||||
news. For ADFS S (single-sided 40 track) you'll want `--heads 0 --cylinders
|
||||
0-79x2`. For ADFS M (single-sided 80 track) you'll want `--heads 0`.
|
||||
|
||||
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.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read acornadfs
|
||||
```
|
||||
|
||||
You should end up with an `acornadfs.img` of the appropriate size for your disk
|
||||
format. This is an alias for `fluxengine read ibm` with preconfigured
|
||||
parameters.
|
||||
@@ -1,34 +0,0 @@
|
||||
Disk: Acorn DFS
|
||||
===============
|
||||
|
||||
Acorn DFS disks 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 drive. FluxEngine supports these; read one side at a time
|
||||
with `--heads 0` or `--heads 1`.
|
||||
|
||||
DFS comes in two varieties, 40 track and 80 track. These should both work. For
|
||||
40 track you'll want `--cylinders 0-79x2`. 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.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read acorndfs
|
||||
```
|
||||
|
||||
You should end up with an `acorndfs.img` of the appropriate size for your disk
|
||||
format. This is an alias for `fluxengine read ibm` with preconfigured
|
||||
parameters.
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
- [The Acord DFS disc format](https://beebwiki.mdfs.net/Acorn_DFS_disc_format)
|
||||
|
||||
@@ -1,44 +0,0 @@
|
||||
Disk: AES Lanier word processor
|
||||
===============================
|
||||
|
||||
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 £13,000 in 1981 (the equivalent
|
||||
of nearly £50,000 in 2018!).
|
||||
|
||||
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).
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read aeslanier
|
||||
```
|
||||
|
||||
You'll end up with an `aeslanier.img` file.
|
||||
|
||||
Useful 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.
|
||||
@@ -1,34 +0,0 @@
|
||||
Disk: Agat
|
||||
==========
|
||||
|
||||
The Agat (Russian: Агат) was a series Soviet-era computer, first released about
|
||||
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 [Apple II
|
||||
profile](disk-apple2.md).
|
||||
|
||||
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read agat840
|
||||
```
|
||||
|
||||
You should end up with an `agat840.img` which is 860160 bytes long.
|
||||
|
||||
|
||||
Useful 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)
|
||||
@@ -1,65 +0,0 @@
|
||||
Disk: Amiga
|
||||
===========
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read amiga
|
||||
```
|
||||
|
||||
You should end up with an `amiga.adf` which is 901120 bytes long (for a
|
||||
normal DD disk) --- it ought to be a perfectly normal ADF file which you can
|
||||
use in an emulator.
|
||||
|
||||
If you want the metadata as well, specify a 528 byte sector size for the
|
||||
output image:
|
||||
|
||||
```
|
||||
fluxengine read amiga -o amiga.adf --output.image.img.trackdata.sector_size=528
|
||||
```
|
||||
|
||||
You will end up with a 929280 byte long image which you probably _can't_ use
|
||||
in an emulator; each sector will contain the 512 bytes of user payload
|
||||
followed by the 16 bytes of metadata.
|
||||
|
||||
Writing disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine write amiga -i amiga.adf
|
||||
```
|
||||
|
||||
This will take a normal 901120 byte long ADF file and write it to a DD disk.
|
||||
Note that writing to an HD disk will probably not work (this will depend on
|
||||
your drive and disk and potential FluxEngine bugs I'm still working on ---
|
||||
please [get in touch](https://github.com/davidgiven/fluxengine/issues/new) if
|
||||
you have any insight here).
|
||||
|
||||
If you want to write the metadata as well, specify a 528 byte sector size for
|
||||
the output image and supply a 929280 byte long file as described above.
|
||||
|
||||
```
|
||||
fluxengine write amiga -i amiga.adf --input.image.img.trackdata.sector_size=528
|
||||
```
|
||||
|
||||
Useful 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)
|
||||
@@ -1,51 +0,0 @@
|
||||
Disk: Ampro Little Board
|
||||
========================
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read ampro <format>
|
||||
```
|
||||
|
||||
...where `<format>` is one of `--400` for a 40-track disk or `--800` for an
|
||||
80-track disk. These are an alias for `fluxengine read ibm` with preconfigured
|
||||
parameters.
|
||||
|
||||
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...
|
||||
```
|
||||
|
||||
Useful references
|
||||
-----------------
|
||||
|
||||
- [The Ampro Little Board](http://oldcomputers.net/ampro-little-board.html)
|
||||
@@ -1,100 +0,0 @@
|
||||
Disk: Apple II
|
||||
==============
|
||||
|
||||
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 these
|
||||
options:
|
||||
|
||||
- `--appledos` Selects AppleDOS sector translation
|
||||
- `--prodos` Selects ProDOS sector translation
|
||||
- `--cpm` Selects CP/M SoftCard sector translation[^1][^2]
|
||||
|
||||
These options also select the appropriate file system; FluxEngine has read-only
|
||||
support for all of these. For example:
|
||||
|
||||
```
|
||||
fluxengine ls apple2 --appledos -f image.flux
|
||||
```
|
||||
|
||||
In addition, some third-party systems use 80-track double sides drives, with
|
||||
the same underlying disk format. The full list of formats supported is:
|
||||
|
||||
- `--140` 35-track single-sided (the normal Apple II format)
|
||||
- `--640` 80-track double-sided
|
||||
|
||||
`--140` is the default.
|
||||
|
||||
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. To access these
|
||||
files, use `--640 --appledos --side1`.
|
||||
|
||||
[^1]: CP/M disks use the ProDOS translation for the first three tracks and a
|
||||
different translation for all the tracks thereafter.
|
||||
|
||||
[^2]: 80-track CP/M disks are interesting because all the tracks on the second
|
||||
side have on-disk track numbering from 80..159; the Apple II on-disk format
|
||||
doesn't have a side byte, so presumably this is to allow tracks on the two
|
||||
sides to be distinguished from each other. AppleDOS and ProDOS disks don't
|
||||
do this.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read apple2
|
||||
```
|
||||
|
||||
(or `apple2 --640`)
|
||||
|
||||
You should end up with an `apple2.img` which is 143360 bytes long. It will
|
||||
be in physical sector ordering if you don't specify a file system format as
|
||||
described above.
|
||||
|
||||
Writing discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
```
|
||||
fluxengine write apple2 -i apple2.img
|
||||
```
|
||||
|
||||
The image will be expected to be in physical sector ordering if you don't
|
||||
specify a file system format as described above.
|
||||
|
||||
Useful 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)
|
||||
@@ -1,73 +0,0 @@
|
||||
Disk: Atari ST
|
||||
==============
|
||||
|
||||
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.
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
fluxengine read <format>
|
||||
|
||||
...and you'll end up with an `atarist.st` file. The size of the disk image will
|
||||
vary depending on the format. This is an alias for `fluxengine read ibm` with
|
||||
preconfigured parameters.
|
||||
|
||||
Note that the profile by default assumes a double-sided disk; if you're reading
|
||||
a single-sided disk, add `--heads 0` to prevent FluxEngine from looking at the
|
||||
other side and getting confused by any data it sees there.
|
||||
|
||||
Writing disks
|
||||
-------------
|
||||
|
||||
FluxEngine can also write Atari ST scheme disks.
|
||||
|
||||
The syntax is:
|
||||
|
||||
fluxengine write atarist -i input.st <format>
|
||||
|
||||
Available formats
|
||||
-----------------
|
||||
|
||||
`<format>` can be one of these:
|
||||
|
||||
- `--360`: a 360kB 3.5" disk, with 80 cylinders, 1 side, and 9 sectors per
|
||||
track.
|
||||
- `--370`: a 370kB 3.5" disk, with 82 cylinders, 1 side, and 9 sectors per
|
||||
track.
|
||||
- `--400`: a 400kB 3.5" disk, with 80 cylinders, 1 side, and 10 sectors per
|
||||
track.
|
||||
- `--410`: a 410kB 3.5" disk, with 82 cylinders, 1 side, and 10 sectors per
|
||||
track.
|
||||
- `--720`: a 720kB 3.5" disk, with 80 cylinders, 2 sides, and 9 sectors per
|
||||
track.
|
||||
- `--740`: a 740kB 3.5" disk, with 82 cylinders, 2 sides, and 9 sectors per
|
||||
track.
|
||||
- `--800`: a 800kB 3.5" disk, with 80 cylinders, 2 sides, and 10 sectors per
|
||||
track.
|
||||
- `--820`: a 820kB 3.5" disk, with 82 cylinders, 2 sides, and 10 sectors per
|
||||
track.
|
||||
|
||||
See [the IBM format documentation](disk-ibm.md) for more information. Note that
|
||||
only some PC 3.5" floppy disk drives are capable of seeking to the 82nd track.
|
||||
|
||||
|
||||
Useful 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
|
||||
@@ -1,37 +0,0 @@
|
||||
Disk: Elektronica BK
|
||||
====================
|
||||
|
||||
The BK (an abbreviation for бытовой компьютер --- 'home computer' in Russian)
|
||||
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.
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read bk800 -o bk800.img
|
||||
```
|
||||
|
||||
You should end up with an `bk800.img` containing all the sectors concatenated
|
||||
one after the other in CHS order. This will work on both 5.25" and 3.5" drives.
|
||||
|
||||
Writing disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine write bk800 -i bk800.img
|
||||
```
|
||||
|
||||
This will write the disk image to either a 5.25" or 3.5" drive.
|
||||
|
||||
@@ -1,174 +0,0 @@
|
||||
Disk: Brother word processor
|
||||
============================
|
||||
|
||||
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`.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read brother `<format>`
|
||||
```
|
||||
|
||||
... where `<format>` can be `--120` or `--240`. You should end up
|
||||
with a `brother.img` which is either 119808 or 239616 bytes long.
|
||||
|
||||
Writing disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine write `<format>` -i brother.img
|
||||
```
|
||||
|
||||
...where `<format>` can be `--120` or `--240`.
|
||||
|
||||
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. I have reversed engineered
|
||||
a very simple tool for extracting files from it. To show the directory, do:
|
||||
|
||||
```
|
||||
brother120tool image.img
|
||||
```
|
||||
|
||||
To extract a file, do:
|
||||
|
||||
```
|
||||
brother120tool image.img filename
|
||||
```
|
||||
|
||||
Wildcards are supported, so use `'*'` for the filename (remember to quote it)
|
||||
if you want to extract everything.
|
||||
|
||||
The files are usually in the format known as WP-1, which aren't well
|
||||
supported by modern tools (to nobody's great surprise). Matthias Henckell has
|
||||
[reverse engineered the file
|
||||
format](https://mathesoft.eu/brother-wp-1-dokumente/) and has produced a
|
||||
(Windows-only, but runs in Wine) [tool which will convert these files into
|
||||
RTF](https://mathesoft.eu/sdm_downloads/wp2rtf/). This will only work on WP-1
|
||||
files.
|
||||
|
||||
To create a disk image (note: this creates a _new_ disk image, overwriting the
|
||||
previous image), do:
|
||||
|
||||
```
|
||||
brother120tool --create image.img filename1 filename2...
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
Any questions? please [get in
|
||||
touch](https://github.com/davidgiven/fluxengine/issues/new).
|
||||
|
||||
### 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. Once done, this will work:
|
||||
|
||||
```
|
||||
mdir -i brother.img
|
||||
mcopy -i brother.img ::brother.doc linux.doc
|
||||
```
|
||||
|
||||
The word processor checks the media byte, unfortunately, so you'll need to
|
||||
change it back to 0x58 before writing an image to disk. Just run
|
||||
`brother240tool` on the image again and it will flip it back.
|
||||
|
||||
The file format is not WP-1, and currently remains completely unknown,
|
||||
although it's probably related. If anyone knows anything about this, please
|
||||
[get in touch](https://github.com/davidgiven/fluxengine/issues/new).
|
||||
102
doc/disk-c64.md
102
doc/disk-c64.md
@@ -1,102 +0,0 @@
|
||||
Disk: Commodore 64
|
||||
==================
|
||||
|
||||
Commodore 64 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 standard 1541 disk has 35 tracks of 17 to 21 sectors, each 256 bytes long
|
||||
(sometimes 40 tracks).
|
||||
|
||||
A standard 1581 disk has 80 tracks and two sides, each with 10 sectors, 512
|
||||
bytes long.
|
||||
|
||||
Reading 1541 disks
|
||||
------------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read commodore -o commodore.d64
|
||||
```
|
||||
|
||||
You should end up with an `commodore.d64` file which is 174848 bytes long.
|
||||
You can load this straight into a Commodore 64 emulator such as
|
||||
[VICE](http://vice-emu.sourceforge.net/).
|
||||
|
||||
If you have a 40-track disk, add `--196`.
|
||||
|
||||
**Big warning!** Commodore 64 disk images are complicated due to the way the
|
||||
tracks are different sizes and the odd sector size, so you need the special D64
|
||||
or LDBS output formats to represent them sensibly.
|
||||
|
||||
Writing 1541 disks
|
||||
------------------
|
||||
|
||||
Just do:
|
||||
```
|
||||
fluxengine write commodore -i file.d64
|
||||
```
|
||||
|
||||
If you have a 40-track disk, add `--196`.
|
||||
|
||||
Note that only standard Commodore 64 BAM file systems can be written this way,
|
||||
as the disk ID in the BAM has to be copied to every sector on the disk.
|
||||
|
||||
Reading and writing 1581 disks
|
||||
------------------------------
|
||||
|
||||
1581 disks are just another version of the standard IBM scheme.
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read commodore1581 -o commodore1581.d81
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```
|
||||
fluxengine write commodore1581 -i commodore1581.img
|
||||
```
|
||||
|
||||
Reading and writing CMD FD2000 disks
|
||||
------------------------------------
|
||||
|
||||
Yet again, these are another IBM scheme variant.
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read cmd_fd2000 -o cmd_fd2000.d81
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```
|
||||
fluxengine write cmd_fd2000 -i cmd_fd2000.img
|
||||
```
|
||||
|
||||
|
||||
Useful references
|
||||
-----------------
|
||||
|
||||
- [Ruud's Commodore Site: 1541](http://www.baltissen.org/newhtm/1541c.htm):
|
||||
documentation on the 1541 disk format.
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
Disk: Durango F85
|
||||
=================
|
||||
|
||||
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).
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read f85
|
||||
```
|
||||
|
||||
You should end up with an `f85.img` which is 472064 bytes long.
|
||||
|
||||
Useful references
|
||||
-----------------
|
||||
|
||||
There's amazingly little information about these things.
|
||||
|
||||
* [Chuck Guzis' F85 page](http://www.sydex.com/durango/durango.html) with lots of pictures
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
Disk: VDS Eco1
|
||||
==============
|
||||
|
||||
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.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read eco1 -o eco1.img
|
||||
```
|
||||
|
||||
You should end up with an `eco1.img` of 1255168 bytes, containing all the
|
||||
sectors concatenated one after the other in CHS order, with no padding.
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
- [Apulio Retrocomputing's page on the Eco1](https://www.apuliaretrocomputing.it/wordpress/?p=8976)
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
Disk: Brother FB-100
|
||||
====================
|
||||
|
||||
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.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read fb100
|
||||
```
|
||||
|
||||
You should end up with an `fb100.img` of the appropriate size. It's a simple
|
||||
array of 80 1292-byte sectors (12 bytes for the ID record plus 1280 bytes for
|
||||
the data).
|
||||
|
||||
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)
|
||||
135
doc/disk-ibm.md
135
doc/disk-ibm.md
@@ -1,135 +0,0 @@
|
||||
Disk: Generic IBM
|
||||
=================
|
||||
|
||||
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](disk-acorndfs.md) 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.
|
||||
|
||||
The generic decoder is mostly self-configuring, and will detect the format of
|
||||
your disk for you.
|
||||
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
fluxengine read ibm `<format>`
|
||||
|
||||
...and you'll end up with an `ibm.img` file. You'll need to specify which
|
||||
format to use; this can be one of `--160`, `--180`, `--320`, `--360`, `--720`,
|
||||
`--1200`, `--1232`, `--1400` or `--1680` depending. The size of the disk image
|
||||
will vary depending on the format.
|
||||
|
||||
The common PC formats are `--720` and `--1440`, but there are _many_ others,
|
||||
and there's too many configuration options to usefully list. Use `fluxengine
|
||||
write` to list all formats, and try `fluxengine write ibm --1440 --config` to see
|
||||
a sample configuration.
|
||||
|
||||
Configuration options you'll want include:
|
||||
|
||||
- `--decoder.ibm.sector_id_base=N`: specifies the ID of the first sector;
|
||||
this defaults to 1. Some formats (like the Acorn ones) start at 0. This
|
||||
can't be autodetected because FluxEngine can't distinguish between a disk
|
||||
which starts at sector 1 and a disk which starts at sector 0 but all the
|
||||
sector 0s are missing.
|
||||
|
||||
- `--decoder.ibm.ignore_side_byte=true|false`: each sector header describes
|
||||
the location of the sector: sector ID, track and side. Some formats use the
|
||||
wrong side ID, so the sectors on side 1 are labelled as belonging to side
|
||||
0. This causes FluxEngine to see duplicate sectors (as it can't distinguish
|
||||
between the two sides). This option tells FluxEngine to ignore the side
|
||||
byte completely and use the physical side instead.
|
||||
|
||||
- `--decoder.ibm.required_sectors=range`: if you know how many sectors to
|
||||
expect per track, you can improve reads by telling FluxEngine what to
|
||||
expect here. If a track is read and a sector on this list is _not_ present,
|
||||
then FluxEngine assumes the read failed and will retry. This avoids the
|
||||
situation where FluxEngine can't tell the difference between a sector
|
||||
missing because it's bad or a sector missing because it was never written
|
||||
in the first place. If sectors are seen outside the range here, it will
|
||||
still be read. You can use the same syntax as for track specifiers: e.g.
|
||||
`0-9`, `0,1,2,3`, etc.
|
||||
|
||||
|
||||
Writing disks
|
||||
-------------
|
||||
|
||||
FluxEngine can also write IBM scheme disks. Unfortunately the format is
|
||||
incredibly flexible and you need to specify every single parameter, which
|
||||
makes things slightly awkward. Preconfigured profiles are available.
|
||||
|
||||
The syntax is:
|
||||
|
||||
fluxengine write ibm <format> -i input.img <options>
|
||||
|
||||
See above for the formats.
|
||||
|
||||
Some image formats, such as DIM, specify the image format, For these you can
|
||||
specify the `--auto` format (which is the default) and FluxEngine will
|
||||
automatically determine the correct format to use.
|
||||
|
||||
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.
|
||||
|
||||
@@ -1,88 +0,0 @@
|
||||
Disk: Macintosh
|
||||
===============
|
||||
|
||||
Macintosh disks come in two varieties: the newer 1440kB ones, which are
|
||||
perfectly ordinary PC disks you should use `fluxengine read ibm` to read, 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.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read mac <format> -o mac.dsk
|
||||
```
|
||||
|
||||
...where `<format>` can be `--400` or `--800`.
|
||||
|
||||
You should end up with a `mac.dsk` file containing a raw sector image
|
||||
(equivalent to `.img`).
|
||||
|
||||
The Mac disk format contains an extra twelve bytes of data per sector which can
|
||||
be used for filesystem metadata. In practice, this was never used by anyone,
|
||||
and so the default is to omit these. If you want them, specify that you want
|
||||
524 byte sectors with `--layout.layoutdata.sector_size=524`. The metadata will
|
||||
follow the
|
||||
512 bytes of user data.
|
||||
|
||||
FluxEngine also supports DiskCopy 4.2 disk images, which may be a better option
|
||||
if you're going to be using the image on a real Macintosh (or with other
|
||||
tooling which supports it). To get one of these, use a filename like
|
||||
`mac.diskcopy`. This will contain both user data and metadata.
|
||||
|
||||
Writing discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine write mac <format> -i mac.dsk
|
||||
```
|
||||
|
||||
...where `<format>` can be `400` or `800`.
|
||||
|
||||
It'll read the image file and write it out.
|
||||
|
||||
Useful 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.
|
||||
@@ -1,101 +0,0 @@
|
||||
Disk: Micropolis
|
||||
================
|
||||
|
||||
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.
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
Based on your floppy drive, just do one of:
|
||||
|
||||
```
|
||||
fluxengine read micropolis --143 # single-sided Mod I
|
||||
fluxengine read micropolis --287 # double-sided Mod I
|
||||
fluxengine read micropolis --315 # single-sided Mod II
|
||||
fluxengine read micropolis --630 # double-sided Mod II
|
||||
```
|
||||
|
||||
You should end up with a `micropolis.img` of the corresponding size. The image
|
||||
is written in CHS order, but HCS is generally used by CP/M tools so
|
||||
double-sided disk images may need to be post-processed. Half-full double-sided
|
||||
disks can be read as single-sided disks to work around the problem.
|
||||
|
||||
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.
|
||||
|
||||
It's also possible to output to VGI, which retains OS-specific "user data" and
|
||||
machine-specific ECC. Add `--vgi` to the command line after the chosen
|
||||
Micropolis profile:
|
||||
```
|
||||
fluxengine read micropolis --143 --vgi # single-sided Mod I
|
||||
fluxengine read micropolis --287 --vgi # double-sided Mod I
|
||||
fluxengine read micropolis --315 --vgi # single-sided Mod II
|
||||
fluxengine read micropolis --630 --vgi # double-sided Mod II
|
||||
```
|
||||
|
||||
You should end up with a `micropolis.vgi` instead. The format is well-defined
|
||||
for double-sided disks so post-processing is not necessary.
|
||||
|
||||
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=n` where the type is one of:
|
||||
|
||||
| Type | Description |
|
||||
|------|-----------------------------------------|
|
||||
| 0 | Automatically detect |
|
||||
| 1 | Standard Micropolis (MDOS, CP/M, OASIS) |
|
||||
| 2 | Vector Graphic MZOS |
|
||||
|
||||
|
||||
Writing disks
|
||||
-------------
|
||||
|
||||
Just do one of:
|
||||
|
||||
```
|
||||
fluxengine write micropolis --143 # single-sided Mod I
|
||||
fluxengine write micropolis --287 # double-sided Mod I
|
||||
fluxengine write micropolis --315 # single-sided Mod II
|
||||
fluxengine write micropolis --630 # double-sided Mod II
|
||||
|
||||
fluxengine write micropolis --143 --vgi # single-sided Mod I
|
||||
fluxengine write micropolis --287 --vgi # double-sided Mod I
|
||||
fluxengine write micropolis --315 --vgi # single-sided Mod II
|
||||
fluxengine write micropolis --630 --vgi # double-sided Mod II
|
||||
```
|
||||
|
||||
Useful 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
|
||||
@@ -1,67 +0,0 @@
|
||||
Disk: DVK MX
|
||||
============
|
||||
|
||||
The DVK (in Russian, ДВК, Диалоговый вычислительный комплекс or Dialogue
|
||||
Computing Complex) was a late 1970s Soviet personal computer, a cut-down
|
||||
version of the professional SM EVM (СМ ЭВМ, abbreviation of Система Малых ЭВМ
|
||||
--- 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.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
```
|
||||
fluxengine read mx
|
||||
```
|
||||
|
||||
You should end up with an `mx.img` which will vary in length depending on the
|
||||
format. The default is double-sided 80-track. For the other formats, add one of
|
||||
the following options:
|
||||
|
||||
* single-sided 40-track: `--110`
|
||||
* double-sided 40-track: `--220ds`
|
||||
* single-sided 80-track: `--220ss`
|
||||
* double-sided 80-track: `--440`
|
||||
|
||||
|
||||
Useful 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
|
||||
@@ -1,63 +0,0 @@
|
||||
Disk: Northstar
|
||||
================
|
||||
|
||||
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.
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
To read a double-sided North Star floppy, run:
|
||||
|
||||
```
|
||||
fluxengine read northstar <format>
|
||||
```
|
||||
|
||||
...where `<format>` is one of the formats listed below.
|
||||
|
||||
You should end up with a `northstar.nsi` with a file size dependent on the floppy
|
||||
disk type.
|
||||
|
||||
Writing disks
|
||||
-------------
|
||||
|
||||
To write a double-sided North Star floppy, run:
|
||||
|
||||
```
|
||||
fluxengine write northstar <format> -i image_to_write.nsi
|
||||
```
|
||||
|
||||
...where `<format>` is one of the formats listed below.
|
||||
|
||||
Available formats
|
||||
-----------------
|
||||
|
||||
The following formats are supported:
|
||||
|
||||
| Format name | Disk Type | File Size (bytes) |
|
||||
| -------------- | ----------------------------------- | ----------------- |
|
||||
| `--87` | Single-Sided, Single-Density (SSSD) | 89,600 |
|
||||
| `--175` | Single-Sided, Double-Density (SSDD) | 179,200 |
|
||||
| `--350` | Double-Sided, Double-Density (DSDD) | 358,400 |
|
||||
|
||||
Useful 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
|
||||
@@ -1,43 +0,0 @@
|
||||
Disk: Smaky 6
|
||||
=============
|
||||
|
||||
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).
|
||||
|
||||
Reading disks
|
||||
-------------
|
||||
|
||||
You must use a 100-tpi 80-track 5.25" floppy drive.
|
||||
|
||||
To read a Smaky 6 floppy, do:
|
||||
|
||||
```
|
||||
fluxengine read smaky6
|
||||
```
|
||||
|
||||
You should end up with a `smaky6.img` file.
|
||||
|
||||
|
||||
Filesystem access
|
||||
-----------------
|
||||
|
||||
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! See the [Filesystem
|
||||
Access](filesystem.md) page for more information.
|
||||
|
||||
|
||||
Useful references
|
||||
-----------------
|
||||
|
||||
- [Smaky Info, 1978-2002 (in French)](https://www.smaky.ch/theme.php?id=sminfo)
|
||||
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
Disk: TI DS990 FD1000
|
||||
=====================
|
||||
|
||||
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).
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read tids990
|
||||
```
|
||||
|
||||
You should end up with an `tids990.img` which is 1153152 bytes long.
|
||||
|
||||
Writing discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine write tids990 -i tids990.img
|
||||
```
|
||||
|
||||
|
||||
Useful references
|
||||
-----------------
|
||||
|
||||
- [The FD1000 Depot Maintenance
|
||||
Manual](http://www.bitsavers.org/pdf/ti/990/disk/2261885-9701_FD1000depotVo1_Jan81.pdf)
|
||||
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
Disk: TRS-80
|
||||
============
|
||||
|
||||
The TRS-80 models I, III and IV (but not the II, 100, 2000, Colour Computer
|
||||
or Pocket Computer) was a popular line of Z80-based home computers made by
|
||||
Tandy Corporation and sold by Radio Shack. There were some of the first
|
||||
generation of domestic micromputers, with the Model I released in 1978.
|
||||
|
||||
There were a myriad of different floppy disk interfaces, some produced by
|
||||
Tandy and some by third parties, using all the various combinations of 40-
|
||||
and 80-track, FM, MFM, etc.
|
||||
|
||||
Luckily the encoding scheme was mostly compatible with the IBM scheme, with a
|
||||
few minor variations: when using FM encoding, the TRS-80 wrote the sectors on
|
||||
track 17 (where the directory was) with a non-standard DAM byte.
|
||||
|
||||
FluxEngine's IBM reader can handle TRS-80 disks natively.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read ibm -o trs80.jv3
|
||||
```
|
||||
|
||||
You should end up with an `trs80.jv3` of the appropriate size. It's a simple
|
||||
array of sectors in JV3 format.
|
||||
|
||||
If you've got a 40-track disk, use `--cylinders=0-79x2`.
|
||||
|
||||
If you've got a single density disk, use
|
||||
`--decoder.ibm.trackdata.read_fm=true`. (Double density is the default.)
|
||||
|
||||
|
||||
Useful references
|
||||
-----------------
|
||||
|
||||
- [The JV3 file format](https://www.tim-mann.org/trs80/dskspec.html):
|
||||
documents the most popular emulator disk image.
|
||||
|
||||
@@ -1,67 +0,0 @@
|
||||
Disk: Victor 9000
|
||||
=================
|
||||
|
||||
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.
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read victor9k <format>
|
||||
|
||||
```
|
||||
|
||||
...where `<format>` can be `--612` for a single-sided disk or `--1224` for a
|
||||
double-sided disk.
|
||||
|
||||
Writing discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine write victor9k <format> -i victor9k.img
|
||||
```
|
||||
|
||||
`<format>` is as above.
|
||||
|
||||
Useful 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)
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
Disk: Zilog MCZ
|
||||
===============
|
||||
|
||||
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 experimental read support for these disks, based on a single
|
||||
Catweasel flux file I've been able to obtain, which only contained 70 tracks.
|
||||
I haven't been able to try this for real. If anyone has any of these disks,
|
||||
an 8-inch drive, a FluxEngine and the appropriate adapter, please [get in
|
||||
touch](https://github.com/davidgiven/fluxengine/issues/new)...
|
||||
|
||||
Reading discs
|
||||
-------------
|
||||
|
||||
Just do:
|
||||
|
||||
```
|
||||
fluxengine read zilogmcz
|
||||
```
|
||||
|
||||
You should end up with an `zilogmcz.img` which is 315392 bytes long.
|
||||
|
||||
Useful 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)
|
||||
|
||||
@@ -9,4 +9,3 @@ $(OBJDIR)/scripts/protoencode_%.o: scripts/protoencode.cc
|
||||
$(call use-library, $(OBJDIR)/protoencode_ConfigProto.exe, $(OBJDIR)/scripts/protoencode_ConfigProto.o, PROTO)
|
||||
$(call use-library, $(OBJDIR)/protoencode_TestProto.exe, $(OBJDIR)/scripts/protoencode_TestProto.o, PROTO)
|
||||
|
||||
|
||||
|
||||
55
scripts/mkdoc.cc
Normal file
55
scripts/mkdoc.cc
Normal file
@@ -0,0 +1,55 @@
|
||||
#include "lib/globals.h"
|
||||
#include "lib/proto.h"
|
||||
#include "lib/flags.h"
|
||||
#include <fmt/format.h>
|
||||
|
||||
extern const std::map<std::string, std::string> formats;
|
||||
|
||||
static ConfigProto findConfig(std::string name)
|
||||
{
|
||||
const auto data = formats.at(name);
|
||||
ConfigProto config;
|
||||
if (!config.ParseFromString(data))
|
||||
Error() << "bad config name: " + name;
|
||||
return config;
|
||||
}
|
||||
|
||||
int main(int argc, const char* argv[])
|
||||
{
|
||||
auto config = findConfig(argv[1]);
|
||||
|
||||
fmt::print("# {}\n\n", config.comment());
|
||||
|
||||
const auto& documentation = config.documentation();
|
||||
auto it = documentation.begin();
|
||||
if (it != documentation.end())
|
||||
{
|
||||
fmt::print("{}\n", *it++);
|
||||
|
||||
fmt::print("## Options\n\n");
|
||||
|
||||
if (!config.option().empty() && !config.option_group().empty())
|
||||
{
|
||||
for (const auto& option_group : config.option_group())
|
||||
{
|
||||
fmt::print(" - {}:\n", option_group.comment());
|
||||
for (const auto& option : option_group.option())
|
||||
fmt::print(" - `{}`: {}\n", option.name(), option.comment());
|
||||
}
|
||||
|
||||
for (const auto& option : config.option())
|
||||
fmt::print(" - `{}`: {}\n", option.name(), option.comment());
|
||||
}
|
||||
else
|
||||
fmt::print("(no options)\n");
|
||||
fmt::print("\n");
|
||||
|
||||
while (it != documentation.end())
|
||||
fmt::print("{}\n", *it++);
|
||||
}
|
||||
else
|
||||
fmt::print("(This format has no documentation. Please file a bug.)\n");
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
@@ -98,7 +98,7 @@ int main(int argc, const char* argv[])
|
||||
if (!u)
|
||||
break;
|
||||
|
||||
ss << fmt::format("\\u000{:02x}", u);
|
||||
ss << fmt::format("\\u{:04x}", u);
|
||||
}
|
||||
ss << "\\n\"\n";
|
||||
}
|
||||
|
||||
@@ -57,3 +57,24 @@ LIBFORMATS_LIB = $(OBJDIR)/libformats.a
|
||||
LIBFORMATS_LDFLAGS = $(LIBFORMATS_LIB)
|
||||
$(LIBFORMATS_LIB): $(LIBFORMATS_OBJS)
|
||||
|
||||
|
||||
$(OBJDIR)/mkdoc.exe: $(OBJDIR)/scripts/mkdoc.o
|
||||
|
||||
$(OBJDIR)/scripts/mkdoc.o: scripts/mkdoc.cc
|
||||
@mkdir -p $(dir $@)
|
||||
@echo CXX $< $*
|
||||
@$(CXX) $(CFLAGS) -DPROTO=$* $(CXXFLAGS) -MMD -MP -MF $(@:.o=.d) -c -o $@ $<
|
||||
|
||||
$(call use-library, $(OBJDIR)/mkdoc.exe, $(OBJDIR)/scripts/mkdoc.o, PROTO)
|
||||
$(call use-library, $(OBJDIR)/mkdoc.exe, $(OBJDIR)/scripts/mkdoc.o, LIBFORMATS)
|
||||
|
||||
|
||||
docs: $(patsubst %, doc/disk-%.md, $(FORMATS))
|
||||
|
||||
doc/disk-%.md: src/formats/%.textpb $(OBJDIR)/mkdoc.exe
|
||||
@echo MKDOC $@
|
||||
@mkdir -p $(dir $@)
|
||||
@$(OBJDIR)/mkdoc.exe $* > $@
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user