他愛もないない事から、悩み事までなんでもお書きください。

では、手始めに私の困ったことから。
我が家のTowns・・・ モデル2FとMXとHC(MXは実家に置き去りにしていますので手元には無い)ですが、MXとHCはCD-ROMが弱っているようでCD-Rが読めなかったり、
特定のCD-ROMから起動できなかったり・・・・ FDDはメディアが悪いのか,安定しない状態です。
かといってSCSIのCD-ROMドライブを持っている訳でも無いので、Windowsとのデータのやり取りに苦慮する場面がチラホラとあります。
真剣に内蔵CD-ROMを何とかする手だてを考えないといけないのだろうか・・・・ みなさんのTownsの状況は如何ですか?

2020-07-29 10:03:48

>145 山川機長さん
その役割は7代目Freshの第2世代(ややこしい…)の時に出たワイヤレスコマンダーが担っていると思います。
ただ、ワイヤレスコマンダーは富士通提供ライブラリがテレビやビデオのリモコン機能専用なので、Zaurus(シャープ)との連携の仕方などがいまいちよく分かりません…接続ポート自体はMSX規格のジョイスティック端子(FMV-TOWNS用「ワイヤレスコマンダーV」/「IRコマンダー」ではシリアルポート接続に変更)なので、ライブラリを解析してどう制御すればいいのかがわかればFM-7シリーズでも使えるかもしれませんが。

そういえばモデルHC本体に付属していた「FM TOWNS拡張計画」だったか何かの初版にHR/HG/MX/MAのリモコン受光部でデータ通信ができるとか訳のわからないことを書いてあったんですが、2版目からは削られているらしいです。

2020-10-16 13:44:16

ワイヤレスコマンダー・・・ 持ってます。
実家に有るので遊ばれるのであれば付き合いますョ ただ、1台しかないので相手をどうするかが問題では有ります。
IRのLEDでもArduinoから光らせてシリアルデータを遅らせることは容易に可能です。

2020-10-16 14:23:56

実家にあるのは頼もしいですね
バッキバキに使っちゃって下さい(*´▽｀*)

2020-10-16 20:01:08

それって、どのぐらいの解像度で信号出ますかね？どのぐらいの解像度が必要だったかソース見ないと忘れてしまったのですが、それを使うと、TOWNSをFM77AV/AV20/AV40のリモコンキーボードとして使うプログラムが書けそうですね。まさに、老々介護！それができたら楽しそうですね。ただ、普通のリモコンより少し高い解像度が必要だったように記憶しています。1ビットが平均1msだったかな？36KHzのmodulationで1ビットがパルス4回とかだったような気がする。しかしI/Oはライブラリを解析しないとわからんですか。それってHigh-Cマルチメディアキットに入ってましたかね？

2020-10-16 22:41:52

>150 山川機長さん
High C マルチメディア開発キット V1.7L13にはライブラリが入っていることを確認しています。
FM77AVシリーズのワイヤレスキーボードとして機能させるとかお互いにワイヤレスコマンダーをつないで通信するとかのネタはユーザーフォーラムになった後のFTOWNSのRTCでもいろいろと話題にはなったのですが、誰も作りませんでした。ｗ

2020-10-20 17:05:20

おおそうですか！それだと津軽で動作を見れますね。十分な解像度が出るようなら老々介護プログラムが書けると思います。ジョイスティックポートに信号が出てるようなら互換ハードは作れると思います。うーん、この間Arduino用に書いたFM77AV赤外線キーボードエミュレータのコントロールプログラムをCで書いておくべきだった。大学の物置とかにHigh-C++落ちとらんかな。

2020-10-22 01:06:47

雑談というか余談です。
ユーザーフォーラム版FTOWNSには初期を除くベンダーフォーラム時の2フォーラム体制を維持(会議室は再編成)した際のユーザーフォーラム(FMTOWNS Multimedia Forum)と、そのあと1フォーラム体制に規模を縮小してフォーラムマネジャーも交代した後のユーザーフォーラム(FMTOWNSフォーラム)があるのですが、1フォーラム体制の時のフォーラムマネジャーは実はベンダーフォーラム当時の絵画喫茶(ふり～はんど)で「うぇいとれす」をつとめてた「あや」さんでしたｗ

2020-10-23 05:32:54

ワイヤレスコマンダーは残念ながらまだ発見できていません。 代わり(?)にCyberStickとTownsMXをサルベージして参りました。
MXはCMOSが飛んでいるので、電池の交換とドライブ構成から行う必要が有ります。 CD-ROMの調子も良くなくてFASTモードでは読み込みが正常に行われない様ですし、互換モードでも成功率は低い様子ですので、SCSIからブートする事になりそうです。本当に助かります。

2020-10-27 09:06:54

ブートローダーで一台でもTOWNSが救えたら作った甲斐がありました。現在ハードディスク用ブートローダーを既存のハードディスクイメージの後ろにひっつけるスクリプトを書いてテストしています。津軽上の実験ではCMOSが飛んだ2Fを仮想ハードディスクだけで外付けCDドライブも使わずに復活させることに成功してますが、まだ実機の起動プロセスと何かが違ってる部分があるようなので実機であっさり成功するかどうかはやってみるまでわからんですね。これがうまくいったら、普段使いのハードディスクイメージの後ろにひっつけたものをSDカードに焼きSCSI2SDなどを使って実機を復活させることができて、しかもそのまま継続使用可能(困ったらまたブートローダーから復活させる)になる予定です。

