雑談スレッドでハードウェア解析や考察が話題となっていますが、個人的に別途スレッドを立てた方がよいと思ったので立てました。
強制はしませんが、今後のハードウェア解析や考察についてはこちらのスレッドで話題にしていただけると助かります。

2020-09-24 09:40:33

現在、去年ヤフオクで落としてアメリカまで輸送したまままだ未処理だったHRの電源を修理しようとしてます。コンデンサは全部交換しますが、なんかリレーが死んでるような気がするのでリレーも交換してみて、それでもだめだったらAT電源化する予定です。

当然のごとくバッテリーも死んでいるはずなのでソケットに変換しようとしてます。一応、MX、MAがCR2450だったのでHRも同じだろういう予想はできましたが、確認しました。同じCR2450でした。一応、報告でした。

2020-09-27 03:51:19

旧スレッドからのネタです
・モデルHC(たぶんMシリーズやFreshも?)のCD-ROMについて、読み取り不良を何とかしたかったのでえすびさん方式(ピックアップのトリマ調整)を行いました。
結果としては上々で、いままであれ程読めなかったCD-ROMが確認した限りでは全て読めるようになりました。
私の場合はトリマを右に10°程度右に適当に回して当たりでした。
CD-ROMが不調な場合の1つの方法としては有効ではないかと思います。(http://sbeach.seesaa.net/article/475985723.html)

・モデルHCのFDDについて、以前ジャンクで購入してきたドライブに交換して3モード共に正常でしたのでWIKIの方に記載しておきました。
交換したドライブは YE-DATA製 YD-702D-6238Dですが、1点だけ注意点が有ります。 (ドライ部側コネクタのバンプ溝が天地逆となっていますのでドライ部側コネクタを加工する必要があり)
同時に購入してきたMITSUMI製 D63119は正常動作しなかった為、原因を究明中です。(非常に綺麗なのでドライブの不良とは考えにくい)

2020-09-28 00:19:19

上記ネタでTOWNSを久しぶりにバラした時に今更気づいたのですが、HCにはPLCCソケットでH8マイコンが搭載されていました。
赤本等の資料には一切その様な記載が有りませんが、どなたか情報をお持ちでしょうか?

逆に赤本ではCDCとしてMB88505が搭載されていると記載されていますが、こちらは見つけることが出来なかった(そもそもよく見ていなかった)のでひょっとしたら2倍速化の際等にCDCがH8に変更されているのか? とも思っています。
(今度機会を造ってH8のピンとCD-DRIVEのピンをテスターで計ってみようかな)

2020-09-28 13:10:57

>4 WINDYさん
遡ると確かHRでHD64180系マイコンに変更されていた記憶があります(おそらく64KB先読みキャッシュのため?)。
その後6代目(白TOWNS)でH8マイコン(Oh!誌のDr.ちゆきの分解記事の写真(暗いですが)によると「H8/325」)に変更され、それが7代目(Oh!誌の分解記事の写真によると「H8/324」)にも引き継がれているものと思われます。
なお、V-TOWNSではATAPIから独自I/Fへのエミュレーションの関係上、CD-ROMコントローラエミュレータもTOWNSカード上のVM386SXで実行されるファームウェアに実装されています。このあたりを更に深掘りしてみれば白TOWNSにしか実装されていないADPCMデコーダ以外の仕様が見えてくるかもしれません。

2020-09-29 19:04:50

>5 りうさん
有り難うございます。 Oh!誌はFM-7を使っていた頃から欠かさず購入していましたが・・・・
そのような記事が有ったことはすっかり記憶から欠落していました。

深堀ですか・・・ 深堀ですね。 流石に回路図を起こす事は出来ませんが、なるべく高精細で写真を撮る事は出来ると思います。(LANカードとかMIDIカードとかの写真は撮ったのですが、メインボードは途中で面倒くさくなって・・・)
何せASICが結構使われていますので配線を追ってもそこで手の打ちようが無いのが残念ですが想像は出来そうな気がします。
ビスが異常に多いのでバラすのには時間がかかりますが、初代のような箱根細工風でもないのが唯一の救いです。

2020-09-29 23:55:36

昨日SCSI CDbootのために内蔵HDDを外すついでに見てみたら、私のHCでは「H8/325」が搭載されていました。
詳細な形番が判らないのでPROMなのかMaskedROMなのか判別できませんが、恐らくソフトの版のシールが貼ってあったのでどちらかでしょう。

「入出力ピンからCD-ROMドライブに行っている信号線のIn/Outが判るかも」と思いましたが、H8のGPIOはIN/OUTなのですね・・・・
プログラムも吸い出せそうに無いのでそっち方面からの解析はおあずけです。
ドーターカードの配線がCD-ROMドライブのコネクタを避けて通ってましたので少なくともCD-ROMドライブはSCSIでは無い事は確かです。
(HCのドライブはCD-ROMを挟むように内蔵HDD用のものとファイルスロット用(HC53MはMO内蔵のため)のSCSIのコネクタが存在しています)

2020-10-01 17:57:03

メモリカードの件ですが、手を換えてos-wikiで検証用に使用しておられたpcctolをHCで使用してみました。
結果としては、CFカードアダプタに挿したCF(32MB FAT16)と4in1アダプタに挿したSD(16MB FAT16)でアクセスに成功しました。
ファイルのコピーとかもやりたかったのですがドキュメント通りにタイプしてもdrive errorになってしまうのは私のミスだろうか・・・・
もう少しやってみたいと思います。

pcctoolは、下記のこめんと欄の一番下の川合さんのコメント先よりソース付きで入手できます(ソースはASKAになります)
http://oswiki.osask.jp/?pcctol

2020-10-10 00:32:59

おお、読めたんですね！詳しくリンク先は読んでいないですが、読むときウェイトかなにか必要なんでしょうかね？今でこそ高速なCFやSDがありますが、当時のRAMだと486DXの66MHzで読んで追い付くのかな？と疑問はあったのですが。ただ、SYSROMは普通にMOVSBを使ってアクセスしているようなのですが。引き続き何かわかったら教えてください。

2020-10-10 23:50:13

>9 山川機長さん
取り敢えず小さなファイルをSDとCFに書いたり、SD,CF上の物を読んだりしてみましたが、全く問題がありませんでした。
しかしながらCF上に同じファイルを名前を変えてコピーして行ったときに、2.36MBを超えたときにエラーとなった事からたとえCFやSDが大きな容量を持っていてもある程度までの大きさまでしか書けないような印象です。
この制限がプログラム上の物なのか、TOWNSの機能による制限なのかは不明ですがPC用の同名ソフトではより大きな容量をカバーできている記載がpcctolのドキュメントに記載されている事から、プログラムの制限では無いような気もします。
オリジナルのソースを眺めてみようかと思います。

CFやSD等のスピードに関しては、PCMCIAカード自体がコントローラを内包している事から問題はないのではないかと思います。(カードのBusyが端子に出ているので、それに従うタイミングでOK)

2020-10-11 17:40:42

CFが読み書きできると大きいですね。TOWNS側でBUSYフラグ見て調整ですかね? 赤本だとBUSYフラグはEPROMの書き込みREADYとあったので読み込みは関係ないかと思いました。SYSROMは何もせずにMOVSBしていたような気がしたのですが。PHYSDUMPは何も考えずにMOVSBでリアルメモリにプロテクテドモードメモリをコピーしてダンプしているので、もしもWAITが必要とするとその影響で意味のない値が出てきたのかも。いや、でも、それだとTICMFMT.EXEでフォーマット失敗したなあ。実はMXの問題なのだろうか。

ちなみにブートローダーですが、PCとクロスケーブルでつないでXMODEM経由でCMOSダンプをやりとりできるようにしようとしてます。ゆくゆくは、XMODEMでROMも送れるようにして、CDもFDも動かないTOWNS→仮想SCSIドライブで起動してROMファイル抜き出し→エミュレータ上でHDDイメージ作成、CMOS設定→XMODEMで実機にCMOS送信→仮想SCSIドライブにエミュレータで作ったイメージをマウント→実機復活という流れができないか(SCSI CDドライブが無くても仮想SCSIドライブだけで復活可能)、というようなことを考えてます。

この間ヤフオクでFDが動かないというUXが出てましたね。そういうのもこれで復活させられれば、と、思うのですが、ただUXに関しては依然としてなんで386SXでブートローダーが動かないのか(それともUX特有の問題か)特定できてないですが。386DXで使えて386SXで使えない命令なんてあったかな?

2020-10-12 08:25:46

>11 山川機長さん
pcctolのソースを読んでいます・・・ 私にとってはASKAは慣れないとX86以上に読みづらいかも・・・
ですが、readとwriteの最小ループ部分は512バイトを連続して読み取っている事は判明しました。特にフラグを参照している節は有りません。
もう一段上のループでは、400nsのウェイトが入っていますのでセクタの切替時には待っているようです。(R/W共に同じ400nsです)
また、バンク切替レジスタはオープン時にバンク0に明示的に切り替えていますが、R/W中に切り替えてはいない様子です
上記オープン時には明示的にメモリマップドモード,デバイス番号0を指定していますが、タプルを辿った様子は無く決め打ちでメモリカード側を設定しているようです。

2020-10-12 13:18:38

Amaranth3対応のためI/O FF82H(Memory-Mapped I/O CFF82H)について実機で(今引っ張り出してきた2F)で実験していたのですが、非常に興味深いですね。

まず赤本ではFF82Hに書き込むときはビット6は必ず1にすることとありますが、TBIOSがAH=06Hで27Hを書き込むので0でも1でも関係ないようです。

ビット0～2、ビット5で表示プレーンを指定できることになっていますが、2Fで画面モード1,3,13,17 (なぜかTBIOSが32K色モードで2ページにしたら何も書いてくれないのだが、どうやれば書いてくれるんだったか忘れた。Towns現役当時ほとんど自作のConcorde Graphics Library使ってたもんな。)で試したところ、どうやら16色モードで、カラーインデックスに対するマスクとして機能するようですね。

ビット4で表示ページ指定ということになっていますが、CRTCのVRAMオフセットを切り替えるのかと思ったら、どうやらこのオフセットはCRTCとは別にあるようです。多分CRTCとVRAMのアドレスバスに割って入って、CRTCがVRAMレイア0の上半分(00000H～20000H)にアクセスするときのみオフセットが適用されるようです。1画面モードではVRAMを互い違いに読むので、このオフセットが適用されると縦じまが入るみたいに画面が乱れます。が、本来FM-R互換モード以外でこのビットを使うことは無いはずなので2F以外だと動作が違うかもしれません。

さらに、画面モード1(FM-R互換モード)以外では明らかにオフセットはちょうどVRAMの半分, 20000Hなのですが、画面モード1だと縦方向に12ピクセル、横方向に320ピクセルずれるんですね。計算すると、画面モード1のときだけ203A0Hのオフセットになるという謎な挙動を示したのですが、この3A0Hがどこから来たのか謎です。

ただ、おそらくこの3A0Hのオフセットを気にするアプリケーションは無いだろうと思ったので津軽では画面モードにかかわらずちょうど半分20000Hで割ってます。それから画面が互い違いに乱れる状態も実機に忠実に再現しようかと思ったのですが、それだとレンダリングでピクセル単位で加算と論理和が増えるし、そもそも未定義の動作なので再現してません。

2020-10-19 03:08:07

>13 山川機長さん
I/O 0xFF82のbit6って何だっけと思ってXM⑪のソースを見てみたところ、400ライン/200ライン設定でした。おそらくFM16β/FMR-50との互換性を持たせるために必ず1(=400ライン)を書き込むことになっているんだとは思いますが、TOWNSでは何の意味もないですね。

2020-10-20 16:59:52

なるほど、FM11のI/Oを見て意味を確認するという手があったんですね。さすがです。いやあ、意味がないかどうか、とりあえず4ピクセルまたは2ピクセルずつ互い違いになる現象を利用したプログラムは確認できてませんが、400/200ラインの選択も非公式にできるのであれば、4段階で画面を崩すことができるので、その気になればこれを使って画面がDissolveするようなエフェクトを書くことも不可能ではないかもしれません。ひょっとするとそれが意味を持つプログラムも見つかるかもしれないですね。見つかったら面白いですが、エミュレータ泣かせですね(^_^;)

2020-10-22 01:11:17