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:
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?
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!
Thank you for reading the article and commenting. The short answer is...
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.
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.
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!
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に指定して保存する等もしたのですが改善せず....
コメントありがとうございます。
git applyでパッチを適用する際の注意点ですが、
a/～b/～で指定するファイル名とパッチ対象のファイル名がすべて一致している必要があります以上の点を試してみてください。
ご返信ありがとうございます。
2週間程空いてしまいましたが進展致しましたのでコメント送らせていただきます。
patchファイル末尾に空白行を2行入れた所パッチに成功致しました。
その上でPC-9801USにてLBA_IDEを用いて128GBのSDカードを組み込んだのですが、
IPLwareを読み込み固定ディスク起動メニュー迄は行くのですがその先に進みません。
別のディスク(FD)よりアクセスしてみるとファイル表示等は正常にされるものの、
アプリケーションを起動するとハングしたりAbnormal Program terminationと表示されたりと
明らかに異常です。
FAQにある様にこれは電圧不足による化けなのでしょうか...?
パッチ適用、書き込みに成功したようで幸いです。
IPLwareが正常に実行され起動メニューが表示されているなら、データ化けは発生していないと考えられます。
もしデータ化けが発生していたら、IPLの起動中に異常が発生するか、IPLwareのロード中にチェックサムエラーが発生するはずです。
しかし、PC-9801USに128GBのストレージを搭載した方は今まであまりいないでしょうから、問題の切り分けが難しそうですね。
まずは先頭500MB程度が問題なく使えるかどうか確認してみてはいかがでしょうか。
現状報告です。
PC-9801USはLBA_IDE抜きですと問題なく動作致しました。
(FreeDOS(98)の場合はLBA_IDE入りでも正常に動作しました。
詳しくはりうさんのツイートをご参照お願いいたします。)
PC-9821Na7でもLBA_IDE付きで動作致しました。
今後これを超える様な内蔵固定ディスクインターフェース用のストレージは現れないと思います。
えむしてさんにはとても感謝してもしきれません、ありがとうございます。
質問等でなくてすみません。
かなり感動してます。
素晴らしい改造をされたことと、
情報を公開してくださったことに感謝です。
FC1307Aのアダプタは、諦めていました。
手持ちのものがいくつかあるので
公開して頂いた内容をもとに
色々やってみます。
かなり前に、
某chでFC1307使った際のリセット回避について
議論されてた方でしょうか？
海外の方の情報だと、レトロな固定CHS対応機種にも
ファーム改造でいけそうで、嬉しい。
このためにアカウント作りましたが、
また質問等させていただければと思います。
ありがとうございます。
2022年ごろまでの経緯はTwitter等に投稿しておりました。遡ってみたところ、2019年秋ごろにFC1307A搭載SD-CFアダプタとSD-IDE基板を購入したのがきっかけで、2022年1月にファームウェアの載せ替えを試み、SD-CFアダプタは解決し、SD-IDE基板はお蔵入りとなっていたものを、今回再びチャレンジしてみた次第です。
せっかくの機会なので、ぜひZennに記事を作成してみてください。気軽に書けるスクラップという投稿スタイルもあるので、小さなことから技術的交流が図れるのではないかと考えています。よろしくお願いします。
そうなのですね。。(^^;
多分、Xの検索もしてましたので
みてたと思うのですが。。😅
ファームのスワップとか、やはり
視点がw
海外の方で、ファーム解析を
してたのはみてましたが、
如何せんチップの情報が探せなくて、
吸出し機器も持っておらず
まぁ、自分のレベルでは
手詰まりでした。で二年放置。。(^^;
とにかく、今から再始動して見ます😁
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:
Any insight you could provide would be greatly appreciated.
Thank you again for your fantastic work and for sharing it with us!
Thank you for reading the article and commenting. The short answer is...
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.
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.
コメントありがとうございます。端的にお答えしますと…
レトロPC的観点では、依然としてC/H/Sパラメータの計算がおかしい問題がありますが、実験的にこの部分の処理を丸ごと書き直したパッチを当てることで解消しています。逆アセンブルする方法、目的の処理を探す方法、パッチを作成する方法はまた別の記事で紹介できればと考えています。
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!