ワイヤレスコマンダーは、僕の環境でやろうと思ったらどうせ自作が必要になるので、そのうちワイヤレスコマンダー再生産プロジェクトをしましょう。単純にCOM信号でOn/Offを出してるだけだったら簡単な赤外線LEDの回路で済むかもしれないですが、そこまで甘くはないですかね。

2020-10-27 10:43:09

FMTowns新エミュレータ Tsugaruの情報交換用スレッドです。
Tsugaru : http://www.ysflight.com/FM/towns/Tsugaru/j.html

2020-07-28 12:41:40

J-TYPEを見てますが謎ですね。ディレクトリが表示されないのがなぜなのか調べようとしているのですが。これ、中解像度モードでも出ませんね。ディレクトリをストアしている場所の特定は割と早かったのですが、今逆アセンブルをたどってたどって、表示内容をREPNE SCASBしているところを見つけて先に進めたらなぜかEGBで文字列表示ではなくビットマップ表示に行きついてしまってがっくり来たところでした。間違った場所に書いてしまっているとかだったら書いてる場所を特定するのですが、文字列表示を呼んでない(本来発生するべき処理が発生してない)のは難しいパターンですね。さすがにJ-TYPEのソースなんてないですよね。まだ、最後の手段、実機で386DEBUGして動作比較という手は残っていますが。

2020-10-25 01:12:59

久しぶりにCPUのバグ鴨しれないんですが、
MOV EAX,DS
(逆アセンブルするとMOV AX,DXと表示するけどオペランドサイズは32)って、EAXの上位16ビットクリアするのが正解なんですかね？オペランドサイズにかかわらず上位16ビットは歩青んするように書いていたら、J-TYPEの中で、 MOV AX,DS CMP EAX,EBX JNE (Skip Drawing) というのがあって、字が出ないのはこの影響でした。むむむ、セグメントの比較だったら CMP AX,BX と書いてほしかった。ちなみに、いくらEGBの文字列表示を探してもだめなはずで、フォントBIOSを使ってビットマップを作ってビットマップ描画機能を使って描画してました。

というか、言ってる暇にテストプログラム書いて実験します。原因がわかったので多分なんとかなるでしょう。

2020-10-25 02:48:14

どうやら MOV EAX,DS は上位16ビットをクリアするべきのようです。386ASMは MOV AX,DS としないとエラーを出すので、上位ビットは残るような印象ですが、実際は MOV EAX,DS と MOV AX,DS は挙動が違うんですね。というわけで、J-TYPE高解像度版も動作するようになり、マウスカーソルが512を超えると0にラップされてしまう問題と、レイア1の内容がレンダリングスレッドにコピーされてなかった問題を解決して、J-TYPEは完全動作するようになりました。今晩のソースで使えるようになります。他のソフトもこれから調査してみます。

2020-10-25 06:07:15

ソースPUSHしました。とりあえず、J-TYPEとTowns Paint LiteとMiVは確認しました。WINK3ってフリコレ11にも見つからなかったんですが、どこかでダウンロードできますかね？なお、ハイレゾCRTCのシングルページモードの判定ですが、多分、レジスタ1のビット1のような気がします。一応ズームも対応したつもりなのですが、まだ試してないので間違ってるかもしれません。フルカラーモードですが、EGBでは対応してないんですね。今からHigh-Cのドキュメント読んで勉強します。ところで、MA/MX世代より前の機種用のフルカラーカードって刺すと高解像度も出るようになったんですかね？ハイレゾVRAMを持ってない機種に1MBのVRAMを搭載するカードのような印象を受けたのですが。

2020-10-25 10:04:31

一応、フルカラーモード対応したソースもPUSHしました。EGBはフルカラー非対応とマニュアルには出てるのですが、画面モード22番が一応非対応だけどフルカラーと書いてあって(なんだそりゃ)、試しに使ってみたら普通にフルカラーモードになりました。フルカラーモードはレジスタ11BHの値がFFFFFFHですね。なぜかFGSライブラリはフルカラーモードに入ることが出来なかったのですが、多分何か使い方が違うのだと思います。FGS_init2にドライバがインストールされてないと言われますね。Towns MENUの設定ではフルカラーにチェックを入れたのですが。

2020-10-25 13:59:13

>112,113 山川機長さん
WINK3(WINK[波動版・セミハイレゾ対応・MSV対応])はフリコレが発行終了した後に作られた(というか、作った)ソフトなので、フリコレ11にも収録されていません。下記のリンクよりダウンロードできます。
http://retropc.net/ryu/unz/lib2.htm

あと、フルカラーモードを含めた高解像度CRTCのEGBでの画面モード表をどこかで見たような気がするのですが、見つかりませんでした。記憶違いかもしれません。

2020-10-25 17:29:24

>112 山川機長さん
114で書き忘れましたが、フルカラーカードは単純に本体と独立したVRAMを持つフルカラーモード専用(と考えていいです。実際には640×480 256色+32768色2画面モードもあるっぽいですが)のオプションカードです。専用NSDD(TownsOS V2.1L30の時点ではMX/MAの本体フルカラーにも対応していますが)経由で制御し、TownsFullcolor V1.1L10ではフルカラー画像をフルカラーカード側から出力させ、その他のGUIまわりは本体側から出力させて、映像信号をフルカラーカード側でスーパーインポーズすることによって処理しています。

