🛠️

FC1307A搭載SD-IDE変換基板のおかしな挙動を直す

に公開
11件
storage
hardware
embedded
pc
Retrofit
tech

はじめに

数年前には登場していたと思われる、FC1307Aを搭載したSD-CFアダプタとSD-IDE変換基板に関するお話です。

機能は形状のまま見ての通り、SDカードやMicroSDカードをIDEハードディスクの代わりに使うためのデバイスで、40ピンタイプはSD35VC0、TF35VA0といった型番が印字されており、44ピンタイプはSDタイプは型番の印字は無し、MicroSDタイプはTF25VA0といった型番のものが存在します。

論理的にはSD-CFアダプタ＋CF-IDEアダプタとほぼ等価なのですが、SD-CFアダプタでは省略されている電源回路や受動部品が搭載されていたり、プッシュプル式のカードスロットが搭載されており、CF-IDE変換してSD-CFアダプタを組み込むより電気的にも安定していそうで、カードの出し入れもしやすい構造です。

…なのですが、一つ致命的な問題があったのでした。

何が問題か？

状況によって電源投入時に先頭セクタの読み出し内容が化けてしまい、正常に動作しないという挙動が発生してしまうのです。実際にSDカード上のデータが破壊されるわけではないのですが、ホストから見れば書き込んだ通りのデータが読みだせないので、データが破壊されているように見えます。
Linuxベースの機器や、独自フォーマット利用する方式の楽器、パーティションテーブルの形式がPC/ATと異なるコンピューターに組み込む場合は、このバグを踏んでしまうことになり、正常に起動しないなどの問題が発生します。

さて、この問題を回避するためにいくつかの方法が編み出されました。

  • カードを挿さずに電源投入し、カードを挿してからリセットする
  • PC/ATのパーティションテーブルを模倣したものを作成する

…など。
でも、できることなら環境に依存せず、特別な手続きなしに任意の内容のカードを挿入した状態で電源投入時から正しく動いてほしいですよね。

調査

SD-IDE、SD-CFを含めFC1307Aのファームウェアにはいくつかのバージョンが存在することも知られており、バージョンによって細かな挙動に違いがありました。
分解してSPI Flashを取り外し、内容をダンプしてみます。
SPI Flashを読み書きする方法は、「SPI Flash RaspberryPi」で検索すると簡単な方法がありますので参考にしてみて下さい。また、SOP8用ICクリップを用いて基板から取り外さずに読み書きすることが可能でした。

確認できているFC1307Aのファームウェアの一覧

ATAデバイス名 リビジョン ファームウェア内文字列 Flash型番 容量 確認されている搭載製品 48bit LBA 対応
SINTECHI HighSpeed SD to CF Adapter V1.0 Rev 1.2 FC-1307 2012_07_19-BANK CF_V1.5B15 Pm25LD512 512kbit SD35VC0（黄色シルク印刷）、変換名人のSD-IDE 44ピンタイプ（黄色シルク印刷）
FC-1307 SD to CF Adapter V1.3 Rev 1.3 FC-1307 2012_10_29-BANK CF_V1.5B17 FH25VQ40 4Mbit TF-CFアダプタ（赤）
FC-1307 SD to CF Adapter V1.4 Rev 1.4 FC-1307 2012_12_20-BANK CF_V1.5B18 BY25D40A 4Mbit SD-IDEアダプタ (TD-Linuxさんによる報告)、SD35VC0（白色シルク印刷）、44ピンタイプ（白色シルク印刷）、TF25VA0、1.8"ZIFタイプ2TF2CEVA1
FC-1307 SD to CF Adapter V1.5 Rev 1.5 FC-1307 2015_10_16-BANK CF_V1.5B17 FH25VQ40 4Mbit SD-CFアダプタ（黒）、サンワサプライ ADR-SDCF1
iFlash-Platform iPod Adapters iFlash85 FC-1307 2015_03_05-BANK CF_V0.10 CM 不明 imCort Design, iFlash Quad ○
SD to CF Adapter 3rd Gen Rev 3.72 FC-1307 2014_09_30-BANK CF_V3.72 CM GD25Q512 512kbit サンワサプライ ADR-SDCF2 ○

（6/24 Flash容量、確認されている搭載製品を修正しました。）
（7/23 1/14 2/20 6/16 搭載製品を追加しました。）
512kbit、4MbitのFlashともに、先頭48KB(384kbit)しか使用していないようです。

