Apple II のディスクフォーマット
1996年3月7日から3月18日にかけてNIFTY-ServeのFAPPLEの13番会議室で議論した内容です
<![CDATA[
454/454 PXF07216 出石宗久 GCR FORMATについて
(13) 96/03/07 18:46
Macユーザーですが、教えていただきたいことがあります。
Macの800K(400K)ディスクの、GCR FORMATのエンコードの仕方とトラックフォー
マットが知りたいのです。
なにせ古いことなんで、FMACPROではお答えがいただけませんでした。FAPPLEに
ご存じの方がおられるのでは？というヒントで、こちらへ押しかけて参りまし
た。
APPLE II を参考にMACのFORMATも作られたと思うので、APPLE IIのGCRではこう
ですということでも参考になりますので、教えてください。
（１）MACの場合GCRに直すのに、6-8変換表を使います（文末に載せておきまし
た）。まず、わからないのが、変換表を適用する前に、元のデータの8bitの列を
どうやって6bitに切りわけるのかということです。自分で実験的に調べた結果、
「 6、8の最小公倍数24bit毎に処理されているらしい」、「 24bitをシフトレジ
スタに入れてその出力の一部を入力側にfeedbackしているらしい」、ことまでは
わかりました。
（２）APPLE IIの資料を自分で読んで見ようと思い、Lib1-9からTechNotes.
UDSK.BXYをMacにダウンロードしましたが、ShrinkItで圧縮されて読めません。
Lib6-8 STM 0.881r.sit MAC Apple II Emulator
Lib2-21 II+.SHK.EXE ][ ｱｰｶｲﾊﾞ(II+ ShrinkIt)
この２つを使えばMacで読めるでしょうか？
どこかのftpから直接TechNotesをテキスト形式で持ってこれるならそのほうが楽
なんですが。
（参考）6-8変換表for Macintosh （c言語形式）
static unsigned char GCR6to8[ 64 ] = {
0x96, 0x97, 0x9A, 0x9B, 0x9D, 0x9E, 0x9F, 0xA6, //00-07
0xA7, 0xAB, 0xAC, 0xAD, 0xAE, 0xAF, 0xB2, 0xB3, //08-0F
0xB4, 0xB5, 0xB6, 0xB7, 0xB9, 0xBA, 0xBB, 0xBC, //10-17
0xBD, 0xBE, 0xBF, 0xCB, 0xCD, 0xCE, 0xCF, 0xD3, //18-1F
0xD6, 0xD7, 0xD9, 0xDA, 0xDB, 0xDC, 0xDD, 0xDE, //20-27
0xDF, 0xE5, 0xE6, 0xE7, 0xE9, 0xEA, 0xEB, 0xEC, //28-2F
0xED, 0xEE, 0xEF, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, //30-37
0xF7, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE, 0xFF }; //38-3F
PXF07216 / 出石 宗久
]]>
<![CDATA[
456/457 MHA00053 A.Suzuki RE:GCR FORMATについて
(13) 96/03/07 23:49 454へのコメント
こんばんは。
> まず、わからないのが、変換表を適用する前に、元のデータの8bitの列を
> どうやって6bitに切りわけるのかということです。
月刊マイコン別冊 APPLE Disk Operating System 入門（昭和58年）の186ページ
に似たような図が出ています。
> 図2-1
> 95 96 97 9a 9b 9d 9e 9f a5 a6 a7 a9 aa ab ac ad ae af
> b2 b3 b4 b5 b6 b7 b9 ba bb bc bd be bf ca cb cd ce cf
> d2 d3 d4 d5 d6 d7 d9 da db dc dd de df e5 e6 e7 e9 ea
> eb ec ed ee ef f2 f3 f4 f5 f6 f7 f9 fa fb fc fd fe ff
> 図2-2
> ３バイトのデータはディスク上では４バイトになります。
>
> |a7|a6|a5|a4|a3|a2|a1|a0|
>
> |b7|b6|b5|b4|b3|b2|b1|b0|
>
> |c7|c6|c5|c4|c3|c2|c1|c0|
>
> ↓
>
> |a7|a6|a5|a4|a3|a2|
>
> |b7|b6|b5|b4|b3|b2|
>
> |c7|c6|c5|c4|c3|c2|
>
> |a1|a0|b1|b0|c1|c0|
これで参考になるでしょうか？ Apple II の時代にはこのニブルデータをいじく
って遊んでた人が結構いたんではなかったかと思います。（コピープロテクトと
関係あり。^_^;）「D5 AA 96」というのが標準的なセクタ開始の目印です。いや
ぁ、懐かしいですねぇ^_^ _
== |-|.Suzuki/MHA00053 ==
]]>
<![CDATA[
459/459 PXF07216 出石宗久 RE^2:GCR FORMATについて
(13) 96/03/09 01:11 456へのコメント
A.Suzukiさん、レスありがとう。
昭和58年はMac誕生前年ですから、これはAPPLE IIのFormatですね。
>>これで参考になるでしょうか？
大いに勇気づけられました（^_^）。Macでは以下のようではないかと推測してい
ました。図2-2にたいへんよく似ています。ただし、これを24bitシフトレジスタ
に入れてfeedbackをかけているようなので、解析できていない部分（??）がある
のです。
|a7|a6|a5|a4|a3|a2|a1|a0|
|b7|b6|b5|b4|b3|b2|b1|b0|
|c7|c6|c5|c4|c3|c2|c1|c0|
↓
|a5|a4|a3|a2|a1|a0|
|b5|b4|b3|b2|b1|b0|
|??|??|a7|a6|b7|b6|
|??|??|??|??|??|??|
APPLE II ではこのようなfeedback処理（？）はされていないのでしょうか。
>>「D5 AA 96」というのが標準的なセクタ開始の目印です。
おお！これはMacでも同じコードのようです。FFが42個続いた後（これはセクタ
全体に00を書き込んだ時）、必ずこの3バイトが出現しています。
私が推定したMacのセクタformatは（まだ完全ではありませんが・・・）
DE AA （FFが42個続く）D5 AA 96 TT NN SS D9 ?? DE AA （FFが6個続く） D5
AA AD NN（File Tagsの16バイト）（セクタデータ512バイト）->この後DE AAに
戻り繰り返す
TT：トラック番号（0-79を6-8変換した値）
NN：セクタ番号（0-11を6-8変換した値）
SS：サイド番号（0の時は96、1の時はD6)
??：なんらかのチェック用バイトか？
というものです。APPLE II ではいかがでしょうか。
PXF07216 / 出石 宗久
]]>
<![CDATA[
461/461 MHA00053 A.Suzuki RE:RE^2:GCR FORMATについて
(13) 96/03/09 22:12 459へのコメント
> 私が推定したMacのセクタformatは（まだ完全ではありませんが・・・）
>
> DE AA （FFが42個続く）D5 AA 96 TT NN SS D9 ?? DE AA （FFが6個続く） D5
> AA AD NN（File Tagsの16バイト）（セクタデータ512バイト）->この後DE AAに
> 戻り繰り返す
Locksmith というコピープログラムのマニュアルを見てみたんですが、次のよう
に書かれてありました。（ DOS 3.3 (Apple II) の場合 ）
・セクタはアドレスフィールドとデータフィールドに分かれる。
・各フィールドは header, information nibbles, trailer を持つ。
・アドレスフィールドは D5 AA 96 という header に続いて４つの情報
（volume number, track number, sector number, checksum）が続く。
これらは double-nibble format になっている。（checksum はその前
の３つの排他的論理和。）最後は trailer の DE AA で終る。
・アドレスフィールドとデータフィールドの間は self-sync nibbleで埋
められている。
・データフィールドは header D5 AA AD ではじまり、342 のニブルが実
際のデータ（256バイトぶん）をあらわし、チェックサムの１ニブルの
あと、trailer DE AA で終る。
Apple II の５インチフロッピーは片面なので、面番号はないんだと思いますが
あとはかなりよく似てますね。 _
== |-|.Suzuki/MHA00053 ==
]]>
<![CDATA[
471/471 PXF07216 出石宗久 RE^4:GCR FORMATについて
(13) 96/03/18 18:37 461へのコメント
A.Suzukiさん、こんにちわ。
最後の難問「8bitの列をどうやって6bitに切りわけるのか」がようやく解読でき
ました。
この処理には、入力のa,b,cから２つの内部変数S'(8 ビット),I(16ビット）をま
ず計算し、さらにExclusive OR を求めることが必要で 、
|a7|a6|a5|a4|a3|a2|a1|a0|
|b7|b6|b5|b4|b3|b2|b1|b0|
|c7|c6|c5|c4|c3|c2|c1|c0|
↓
----------------------------------------------------------
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
----------------------------------------------------------
という複雑なしろものです。（詳しくお知りになりたい方は、FMACPRO MES 4
Programmer's Folder (10) の 505番目の発言をご覧下さい。）
ともかくお陰さまで、MacのGCRデータから元データを復元できるようになりまし
た。どうもありがとうございました。
PXF07216 / 出石 宗久
]]>
元へ戻る