ハイレゾモード対応を含めたものというと、アップグレードカードのほうになると思います。実物を持っていないのでどのような挙動をするのかは不明ですが(秋葉原で中古がたたき売りされていたときに入手すればよかった…)、Oh!誌に掲載されていた写真のチップ点数を見る限り、本体VRAM 512KB(スプライトRAM含まず)+カード上VRAM 512KBの合計1MBでMX/MA/HA/HB/HC同等の新画面モードが使えるようになるっぽいです。もちろんOS(TBIOSやWin95のドライバ)側の対応は必須ですが…

2020-10-25 17:40:17

新バージョンを試してみました。

どうもCRTC2のレジスタ0x0000 bit0はCRTC切り換えとはあまり関係のない機能のようで、これを有効にしているとこちらで確認した範囲ではMiV、TownsOS標準の「システム設定」、EGB_MF.BINを組み込んだ状態のTownsMENU(TownsSHELL?)等でウインドウサイズが1024×768ピクセル分に広がって何も表示されないという現象が発生しました。
そのあたりをこちらで手直ししたもので調べてみた結果、フルカラーモード対応は当然として(TownsFullcolor,MiV,ViXで確認)、前回のバージョンにあった表示異常(1画面モードで映像がおかしい、MiVで互い違いの表示になる)も直っていましたし、J-TYPEやTownsMENUが使用している2画面モード、MiVやTownsMENUが使用しているハードウェア拡大も問題なく、概ね良好と言った感じでした。

現状の津軽は、CRTC2対応に関してはUnzよりいい感じです。

2020-10-25 19:02:32

早速テストしていただきありがとうございます！レジスタ0の切り替えは問題ありのようなので、無効にしておきます。ちなみに、なぜそうしたかというと、画面モード22番を一度使ってしまうと、プログラムを終了してもTowns MENUがHigh-Res CRTCを有効にしないという問題が出たからなのですが、そういう理由で22番は公式に非対応なのかもしれないし、あるいは、別の何かを僕が見落としてるのかもしれません。

しかし、秋葉原で中古がたたき売りのときに買えばよかったものはたくさんありますね。レトロゲームとかカゴで500円とかで売ってた時に買い戻しておけば良かったと後悔してるものがたくさんあります。今日もヤフオクでFM77AV専用Dig Dugが18000円とか値段ついてるし。

2020-10-25 22:16:19

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

2020-09-24 09:40:33

昨日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

スレッド分けました。内蔵CDが故障してしまったTOWNSをフロッピーディスク経由でSCSI CDから起動するブートローダープロジェクト用スレッドです。一応、フロッピーディスク経由の場合と、SCSI2SDや変換番長のような仮想SCSIデバイスからの起動の両方を想定してます。似たようなことは既にYSSCSICD.SYSでできていますが、TownsOS起動ディスクに組み込む必要があるので、ディスクの再配布していいか微妙なのと、特殊なドライバを組み込むタイトルでは専用起動ディスクが必要などの問題がありましたが、このプロジェクトはその2点の解消を目指してます。

まだ津軽上の実験ですが、SCSI CDドライブからIO.SYSを読み込み、INT 93Hなどをインストールして、MSDOS.SYSまで読み込んだところで処理を迎撃することに成功しました。まだ青森県地図の表示はできてません。

しかし、迎撃地点ではMSDOS.SYSは読み込んでいるものの、まだINT 21HがEnableされていないようで、INT 21H AH=48Hでメモリを確保してやろうと思ったら固まってしまいました。これ、INT 21がまだ使えないのではなく、実はPSPとかが存在してないからという可能性もあるんですがね。ただ、考えようによってはBIOSのRedirectorをインストールしようと思ったらこの迎撃地点は悪く無くて、IO.SYSには内蔵CD-ROMから起動したと思い込ませているはずなので、ここでINT 93 AL=C0HがすべてSCSIにリダイレクトされるようにすると、IO.SYSは何事もなかったかのようにSCSI CDから起動してくるはずです。

問題は、リダイレクタをインストールしたとして、リダイレクタが使用するアドレスがその後別のプロセスに上書きされてしまうことを防止しなくてはならない点です。そのために、その後さらに調べたところ、どうも、MSDOS.SYSにジャンプするときのDXの値がMSDOS.SYSが使ってもいい最後のアドレス (DX=B800Hだと物理B8000Hまで使える)になっているようなのですが、どなたかこの解釈が正しいかご存知の方いませんか？また、そうした場合、DOS ExtenderがB8000～BFFFFを使わないと言えるのかという問題もあるのですが。nabeさんとか知ってそうと期待していたりするのですが。もしもこの解釈が正しければ C000H をDXにセットしている場所にパッチを当ててやれば、BIOSリダイレクタ置き場を作ることができるはずです。

これまで津軽のデバッガでMSDOS.SYS入り口で止めてLET DX B800H として放流してやった上でV2.1 L20上で何本かEXPファイルを走らせてみた限りではB8000～BFFFFは守られているようでした。