ほかにも、FC1307Aを搭載しながらリムーバブルで使うことを想定したMisty Ghostというものが存在しますが、用途的にリムーバブルフラグがあると都合が悪いため今回は考慮しません。

手元のいくつかの環境で検証した結果、Rev1.5のものは前述の問題が発生しないことを確認できました。というわけで、問題のあるファームウェアを都合のいいものに置き換えてしまうという蛮行を思いついたのでした。

掲載時点でファームウェアをダンプできていなかった搭載製品は下記のものがあります。(25/06/16 訂正箇所が多くなったので、情報を整理しました。)

  • iFlash (SD-CF、SD-ZIF、2SD-ZIF、4TF-ZIFタイプ）
    FC1307Aを搭載しており、ATAデバイス名は独自のものになっているようです。チップ周りが樹脂で固められており、ファームウェアを読みだすには破壊的な方法で分解する必要がありそうです。
    ・SD-CFタイプの登場が2012/12/26
    ・Dualタイプの登場が2015/09/18
    とのことで、これらは少なからずFC1307A Rev1.5の日付である2015/10/16より前から存在するので、時空をさかのぼっていなければ、iFlashはRev1.5のものより古いFC1307Aファームウェアをベースにしていると考えられます。
    ・iFlash-SD v7/iFlash72：先頭セクタ問題がありそうな報告あり。ダンプ報告なし。
    ・iFlash85：137GB超のカードを挿入した際に、48bit LBAに対応しているファームウェアで、先頭のセクタ化けは発生しませんが、Identify情報の一部が文字列で潰されているという重大なバグがあり、その原因として終端文字を理解しない人がリビジョン・モデル名の文字列を弄ったと思われる形跡があります。
  • imCort Design(2TF-ZIFタイプ)
    iFlashと同様の目的で設計されたと思われるアダプタです。
    発売日は不明ですが、Rockboxのチャットログによると、「根本的にはiFlashと同じで、broken everything」なのだそうです。後に、iFlash Quadのものと同一だったとの情報を頂きました。樹脂を剥がしての検証、大変お疲れさまでした。(2/20追記)
    こちらは樹脂に覆われておらず、SOP8形状でICクリップによるアクセスも容易なため、読出しやバグ修正は比較的やりやすいと考えられます。
  • Arqamさんの情報によると、Rev1.5のみJBOD機能なしのようです。シングルカードのアダプタしか所持していないため、検証はしていません。(7/16追記 1/14更新)
  • サンワサプライ製のアダプターは、仕様にはADR-SDCF1が128GBまで、ADR-SDCF1NとADR-SDCF2が512GBまで対応と記載されています。前者はRev 1.5 後者はRev 3.72が搭載されているためでしょう。Rev 3.72のほうが若い日付となっているのは少々奇妙ですが。（黄色い青梗菜さん、情報提供ありがとうございました）

小手調べ

手始めにRev 1.3のTF-CFアダプタ（赤）にRev 1.5のファームウェアを載せてみます。これは問題なく動きました。

実践

当初はSD-IDEにもRev 1.5のファームウェアを書き込んで、一件落着、という目論見であったのですが、SD-IDEにこのファームウェアを書き込んでも動かないのです。電源を入れてもだんまりで、ホストから見ても応答しません。
同じチップを使っているのになぜだ…そんなはずはない…ならばだ、回路を追いかけてSD-CFと同じ状態にしてやるまでだ。
というわけで調査した結果、下記の変更を基板に加えることにします。

  • 基板上のSPI FlashにRev 1.5のファームウェアを書き込む
  • 下記のピンがGNDに落ちているので、パターンカットする
    • FC1307A 9pin (IOP0)
    • FC1307A 13pin (IOP1)
  • U3 (STCA1) を取り外し、その6pinのランド =FC1307A 14pin (IOP2) をGNDに落とす

実は、この作業を2022年初頭に途中までやりかけた後、まる2年放置していたんですが、ピン配置の情報が入手できたため2年ぶりの雪辱が晴らすことができました。
電源ピンなのかIOピンなのかが判別できるだけでも、格段に解析難易度が変わりますね。

さて、パターンカットした箇所をルーペでよ～く確認して…OK、電源投入。
Accessが一瞬光った！動いた！！

SD-IDE(SD35VC0)の基板で、SD-CF Rev1.5のファームウェアが動作いたしました。
これで異常な挙動に悩まされることはなくなりそうです。

FAQ

  • Rev 1.5のファームウェアはどこにありますか？
    • まず、この記事を最後まで読んでみることをおすすめします
    • 探しても見つからなければ、確認されている搭載製品の欄を参考に購入し、分解してROMを取り出すことで入手できます
    • もし、一覧にないバージョン、搭載製品を見つけたらコメントいただけると嬉しいです
  • 機器のアクセスランプが薄く点灯する、常に点灯するのですが？
    • ホスト側のアクセスランプが5Vでプルアップされている場合、SD-IDEアダプタ内で39ピンが3.3Vでプルアップされているため、その差の1.7VでLEDが点灯してしまう場合があります
      • アクセスランプの+側を3.3Vから取る
      • アクセスランプをVfの大きいLED（白・青・紫）に替える
      • SD-IDE基板上で39ピンに直列にLEDかダイオードを入れる
      • SD-IDE基板上で39ピンを5Vでプルアップする
        • 微点灯が収まらないからと過小な抵抗を挿入すると、ICに過大な電流が流れて破損するため、この方法は非推奨です。(7/8追記)
    • 等で解消できると考えられます。ホスト側の回路との関係を見て適切に対応してください
  • 認識しているようですが、データが化けています…
    • UDMA66以前のホストは基準電圧が5Vとなっていますが、FC1307Aは3.3Vで駆動されるため、チップセットによってはビットが落ちてしまうケースを確認しています
    • 対処療法的ですが、SD-IDE基板上のレギュレータを3.5V程度のものに換える、レギュレータのGND端子に直列にダイオードを挟む等して、電圧を少し盛ってあげることで解決する場合があります
      • Libretto SS1000において問題解消を確認しています

お土産

本日はお越しいただきありがとうございました。
お土産にFC1307A KiCAD用ライブラリをどうぞ。
FC-1307A.lib

番外編 改造ファームウェアをつくる

さて、汎用的に都合がよい状態を得ることができ、ひと段落ついたところですが、動作に癖のある特定の機種用に利用することを目的としている方もいらっしゃると思います。
Internet ArchiveにファームウェアをコレクションしていたAdam K氏より、特定のいくつかのモデルのHDDしか認識しない東芝T5200に対して、SD-IDEのファームウェアのモデル名を変更して対応したという事例を教えていただきました。
https://www.vogons.org/viewtopic.php?p=1018823#p1018823
これに着想を得て、PC-98シリーズの内蔵IDEディスクの容量上限が543MBおよび4,351MBの機種で発生するシリンダ数計算のオーバーフローおよび、それに起因するハングアップを回避するファームウェアを作ることができないか試みるという、さらなる蛮行を重ねました。
結果、ネイティブHead/Sectorの値を、これらの機種が決め打ち設定する値である8/17とすることで、挿入したSDカードの容量に関わらず起動時のオーバーフローが回避できることがわかりました。

パッチ対象のファームウェアイメージ
FC-1307 2015_10_16-BANK CF_V1.5B17.bin 65,536byte CRC32=2F99F86C

該当の機種向けのパッチ。git applyコマンドを使用して上記のファームウェアに適用します。

diff --git a/FC1307A_1.5.bin b/FC1307A_1.5.bin
index 7e3b8536b7735757a52cbd40ec9b17df5cae8fb2..9d9c20ef5900d0cfb801225aafda2787e6e616b0 100755
GIT binary patch
delta 84
zcmZo@U}<Pz+0dZP$HBnB;J_pZBtc;EMs1PFi?r()88$2G2nq}MI+vtoD+D;}T3Q$w
lC<MDqcCz2Y6r{JwVUjQ_M@4O!;O6PU={ihI&lfc`002?}7R~?w

delta 71
zcmZo@U}<Pz+0dZPC&0kK;J{=LBtc;EMs1PFi?r()SvD)`2ntVbv6r0eZNHhRN@bJ7
YBw<#8irO;!&C`R^b(qdPTh!110Eb=`NB{r;

(6/18更新：シリンダ値の割り算に使うH/S値の格納場所がわかったので、正しいシリンダ値が計算されるようにパッチを修正しました。これにより、4GB以下のカードを挿入したときに正しい容量で認識するようになります。）
(2/3追記：Current H/S値を正しく反映するようにしたり最大容量を4351MBにしたりを試みました。これにより、EPSON98互換機でも動くようになりました。逆アセンブルしてプログラムを書き換えているので堂々とは公開しにくくなってきました…。そのため、新しいパッチの掲載はこちらに行います。）
(4/23追記：シリンダ数計算ルーチンを丸ごと書き直し、Native・Current のシリンダ値を個別に計算し、65535で頭打ちするようにしました。また、不動作報告のあった約2GB以上のHDDをつなぐとハングアップするEPSONノート前期型機で動くよう、H=4が指定されたときにH=1 S=68として2175MBまで認識させる仕組みを追加しました。新しいパッチはこちら）

32GBのMicroSDカードを使用した例

資料 および 参考文献

お困りの声

https://www.vogons.org/viewtopic.php?t=76871
https://www.vogons.org/viewtopic.php?t=62397
48bit LBA関連
https://www.reddit.com/r/ps2/comments/hdas2g/opl_with_sd_mod_400gb_microsd_card_issue/
https://www.reddit.com/r/ipod/comments/1h5ekpj/has_anyone_successfully_extracted_firmware_from/

ソフトウェア的な対策

https://www7b.biglobe.ne.jp/~marimo9821/hduty/conv98at.html
「特定のSD-IDE変換器」として言及され、対策を施されています。
当記事を紹介して頂きました。ありがとうございます。

ファームウェア、回路図、資料

https://archive.org/details/sd2ide_fc1307a_fw
Rev 1.2、Rev 1.3、Rev 1.4、Rev 1.5のROMイメージおよびSD-CFアダプタの回路図があります。
当記事を紹介して頂きました。ありがとうございます。

http://www.kwanghua.com.cn/cn/product_view.aspx?id=144&classId=68&pId=0
FC1307Aのカタログ(PDF)がダウンロードできます。

Discussion

舞宮舞宮

コメント失礼致します。
git applyでpatchを当てようとすると

error: corrupt binary patch at line 11:
error: unrecognized input

最後の何も無い行が壊れていると表示されます(その行を削除すると10行目が壊れていると表示されます)
原因が皆目見当も付かないのですが、どうしたら良いでしょうか？

/opt/FC-1307/
の中に
FC-1307 2015_10_16-BANK CF_V1.5B17.bin FARM.PATCHが入っています。
改行コードもLFに指定して保存する等もしたのですが改善せず....

MCtekMCtek

コメントありがとうございます。
git applyでパッチを適用する際の注意点ですが、

  • 改行コードはLFにする必要があります（Windows上で動作するgitでも！）
  • a/～ b/～で指定するファイル名とパッチ対象のファイル名がすべて一致している必要があります
  • 末尾でエラーが出る場合は、patchファイルの末尾に空行を二つ入れてみてください

以上の点を試してみてください。

舞宮舞宮

ご返信ありがとうございます。
2週間程空いてしまいましたが進展致しましたのでコメント送らせていただきます。

patchファイル末尾に空白行を2行入れた所パッチに成功致しました。
その上でPC-9801USにてLBA_IDEを用いて128GBのSDカードを組み込んだのですが、
IPLwareを読み込み固定ディスク起動メニュー迄は行くのですがその先に進みません。

別のディスク(FD)よりアクセスしてみるとファイル表示等は正常にされるものの、
アプリケーションを起動するとハングしたりAbnormal Program terminationと表示されたりと
明らかに異常です。

FAQにある様にこれは電圧不足による化けなのでしょうか...?

MCtekMCtek

パッチ適用、書き込みに成功したようで幸いです。

IPLwareが正常に実行され起動メニューが表示されているなら、データ化けは発生していないと考えられます。
もしデータ化けが発生していたら、IPLの起動中に異常が発生するか、IPLwareのロード中にチェックサムエラーが発生するはずです。

しかし、PC-9801USに128GBのストレージを搭載した方は今まであまりいないでしょうから、問題の切り分けが難しそうですね。
まずは先頭500MB程度が問題なく使えるかどうか確認してみてはいかがでしょうか。

舞宮舞宮

現状報告です。

PC-9801USはLBA_IDE抜きですと問題なく動作致しました。
(FreeDOS(98)の場合はLBA_IDE入りでも正常に動作しました。
詳しくはりうさんのツイートをご参照お願いいたします。)
PC-9821Na7でもLBA_IDE付きで動作致しました。

今後これを超える様な内蔵固定ディスクインターフェース用のストレージは現れないと思います。
えむしてさんにはとても感謝してもしきれません、ありがとうございます。

げしょさんげしょさん

質問等でなくてすみません。
かなり感動してます。

素晴らしい改造をされたことと、
情報を公開してくださったことに感謝です。
FC1307Aのアダプタは、諦めていました。
手持ちのものがいくつかあるので
公開して頂いた内容をもとに
色々やってみます。

かなり前に、
某chでFC1307使った際のリセット回避について
議論されてた方でしょうか？

海外の方の情報だと、レトロな固定CHS対応機種にも
ファーム改造でいけそうで、嬉しい。

このためにアカウント作りましたが、
また質問等させていただければと思います。

MCtekMCtek

ありがとうございます。
2022年ごろまでの経緯はTwitter等に投稿しておりました。遡ってみたところ、2019年秋ごろにFC1307A搭載SD-CFアダプタとSD-IDE基板を購入したのがきっかけで、2022年1月にファームウェアの載せ替えを試み、SD-CFアダプタは解決し、SD-IDE基板はお蔵入りとなっていたものを、今回再びチャレンジしてみた次第です。
せっかくの機会なので、ぜひZennに記事を作成してみてください。気軽に書けるスクラップという投稿スタイルもあるので、小さなことから技術的交流が図れるのではないかと考えています。よろしくお願いします。

げしょさんげしょさん

そうなのですね。。(^^;
多分、Xの検索もしてましたので
みてたと思うのですが。。😅
ファームのスワップとか、やはり
視点がw
海外の方で、ファーム解析を
してたのはみてましたが、
如何せんチップの情報が探せなくて、
吸出し機器も持っておらず
まぁ、自分のレベルでは
手詰まりでした。で二年放置。。(^^;
とにかく、今から再始動して見ます😁

AndreAndre

Hello MCtek,

Thank you so much for this incredibly detailed and helpful article, and for the continuous updates! It's a truly amazing resource for the retro-computing community.

I have a question about one of the firmware versions you listed in your table: the Rev 3.72 from the "SD to CF Adapter 3rd Gen" (サンワサプライ ADR-SDCF2).

Your article focuses on the benefits of the Rev 1.5 firmware for fixing the startup bug, which is very clear. I was wondering if you have had a chance to test the Rev 3.72 firmware more extensively? I'm curious about two things:

  1. Do you know if the Rev 3.72 firmware can be safely flashed and run on the same hardware that uses the Rev 1.5 firmware?
  2. More importantly, does this Rev 3.72 firmware also solve the 48-bit LBA issue, allowing for proper support of cards larger than 137GB? I noticed the iFlash firmware has this capability, and I'm very curious if Rev 3.72 does as well.

Any insight you could provide would be greatly appreciated.
Thank you again for your fantastic work and for sharing it with us!

MCtekMCtek

Thank you for reading the article and commenting. The short answer is...

  1. Yes, there is a way to do it. As far as I have tested, applying the patch 0x03CFh FE -> 00 to any firmware and recalculating the checksum will make it ignore the state of the IOP and work on any hardware.

  2. Both seem to report and access 48-bit LBA correctly. About two-thirds of the Rev 3.72 firmware and iFlash85 firmware are binary identical, so they are thought to have the same roots.

From a retro-computing POV, there is still a problem with the incorrect calculation of C/H/S parameters, but this has been resolved experimentally by applying a patch that rewrite whole part of the process. I hope to show how to disassemble, find target code, and create patches in another article.

コメントありがとうございます。端的にお答えしますと…

  1. Rev 3.72ファームウェアは、Rev 1.5ファームウェアを使用しているのと同じハードウェアに書き込んで実行できるかわかりますか？
  1. はい。実行する方法はあります。試した限りでは、どのファームウェアに対しても0x03CFh FE -> 00 のパッチを行い、チェックサムを再計算することで、IOPの状態を無視してどのハードウェアに書き込んでも動作するようになります。
  1. Rev 3.72ファームウェアは48ビットLBAの問題も解決し、137GBを超える容量のカードに対応できるかが重要です。iFlashのファームウェアにはこの機能があることに気づきましたが、Rev 3.72も同様かどうかとても気になります。
  1. いずれも、48bit LBA値を正常に報告し、アクセスできるようです。Rev 3.72ファームウェアとiFlash85ファームウェアは2/3程度がバイナリ一致しており、同じルーツを持っていると考えられます。

レトロPC的観点では、依然としてC/H/Sパラメータの計算がおかしい問題がありますが、実験的にこの部分の処理を丸ごと書き直したパッチを当てることで解消しています。逆アセンブルする方法、目的の処理を探す方法、パッチを作成する方法はまた別の記事で紹介できればと考えています。

AndreAndre

Thank you for the fantastic and speedy reply!
The information about the universal patch for the IOP state is brilliant news. And it's great to get confirmation that Rev 3.72 handles 48-bit LBA correctly.
I'm very much looking forward to your next article on patching C/H/S parameters.
Thanks again for all your hard work and for sharing it!