uts

このあいだ札幌に行った時に、あいの里のハードオフに寄ったら未開封の 5インチフロッピーディスクを見つけたので、あるだけ全部買ってきました。一箱 100円でした。 2HDのメディアはまだいくらか持っているのですが、2Dは中古で買ったものが少しあるだけなので助かりました、2DDは2Dとしてフォーマットできたはず。2D/2DDのメディアはヤフオクでもなかなか流通しません。 他に 230MBのMO 10枚 1,000円とか、MSXのぎゅわんぶらあ自己中心派 500円とか、3.5インチFDD 300円とか、MIDIケーブル 100円とかを買ってきました。3.5インチのFDDも手に入りにくくなってきましたね。未開封のMOは、まだ他にもありましたが手持ちがあるので10枚だけ購入してきました。 ハードオフは値付けがうまくて、ヤフオクで買ったほうが安いなぁとなることが多いんですが、今回は入手困難なものを安く買えました。こんなことってあるんですね。

フロッピーディスクドライブの信号 を見てみて、フロッピーディスクドライブの互換品を自分で作れそうな気がしたので、MMC / SDカードを使ったフロッピーディスクドライブのエミュレーターを作ってみました。 回路図  H8S FDD EMULATOR20141022.pdf ソースコード  2144_FD_EMULATOR20141020.zip マイコンは H8S/2144 で、開発環境はルネサスのHEW無償版です。回路図、ソースコードはどのような用途にでも自由にお使いください。 作成途中ですが、MFMエンコードや CRCの計算は正しく動いていて、X1 turbo の OS LSX-Dodgers 上で 2D と 2HD 形式のファイルの読み取りが正常に動作しました。シークが遅いせいか IPLからの起動はまだできません。書き込みもできません。 フロッピーディスクのCRC計算や、MFMエンコードの資料はなかなか見つからないので、そのサンプル程度には役に立つんじゃないでしょうか。 今のところ、古いパソコンのエミュレータでよく使われている、D88形式のイメージファイルを使っていて、STEP信号が来るたびに D88ファイルからトラックのデータを読んで、CRCを計算して、MFMでエンコードしてバッファに書き込むという動作をしているのでシークに時間がかかっています。 クロックビットの分イメージファイルのサイズが 2倍になってしまいますが、CRCの計算とMFMのエンコードをあらかじめ済ませておいた、独自形式のイメージファイルを使って速くしたらいいんじゃないかなと考え中です。 はじめ、READ DATA 信号の生成は、タイマーで 1ビット期間 (クロックビットを入れると 2HD では 1Mbps) づつ割り込みをかけて、IOポートをソフトウェアで操作して行ってみたのですが、H8Sではまったく間に合わなかったので、SCI のクロック同期モードを使うようにしました。 クロックビットを含めると 1トラック分のバッファに 25Kバイトも必要になるので、外付けRAMのあるジャンクのマイコン基板を使ったのですが、秋月で 1個 360円の PIC32MX が SRAM を 32Kバイト内蔵しているので、これを使えば外付け部品無しで作れるかも。 ま...