別な方法としては、もともとのCD-ROM BIOSはいらなくなるので、IO.SYSを識別して、もとのCD-ROM BIOSが書いてある場所にリダイレクタをインストールしてしまうという手もあるのですが、やや乱暴な方法で、多分CD-ROM BIOSは一か所に固まっているのですが他のINT 93Hがその部分のPROCを使っていたらこの手は使えないですね。

また、できればC0000H直前ではなくもっと下の方のIO.SYS直後あたりにインストールしたいところなのですが、どこでIO.SYSが使っていい領域の最初のアドレスをMSDOS.SYSに渡しているのやら。それはまだ見つかってません。ただ、IO.SYSのサイズはTownsOSのバージョンによって異なってもどのTOWNSのMSDOS.SYSを使っても起動できるということは、どこから使っていいかという情報もIO.SYSはMSDOS.SYSに絶対渡しているはずなんですがね。

2020-09-24 09:22:42

ご確認ありがとうございます！我がHRではRAYXANBER動いています。CDIMAGEまたはFDIMAGEからの起動で、BOOTSECTでの確認はしてないです。機種によって結構差があるのかもしれません。現在UXでまったく起動しないという報告があって(FD BOOTとかの最初の文字もでないらしい)、386SXで使えないインストラクションなんか使ってたっけ？と思いながら調査中です。

2020-10-11 08:05:14

調査中ですか。了解しましたm(_ _)m

2020-10-11 12:00:58

なぜUXで起動しないのか原因はまだわからないのですが、RS232CクロスケーブルでTOWNSとPCをつないでCMOSのバックアップ・リストア、それとROMイメージの吸いだしができるようになりました。TOWNSが使ってるシリアルIC、i8251は38400bpsまで安定して出ることがFM-7実機再稼働プロジェクトのときに判明していたので、試したらTOWNSでも38400bps出たのでデフォルトは38400bpsになってます。試しに76800bpsも試したのですが、さすがに出ませんでした。

これにより、CMOSはPC上にバックアップを取っておけば消滅しても復活できるようになりました。というか、バックアップしておかなくてもエミュレータ上で作ったCMOSイメージをそのまま転送してしまえばいいだけになり、エミュレータと実機の連携がよりお手軽になりました。

新しいTOWNSをヤフオクで落としたときなどは、このブートローダーでROMの吸出しができます。ROMを送信するのに約12分ですね。XMODEMで一本のファイルになるので、それを分割するユーティリティdecomrom.pyもUTILにあります。このぐらいやっとけば相当コンディションが悪い実機もなんとかなりますかね。UXで動かないという報告が気になってるのですが、手元にUX無いのでどうやってデバッグしたもんか。

2020-10-13 10:00:25

>55 山川機長さん
「80386DXと80386SXの違いはバス幅のみで命令については違いは無い」と過去から聞いていたのですが・・・・なぜUXでは起動できないのか・・・・
バス幅が狭い為にプロテクトモードでは相対的に速度低下するのが、タイミング上で問題になっているのでしょうかね。
進行状況を画面に表示させるのが良いのでしょうけど、実際に表示されるタイミングが遅れるのであまり充てに出来ないし・・・UXって他にLED等のインジケータが無さそうですね。

XMODEMでのバックアップ・リストアに関しては、結構時間がかかりますね。
記憶だとTownsOS上での通信では、9600bps位が限界だったと思っていたのですが、38400bpsでも大丈夫なのですね。(リアルモードだからかな)
あとは、XMODEMだとどうしてもスピードが出ないのでプロトコルを換える手もありますが、実装側の手間とフットプリントの大きさ,利用しやすさ等から考えるとXMODEMが良いのだと思います。
(XMODEMでバイナリデータを扱う場合、最終データが1Ahで有った場合にデータとパディングデータが同一である事からデータの破損が発生する可能性が有りますので気をつけてください)

2020-10-14 07:52:33

今日は津軽の感想のメールが二本(どっちも英語)届いて気を良くしてました。

UXの状況ですが、報告によると一瞬メッセージが出た後固まるとのことなんですが、この一瞬のメッセージが"FD BOOT"だとすると、止まってるらしい箇所はFM-R互換VRAMアクセスの書き込み先バンク指定直後なんですね。コード読み直したらなぜかIPLの中では指定してなかった。ひょっとすると(手抜きしてパレット再設定してないもんで)UXは初期パレットが違っててカラーコード15が黒になってしまっているという可能性もあります。ここは、まじめに再設定するように書こうかな。ただ、一瞬出るメッセージは読み取れない、ということなんですが"FD BOOT"は1秒は出てるはずなんですよね。それが読み取れないというのはなんとも。

38400bpsが出るのは、多分ポーリングでRS232Cの監視以外何もしていないからだと思います。RS232C BIOSがリアルモードのBIOSだったので、プロテクテドモードに入ってしまうとRS232C割り込みが出てからリアルモードに戻ってI/O読んでまたプロテクトモードに戻って、だと間に合わなかったのかもしれないですね。赤本によるとMXはFIFO Bufferを使える (pp.829)とのことなのですが、これEnableしたら76800bps出るのかな？気が向いたらTowns実機でD77イメージをRS232C経由で転送するプログラムを書こうと思っているのですが。

ちなみに、RS232Cだけに集中させたらFM-7でも38400bps出てます。リダイレクタでテープ版ソフトをRS232C経由で流し込むと実機なのに爆速でロードするので死ぬ前に一度見ておく価値があります。AV40はI/Oでスピード指定なもんだから19200bps止まりですが、AV40に刺しても大丈夫なRS232Cカード(本体のRS232CカードをEnableすると刺した方が寝る)設計だけしてまだ実際にはまだ作ってません。コロナで引きこもってるから作ってみようかな。

