今ではあまり使われなくなってしまった、Macintoshの２DDのフロッピーディスクのフォーマットについての技術情報です。
| トラック番号 | セクタ数 | セクタ番号 |
|---|---|---|
| 0-15 | 12 | 0-191 |
| 16-31 | 11 | 192-367 |
| 32-47 | 10 | 368-527 |
| 48-63 | 9 | 528-671 |
| 64-79 | 8 | 672-799 |
参考文献２にはもう少し詳しい情報があります。
| トラック番号 | 回転数（rpm） | セクタ・シーケンス |
|---|---|---|
| 0-15 | 394 | 0-6-1-7-2-8-3-9-4-10-5-1 |
| 16-31 | 429 | 0-6-1-7-2-8-3-9-4-10-5 |
| 32-47 | 472 | 0-5-1-6-2-7-3-8-4-9 |
| 48-63 | 525 | 0-5-1-6-2-7-3-8-4 |
| 64-79 | 590 | 0-4-1-5-2-6-3-7 |
一般の3.5インチのディスクでは、IBMトラックフォーマットに従いデータや同期信号などを配置し、これをFMまたはMFMで変調(channel coding)して媒体に書き込みます。これに対しMac800Kディスクでは、6ビットのデータを8ビットのパルス列に変換して媒体に書き込む、GCR（Group Coded Recording）記録方式が採用されています。
磁気媒体には直流（ 例えば０ばかりのデータが長く続く場合）は記録できないので、これをなくす目的でFM,MFM,GCR等のchannel codingが行われるわけです。Macの記録に使われている変換表を次に示します。
6-8変換GCRコード表
| 6bits data | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 00-0F | 96 | 97 | 9A | 9B | 9D | 9E | 9F | A6 | A7 | AB | AC | AD | AE | AF | B2 | B3 |
| 10-1F | B4 | B5 | B6 | B7 | B9 | BA | BB | BC | BD | BE | BF | CB | CD | CE | CF | D3 |
| 20-2F | D6 | D7 | D9 | DA | DB | DC | DD | DE | DF | E5 | E6 | E7 | E9 | EA | EB | EC |
| 30-3F | ED | EE | EF | F2 | F3 | F4 | F5 | F6 | F7 | F9 | FA | FB | FC | FD | FE | FF |
それから推定したMacのセクタformatは（完全ではありませんが・・・）
| 連続FF 約42個 | D5 | AA | 96 | #t | #s | #f | D9 | ?? | DE | AA | 連続FF 約6個 | D5 | AA | AD | #s | File Tags 16バイト | データ 684バイト | 約3バイト のCRC? | DE | AA | 先頭に 戻る |
|---|
#t：トラック番号（0-79を6-8変換した値）
#s：セクタ番号（0-11を6-8変換した値）
#f：サイド番号（0の時は96、1の時はD6)
??：チェック用CRCバイトか？
FMACPROで教えていただいたように、アドレス先導の D5 AA 96, データ先 導の D5 AA AD, アドレス／データ後導の DE AA は APPLE II のそれと全く同じ でした。
6-8変換表を適用する前にどうやって6ビットの列に切り分けるか?
最も簡単なやり方は6と8の最小公倍数の24ビットごとのデータを取り出し（例えば）MSB側から読み出せばいいわけです。しかしApple II の場合にはビット順を入れ替えていました。Macの場合はさらに複雑で24ビット毎にフィードバックがかかる仕掛けがされています。以下に示すのはこれを解析した結果です。
データ512バイトは3バイトずつ1組になって処理されます。8ビット３個がまとめ て、6ビット４個に変換されるわけです。n番目の組の出力w(n),x(n),y(n),z(n) (6ビット)は、入力a(n),b(n),c(n)(8ビット)単独の関数ではなく、内部変数S(n) (8ビット)、I(n)(16ビット)と入力a(n),b(n),c(n)の関数として表わされます。内部変数S(n)、I(n)は次のようなアルゴリズムで決まります。
(0) S(0)=0、I(0)=0
(1) S(n-1)、I(n-1)を変数S(8ビット)、変数I(16ビット)にロードする。
(2) Sを1ビット左回転（シフトではない）し、LSBからあふれ出たときはIをイン クリメントする。なお、この結果をS'(n)として出力の計算に使う。
(3) Iにb(n)*8+a(n)の16ビットを加算(arithmetic)する。overflowの時はSをイ ンクリメントする。
(4) Sにc(n)の8ビットを加算(arithmetic)する。
(5) SとIをS(n)、I(n)に保存し次の組(n+1)の処理に使う。
出力w(n),x(n),y(n),z(n)の各ビットは、内部変数S'(n),I(n)と入力a(n),b(n), c(n)の各ビットの排他的論理和として次のように表わせる。
5 4 3 2 1 0 w a7^S'7 a6^S'6 b7^I7 b6^I6 c7^I15 c6^I14 x a5^S'5 a4^S'4 a3^S'3 a2^S'2 a1^S'1 a0^S'0 y b5^I5 b4^I4 b3^I3 b2^I2 b1^I1 b0^I0 z c5^I13 c4^I12 c3^I11 c2^I10 c1^I9 c0^I8 このw,x,y,zに上で示した6-8変換表が適用され、現実のdisk上の4バイトとなる わけです。
なお、各セクタのデータ512バイトの直前には必ずfile tags 12バイトが置かれ ており、n=0が始まる位置はこのfile tagsの先頭バイトからです。 そして、次のセクタにデータが移動する毎にnも0にリセットされます。
ルポ／Mac変換のソフトを模索する過程で、GCRフォーマットを解読する必要が生じ、この成果が生まれました。結果的にはこの情報は変換ソフトに利用できませんでしたが、フォーマットを探る過程でフロッピーディスク一般についての深い知識を習得することができました。
すでに８００Kディスクは過去のものとなってしまいましたので、この情報が直ちに役立つことは望めそうもありません。この情報にインスピレーションを得て、なにか別のおもしろいことができるアイデアが生まれるようなら、公開した価値もあるというものですが、いかがでしょうか？