ついでに、テーブルを使わないでCRCを計算する関数も作成しました。どうしても使用するプログラムメモリを削減したい場合向け。 テーブルを使って高速に計算する関数はこちら /* CRC-16-CCITT を計算する // wikipediaにある実装例の通り（wikipediaの例は多項式が反転、シフトの向きが右） // http://ja.wikipedia.org/wiki/%E5%B7%A1%E5%9B%9E%E5%86%97%E9%95%B7%E6%A4%9C%E6%9F%BB MB8877のデータシートに X^0+X^5+X^12+X^16 と書いてあったので、フロッピーのCRCは CRC-16-CCITT 2014年9月2日作成 */ unsigned short crc_1byte(unsigned char in, unsigned short crc) { /* 1byteづつCRCを計算する wikipediaにある実装例を、テーブルを使わないように書き換えただけ。 unsigned short crc; crc = 0xffff; // 初期値 crc = crc_1byte(0xA1, crc); crc = crc_1byte(0xA1, crc); crc = crc_1byte(0xA1, crc); crc = crc_1byte(0xFE, crc); // A1 A1 A1 FE : ID ADDRESS MARK crc = crc_1byte(0x02, crc); // C crc = crc_1byte(0x00, crc); // H crc = crc_1byte(0x03, crc); // R crc = crc_1byte(0x02, crc); // N これで crc に計算結果が入る (0x4165) */ #define polynomial 0x1021 // 多項式 CRC-16-CCITT X^16+X^12+X^5+X^0 (1 0001 0000 0010 0001) // 0x8005 //        CRC-16-IBM X^16...

CRCを計算する用事があったので、CRCを計算する関数を作成しました。 テーブルを使わない、省メモリな関数はこちら Visual Studio Express 2013 で動かしてみて計算が合っている様子だったので、たぶん間違っていないんじゃないかな？ /* CRC-16-CCITT を計算する // wikipediaにある実装例の通り（wikipediaの例は多項式が反転、シフトの向きが右） // http://ja.wikipedia.org/wiki/%E5%B7%A1%E5%9B%9E%E5%86%97%E9%95%B7%E6%A4%9C%E6%9F%BB MB8877のデータシートに X^0+X^5+X^12+X^16 と書いてあったので、フロッピーのCRCは CRC-16-CCITT 2014年9月1日作成 // テーブルを作成する void print_crctable(void) { #define polynomial 0x1021 // 多項式 CRC-16-CCITT X^16+X^12+X^5+X^0 (1 0001 0000 0010 0001) // 0x8005 //        CRC-16-IBM X^16+X^15+X^2+X^0 (1 1000 0000 0000 0101) unsigned int i, j; unsigned short a; printf("\n多項式 0x%04X\n", polynomial); for (i = 0; i < 256; i++) { a = (i << 8); for (j = 0; j < 8; j++) { if (0 == (a & 0x8000)) a = (a << 1); // 最上位ビットが0ならシフトのみ else a = polynomial ^ (a << 1); // 最上位ビットが1ならシフトして多項式でXOR } printf("0x%04X,", a); if (((i & 0x0F) == 0x07) ||...

2HD の WRITE DATA 信号 パルスの間隔が、短いところで 2us になっています。 2HD の 転送速度は 500kbps で クロックを入れると 1,000kbps になります。 1,000kbps だと 1ビットあたり 1us になり、2HD で使用されている MFM 方式だと "1" が連続することはないので、パルスの間隔は最短の場合で 2us になります。 ビット列の並びは 2us なら "101" 3us なら "1001" 4us なら "10001" となります。MFM 方式では "0" が 3個以上連続することはありません。（ミッシングクロックの場合でも、"0" が 3個以上連続しないようになっていました） WRITE DATA 信号の拡大図 パルス幅は、だいたい 300ns くらいでしょうか。 2HD の READ DATA 信号 READ DATA 信号は、ドライブが選択されていてモーターが回転している間、ずっと出力され続けます。 2DD の READ DATA 信号 パルスの間隔が、2HD の時の倍になっています。 パルス幅は 2HD と同じくらいに見えます。 READ DATA と WRITE GATE の関係 書き込み中には READ DATA 信号が出てきません。 INDEX 信号のパルス幅は 2ms ～ 4ms 弱くらいの変動がありました。パルスの立ち下がりを使用する事になっているので、幅はあまり重要でありません。 INDEX 信号の間隔 360RPM なので 60/360*1000 = 166.667ms と、計算と同じになっています。 フローッピ-ディスクドライブの READ DATA 信号／ WRITE DATA 信号は、RS232Cなどのシリアル通信のように "0" なら "H" 、"1" なら "L" (FDDの信号は負論理) とレベルが変化するものだと勝手に思っていて、FM 方式で記録した場合、データビットに ...