2020-10-14 10:20:54

面白そうだったのでRS232Cを使ったcmosバックアップをHCとWindowsPCで使ってやってみました。ダンプの中に富士通の文字を確認。津軽で読み込んでみても正常でした。
システムROMのダンプもやってみましたが、こちらは何か不備があるのかxmodemの転送が開始されずWindows側がタイムアウトになりました。
使ってみた端末のOSはWindows10で通信にはMopTermかTeraTermを使っています。bps変更の都度テストメッセージは確認しています。

余談ですがTownsが38400bpsで通信するのは初めて見ました。シリアル通信も馬鹿にできませんね。

2020-10-19 21:46:51

テストありがとうございます！多分、ROMのダンプがHCでできないのは、PHYSDUMPが動かなかったのと同じ理由ですね。Pentiumだと何かUnreal Modeの動作が違うのだと思います。もう少し勉強が必要のようです。

2020-10-20 07:20:59

>>59
Pentiumのせいでしたか。
Towns末期の機体だけあって市販品も動かないソフトが多いですし仕方ないのかも知れないですが残念です。
なんか指摘したようですみません。

2020-10-20 21:55:02

いえ、そういう報告が無いとどこまで動いているかわからないですし、ありがたいです。何か他にも気づいた点があったら教えてください。PentiumでもUnreal Modeは普通に動くはずなので、多分マイナーな修正で使えるようになると思うのですが。

多分、本来はプロテクテドモードに一瞬入ったときJMP命令でCSも新しくするべきところをNear Jumpでごまかしているあたりが怪しいとみているのですが。多分、Unreal Modeじゃなくて一瞬フルにプロテクテドモードに入った方がいいんでしょうね。

2020-10-22 01:03:35

FMTownsのアプリケーションの動作報告用

2020-07-28 13:17:50

DINOSAURなのですが、僕がやると町出て帰ってこれるのですが、すると町から出られなくなるようです。これ、町に戻れなくなります？

こちらの現象ですが、初期状態だと「扉は固く閉ざされている」というメッセージが出ますが、長老に話すと扉が開くのですが、いったん外に出て帰ってくると、メッセージは出なくて、画面が一瞬暗くなって外に出るかと思うのですが、結局出られないという現象が起きてます。現在どこにフラグがあるのか解明しようとしてます。

2020-09-10 09:55:05

DINOSAURですが、DS:106FHが扉通過回数のカウンタになってるっぽくて、値が1以下になると扉を通れないようです。僕は町から出てすぐ戻ったので入れましたが、再度出ようと思ったら出れなくなりました。ひょっとして、町から出て何かするうちにカウンタが減るイベントが発生している鴨しれません。お時間のあるときに、町に戻れなくなった時点で、試しに、

EMB PHYS:3106F 7F

と、やってみて、戻れるか試してみていただけますか？そうであれば同じ原因ということになりますね。あとは、何の拍子に値が減ってるのか解明すれば、扉が通れない問題は解決するのではないかと思うのですが。あ、違うや。減ってる箇所見つけちゃった。けど、これだと扉を通ると確実に1ずつ減っていくことになるな。。。。じゃあ回復する場所を解明しないと解決しないのか。

それから、長老にいちいち話に行くのが面倒だったら、

EMB PHYS:3EF01 5

これで話したことになります。

2020-09-10 11:18:25

>100
"EMB PHYS:3106F 7F"とやってみた所、再度町の外へ出ることができるようになります。
"DM PHYS:3106F"とやると、町を出たり入ったりするとデクリメントされるようです。

うんづでは同じアドレスはオープニング以降ずっと00Hのままですね、一瞬だと判らないですが少なくとも大きな数値は入っていないようです。

2020-09-10 12:37:04

あー、DINOSAURはコピープロテクトですね。なお、一応再度書いておくと僕はアメリカに住んでるのでDMCA法に基づいてレトロゲーム保存のためのプロテクト解除は明示的に合法とのことです。日本も早くレトロゲーム保存のための法制度が整うといいのですが。

INT 93H AX=0720Hを2度読んで、シリンダ6のサイド0に9,10,11,12,13セクタ(おそらくそれぞれ256バイト)が存在することを確認してます。チェック箇所はBRKON INT 93 AX=0720で簡単に見つかります。確認した範囲では2度に分けて読んでます。Brandishと同じ方式に見えますね。プロテクトに通った場合は、DS:[106EH](物理 3106EH)に10Hが、通らなかった場合はDS:[106EH](物理 3106EH)に01H, DS:[106FH]に03Hを書き込んでいます。これは扉を通るたびにチェックしていて、一度ひっかかってDS:[106EH]に01Hが書かれてしまうと、一度扉を通るたびにDS:[106FH]がDecrementされ、0になったら二度と通れないというものです。おそらくシナリオディスク両方がそうでしょう。

D77イメージを作ればプロテクトごと再現できるはずです。が、現在2HDのD77が作れないので、D77に変換して、シリンダ6のサイド0に256バイトのセクタを追加してみたところ、普通に何度でも出入りできるようになりました。なお、使ったツールは、僕のpublic repositoryのsrc/FM7/utilに入ってるd77analyze.exeです。publicレポジトリのFM系のソースをFMレポジトリに分離しようとしてますが、まだD77ユーティリティはpublic下に残ったままになってます。

存在しないセクタの読み込み要求があったら気にしないで適当なデータを返した方がいいんだろうか。うーん。しかし、コピープロテクトも含めて再現したいと思っているので、ひっかかったときの動作も再現したいから、やっぱとりあえずやめておこう。

2020-09-10 22:33:58

>102
プロテクトか・・・ 動き的に何だかそんな気はしていました。
プロテクトに引っかかるのも正しいエミュレーション結果ですので、方針は支持します。
WIKIの方にも記載しておきます。

2020-09-11 06:51:24

Amaranth3が動くようになりました。-APP AMARANTH3でマウスインテグレーションも対応します。Amaranth3対応のためにFM-R互換モードの表示の扱いを直したので一緒に他のタイトルもいくつか直っててくれるといいのですが。あと、Splatter Houseその他でLOW RESモードで背景の一部が1ピクセル上にずれる問題もやっと原因を究明したので、直しました。これはLOW RESモードが問題ではなくて、HDS-HAJがゼロではない状態で横スクロールしたときレンダリングでVRAMのアドレス計算を間違ってました。例によって今テストを流してるので、全部通ったらソースをPUSHします。

2020-10-17 06:21:01

Invitationですが津軽だとデモが速いということなのですが、これって実機やUNZだとCPUクロックの影響でスピード上がりませんかね？

実機でテストすりゃいいんですが、CDドライブが健全なのが2FだけなのでCPUを高速にできませんでした(^_^;)

ただ、ざっと逆アセンブルしてみた感じだとタイミングはCPUによるBusy Waitで取ってるようなのでCPUが速いと高速動作してしまいそうに見えるのですが。多分000C:00009838がWaitで、

if(DS:[63D40H]!=0)MousePolling
else BusyWait

みたいな感じなので、おそらくDS:[63D40H]が本編フラグで、本編だとマウスのポーリングがI/O 6CHでディレイを入れるのでタイミングが速くならないのではないかと思います。

2020-10-19 06:41:20

>105 山川機長さん
Invitation(オリジナル版)のデモの速度ですが、実機やうんづでもCPUクロックに比例して速度が上がります(これは同時期のMistyも一緒です)。互換モードにさえすれば問題は解決するのですが、現状の津軽にはその実装がないようで…。
あと、本編のマウスポーリングに関してですが、I/O 0x006Cは3代目になってから新設されたポートなので、初代の時点…というかCONTROL.EXEのリボン絵の表示内容からして組み込み版がそもそも古いバージョンのTownsOS(&TBIOS)のInvitationでは考慮されていない可能性が高いです。

2020-10-19 09:55:20

りうさん、

了解しました。とりあえず、何かI/Oが実装できてないとか速く進みすぎているわけではないんですね。安心しました。情報ありがとうございます！

互換モードは、メモリアクセスウェイトなどを加えた場合のパフォーマンスの影響を考えると、当面はVMのCPUクロックの調整で対応する方向で行こうと思っています。所要クロック数が486に合わせてあって、メモリアクセスウェイトも無いので、初代相当ぐらいにしようと思ったら16MHzよりも結構下げないと合わないかもしれないですね。ラストハルマゲドンとか8MHzにすると快適とか動作報告に書いてありましたね。

2020-10-19 12:15:25

CMOSの件だけでも長くなる可能性があるかと思ったのでスレッド作りました。YSSCSICD.SYS開発時、津軽開発時に調べたメモに残ってるのが、

CMOS RAM
起動デバイス
[3182H] 起動デバイス種類が (Floppy:1 Harddisk:2)
[3184H] 起動デバイスユニット番号
MX ROMの逆アセンブルでも確認。2020/05/20参照。

臨時起動デバイス
[3C28H]
MX ROMの逆アセンブルによると、パッドAボタンを押して起動すると08H (AL=08,AH=00 に分解されてCD-ROM), Bボタンで 02H (AL=02,AH=00に分解されてFD0)

シングルドライブモード(多分)
[328CH] 0:解除 1:シングルドライブモード -> [33CEH]がこのバイトを含むチェックサムになってるみたい

ドライブレターをどうやったら割り当てられるのか調べてます。

2020-10-01 23:31:01

Zoomミーティング中暇だったので(不良研究員)調べました。comp_romのソースではCMOSの後半にチェックサムがあるということですが、どうもドライブレターとかシングルドライブモードが書いてある領域は、33CEHを使ってチェックサムが変わらないように調節しているようです。そういえば津軽初期のころは、なんとかシングルドライブモードの意味を解明して津軽初回起動時のCMOSの初期化はSYSROMにさせてホスト側でシングルドライブモードを解除させようと思ってたけど、このチェックサムの意味がわからなくて断念したんだよな。今ならわかる気がする。

ちなみに、ドライブレターの割り当てですが、割り当て後、31D0～31DAに「富士通」が書き込まれます。が、これは多分いつも一定だと思います。(たまたま昨日パーティションテーブルを解析しててこれと同じ文字列をチェックしていたのでわかった。すごい偶然。)

IO8:[31D0] 95 <- SJISで「富士通」
IO8:[31D2] 78
IO8:[31D4] 8E
IO8:[31D6] 6D
IO8:[31D8] 92
IO8:[31DA] CA

それで、ドライブレター割り当てですが、以下のようになっているようです。33CEHはシングルドライブモードの変更でも値が変わって、それ以外が増加した分減らして全体のサムが変わらないように調節しているように見えます。

ということで、これをもとにHD Image用ブートローダーにCMOS設定機能を追加してみます! 実現すれば津軽またはUNZ上で作ったHDイメージとSCSI仮想化ツールだけあればCMOSが死んだ状態から起動可能まで持っていけるはずです！

。。。。今日と明日はミーティングが山のようにあるんだよな。さすがにミーティング中にMASMプログラミングはできんから週末の作業だな。

IO8:[31DC] 00 <- 多分Aドライブ
IO8:[31DE] 00
IO8:[31E0] 00 <- 多分Bドライブ
IO8:[31E2] 01
IO8:[31E4] 05 <- 多分Cドライブ
IO8:[31E6] 00
IO8:[31E8] 02 <- ここが変わった (割り当て前FF)
IO8:[31EA] 00 <- ここが変わった (割り当て前FF) 上位4ビットがSCSI ID, 下位4ビットがパーティションぽい
IO8:[31EC] FF
IO8:[31EE] FF
IO8:[31F0] FF
IO8:[31F2] FF
IO8:[31F4] FF
IO8:[31F6] FF
IO8:[31F8] FF
IO8:[31FA] FF
IO8:[31FC] FF
IO8:[31FE] FF
IO8:[3200] FF
IO8:[3202] FF
IO8:[3204] FF
IO8:[3206] FF
IO8:[3208] FF
IO8:[320A] FF
IO8:[320C] FF
IO8:[320E] FF
IO8:[3210] FF
IO8:[3212] FF
IO8:[3214] FF
IO8:[3216] FF
IO8:[3218] FF <- 多分Pドライブ
IO8:[321A] FF

IO8:[33CE] 45 <- ここも変わった。↑で増えた分減ってるっぽい。多分チェックサム一定化調整。

2020-10-02 00:32:27

随分と前のことですが、モデル2のブートロムを追っかけたことが有って、その時に作成した使用CMOSの資料が有りました。
何分素人が逆アセして目で追いながら作成した資料ですので、間違っている部分も多いとは思いますが役に立てばと思い此処に書き込んでみます。

3180 ?(bit0をチェックしている)
3182 ?
3184 ?(3182とセットで使用 3184→AH,3182→AL)
318E ?(ジャンプテーブル?のベース)disk_command_04
3190 ?(上記テーブルで使用? 3198まで?)
3192 ?
3194 ?
3196 ?
3198 ?
319A ?(読んだあと、and al,0CFh xor cl,al jzと続く)
319C SS(現在のSS:SP)
319E SS
31A0 SP
31A2 SP
31A4 SI
31A6 SI
31A8 SP(ローカルSP)
31AA SP
31AC ?
31AE ?
31B0 ?
31B2 ?(起動時にクリアされる)
31B8 ?(起動時にクリアされる)
31BE ?
31CC ?
3A50～3A5A ?
3A64 ?SP(割り込み処理で使用)
3A66 ?SP
3A68 ?SS
3A6A ?SS
3A6C ?(MasterPIC IMR)
3A6E ?(SlavePIC IMR)
3A70 ?(割り込み要因レジスタの値)
3A98 ?
3B50 ?
3B60～3B6E CD_CMOS_PARA
3B70 CD_CMOS_DATA0
3B72 CD_CMOS_DATA1
3B74 CD_CMOS_DATA2
3B76 ?
3B78 CD-CMOS_DATA3
3B7A ?
3B7C ?
3B7E ?
3C22 ?
3C24 起動時のDX
3C26 起動時のDX
3FC6 ?
3FC8 ?

2020-10-02 11:09:53

ああ、ごめんなさい。
上の資料は元々モデル2で逆アセしてたのですが、途中でHCになったので混在している可能性が有ります。

2020-10-02 11:11:43

SCSIのPhaseのMESSAGE_INとSTATUSの順を入れ替えたら、とりあえずSCSIのエラーは出なくなりました。
が、HIMEM.SYSインストール中に割り込みハンドラを破壊という現象が起きていて原因を調査中です。
なお、デバッガで BRKON INT 21 AH=3D としておくとfile openで止まるので、pri cst するとどのファイルを開くとこかわかるようになってます。

2020-07-28 12:59:54

VERR/VERWありがとうございます。VERRを通過して、CLTS（0Fh 06h）で死亡しました。T-OSはなぜタスク機能を使ってるのか……。
お盆あんまり関係ないんですよね。まとまった時間取れれば集中してドライバ書いてたいのですが。

2020-08-14 21:33:10

CLTS実装ありがとうございます。TBIOSLD.SYSとTOWNS.SYSを組み込んだ状態で起動するようになりました。
ですが、COCO で forrbios.nsd を組み込むとコードでない場所（V86モード）を実行して止まるようです。
（COCOを組み込まなくても適当なEXPを起動してると同じようなところで停止。同条件でEMM386を組み込まない場合は問題なし。）

なんとなく根が深そうなので、お時間あるときに見ていただけら嬉しいです。

2020-08-15 15:15:40

あらぬ場所にジャンプしてしまう現象は、考えられる可能性として高いのは、
(1) Exceptionを正しく出してない。
(2) Exceptionの出し方が正しくない。
(3) Task Gateを使ってジャンプしている。
(4) CPUコアに未発見のエラーがある。
と、このぐらいだと思います。多分、(1)だと思うんですね。なんとか環境を作って調べられないか検討してみます。

2020-08-16 02:51:32

>>40
TOWNS-OS on DOS6環境を作るには、DOS6をインストールしたHDD区画に対して、TOWNS-OS V2.1L40以降のシステムCDを起動して、アイコンから新規インストール先として指定すれば、DOS6上にTOWNS-OSがインストールされます。

これで128MB超えのHDD区画もバッチリ認識……じゃなかった。これで上に書いた問題も再現します（V2.1L50にて確認）。

2020-08-17 18:16:55

了解しました！詰まったら、多分実家から回収してきたFM Townsシステムセットアップガイドを見ながらなんとかできると思います。（一応共著者に名前入ってるけどDOS6の部分は全部武井先生が書いた）。やってみます！

2020-08-19 05:36:29

状況再現しました。クラッシュは↓ですね？

3FF8:000014E1 FFFF

この直前がIRETDで、NT=1となっているので、どうやらTask Returnというのを実装しなくてはならないらしいです。戻ってくるアドレス自体は正しいのですが、素直にStack ReturnsしてしまうとVMフラグをクリアしてしまって、3FF8をセレクタと解釈してとんでもないリニアアドレスだと思っているようです。

想像なのですが、ここはRUN386の中のようで、このTask Returnした先でVMフラグをクリアして3FF8:000014E1に戻してRUN386に続きをさせるということではないかと見ています。

どのぐらい簡単か難しいかまだわからないので、ちょっと勉強してみます。

2020-08-19 08:45:30

うーん、もはやどれを信じていいのかわからない。i486 Programmer's Reference ManualのPsuedo Codeによると、

(* Protected mode *)
IF VM=1
THEN #GP(0)
ELSE
IF NT=1
THEN GOTO TASK-RETURN

と、あるものの、下の説明では、

#GP(0) fault if the IOPL is less than 3, to permit emulation

しかし、VM86モードのIOPLは3のはずだから、'less than'にはあたらない。ので、Pseudo Codeとテキストの解説が矛盾してます。結構こういう誤記なのか手抜きなのかわからない表記多いんですよね。

ここの記述→では、https://www.felixcloutier.com/x86/iret:iretd

IF(EFLAGS.VM=1)
THEN GOTO RETURN-FROM-VIRTUAL-8086-MODE;
ELSE GOTO PROTECTED-MODE;

RETURN-FROM-VIRTUAL-8086-MODE:
(*Processor is in virtual-8086 mode when IRET is executed and stays in virtual-8086 mode*)

とあり、その説明では普通にNTフラグにかかわらずStack ReturnするがVMビットは影響を受けない。とのこと。しかし、そんなことはi486 Programmer's Reference Manualを見る限りまったく書いてません。POPFDではそういう記述があるんですけどね。VMフラグそのたいくつかのフラグはPOPFDによって変化しないそうです。

それで、Task Returnを調べたところ、TSSにReturn先のTRが書いてなければならないことになってますが、EMM386環境ではタスクはひとつしかなくて、ほかのタスクにリターンしたくてもそもそも戻り先タスクが存在しなさそうです。

一番都合のいい解釈は、VM86モード下のIRETではVMフラグが変わらない以外は基本的に普通のIRETと一緒、とする説なので、そのようにしてみたところ、DOS6上でTowns MENUが起動しました。例によって現在ctestを流しているので、全部通ったらソースをPUSHしますね。

2020-08-19 09:44:41

>44 山川機長さん
もうある意味解決しているのかもしれませんが、INTELのia32_arh_dev_man_vol2a_i.pdfの該当個所を見てみると、

RETURN-FROM-VIRTUAL-8086-MODE:
(* Processor is in virtual-8086 mode when IRET is executed and stays in virtual-8086mode *)
IF IOPL=3 (* Virtual mode: PE=1, VM=1, IOPL=3 *)
THEN IF OperandSize = 32
THEN
IF top 12 bytes of stack not within stack limits THEN #SS(0); FI;
IF instruction pointer not within code segment limits THEN #GP(0); FI;
EIP ← Pop();
CS ← Pop(); (* 32-bit pop, high-order 16 bits discarded *)
EFLAGS ← Pop();
(*VM,IOPL,VIP,and VIF EFLAGS bits are not modified by pop *)

とあります。

2020-09-02 14:39:35

そうですね。とりあえずDOS6を走らすレベルでは解決しましたが、ありがとうございます！一応、i486 Programmer's Reference Manualというのを参考にしていて、Intelの公式出版物のようなのですが、エラーが多いです。Intel公式のSoftware Development Manual (多分ia32_arch_dev_man_vol2a_i.pdfがそれかな?) を参考にする方が良い、と、とある知り合いの方から教えていただいたので今後はそのようにしようかと思ってます。

2020-09-03 05:33:45

FMTowns実機や各種FMTownsエミュレータを使用する上での質問事項

2020-07-28 13:20:43

FMTowns新エミュレータ emufmtownsの情報交換用スレッドです

2020-07-28 12:45:08