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

では、手始めに私の困ったことから。
我が家の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

SHSUCDXだとTownsOS V1.1 L30がR:\RUN386.EXE読み込みができなくて起動しない、と、思ったら、IO.SYS内のMENU_DRVドライバ、バグってますね。

MENU_DRVの0A42:2AC0は、エラーが無い場合(CF=0)だとジャンプするのですが、ジャンプしてしまうと、次のPOP BXが実行されないため、スタックがずれて、DS,ES,AX,BX,CX,DXの値がもとに戻りません。ところが、保存してあるスタックポインタをリストアしてRETFするので、クラッシュはしません。延々R:\RUN386.EXEが読み込めないループになります。MSCDEXは自主的にレジスタを保存していたのかもしれません。

そこで、 JAE 2AC9h, POP BXを、 POP AX, JAE 2AC9h (AXはどうせすぐMOV AX,*されるからダミーポップにはちょうどいい)にパッチを当ててやると、エラーを回避できるようです。そして、自作版MSDOS.SYSだったら、DOSINIT内でこのエラーを検出してパッチを当ててしまえばいいんですね。

0A42:00002ABE 5B POP BX
0A42:00002ABF 1F POP DS
0A42:00002AC0 7307 JAE 00002AC9 -> 58h POP AX
0A42:00002AC2 5B POP BX -> 73h 06h JAE 2AC9
0A42:00002AC3 B80281 MOV AX,8102H
0A42:00002AC6 E9BB00 JMP 00002B84
0A42:00002AC9 E9B500 JMP 00002B81

というパッチ当てを我が互換MSDOSのDOSINITに追加したら無事Towns OS V1.1 L30も起動するようになりました。V1.1 L20の場合、素のMSCDEXを使っても、V2.1でなんらかのCMOS設定をするとR:\RUN386.EXEが読めなくて起動しなくなる現象があるっぽいのですが、同じ根っこかと思いましたが、違ったっぽいです。

今日は、MALLOCを実装したので、ここらで一度CD起動だけでもテストを書こうと思ったらいきなりTowns OS V1.1 L30でひっかかって、半日がかりで解明しました。またひとつ30年の歳月を経たバグを取ってしまいました。

2021-02-15 06:03:35

(まったく上の書き込みと関係ないけど)

最近の20歳代ぐらいの人の武勇伝、小学生のころからプログラミングができて云々を聞いて思うこと。

ワシの若い頃はのう、3次元グラフィックスの勉強をしておっても、遊んでないで学校の勉強をせいと言われたもんじゃった。

2021-02-15 09:21:03

社会的な環境もそうですが、
自分の若かったころと比べて、最近の若い人は最初から使える計算資源が桁違いなのがうらやましい限りです

一方で今の計算資源に慣れてしまった身としては
せっかくTOWNS動くようにしたのだから何かデモっぽいものでも作りたいなぁと欲だけはあるのですが
これはこれでメモリ(特にVRAM)ののんびりさを計測して改めて認識してしまい、悩んでいます

2021-02-17 19:46:15

結局、SHSUCDXがTownsのIO.SYS起動時に使えなかった問題は、作者のJasonさんにコンタクトしたところ、直してくれました。一応、僕が直したソースも送ったけどさすがは作者だけにもっとうまいこと直してました。

というわけで、新しいSHSUCDXでTownsOSが起動するかテストしてたら、Towns OS V1.1 L20のMENU_DRVにもバグがありますね。

Interruptの入り口なんですが、
0A7E:000046CE FA CLI
0A7E:000046CF 8C165640 MOV [4056H],SS <- CS:
0A7E:000046D3 89265840 MOV [4058H],SP <- CS:
0A7E:000046D7 BC7E0A MOV SP,0A7EH
0A7E:000046DA 8ED4 MOV SS,SP
0A7E:000046DC BC5A42 MOV SP,425AH
0A7E:000046DF FB STI

CSにするのを忘れてるので、MSCDEXのDSのどこかをばっちり破壊してますね。当然出口もこうなってます。

0A7E:00004848 FA CLI
0A7E:00004849 8B265840 MOV SP,[4058H] <- CS:
0A7E:0000484D 8E165640 MOV SS,[4056H] <- CS:
0A7E:00004851 FB STI
0A7E:00004852 CB RETF

ひょっとするとV1.1L20が特定のCMOS設定になるとRドライブの読み込みに失敗して起動しないのはここに問題があったかもしれません。これは、SSに値を入れた次の命令ではINTが発生しない80x86の特性を利用して、STI/CLIを削ることでCSのPrefixを入れる余地ができるので、以下のパッチで対応できますね。自作中MSDOS.SYSで確認しました。

ORG 46CEH
MOV CS:[4056H],SS
MOV CS:[4058H],SP
PUSH CS
POP SS
MOV SP,425AH
STI
NOP
NOP

ORG 4848h
MOV SS,CS:[4056H]
MOV SP,CS:[4058H]

なお、自作MSDOS.SYSはINT 21H AH=02H (PUTC)ぐらい簡単だろうと思って中身を読み始めたら、Ctrl＋C対応だとか、リダイレクト対応だとか案外いろいろあって予想を超える難しさに直面してま。だが、あきらめなければいつかできるはず。

2021-02-18 00:11:17

>215 山川機長さん
>ワシの若い頃はのう、3次元グラフィックスの勉強をしておっても、遊んでないで学校の勉強をせいと言われたもんじゃった。

まさかこの「遊び」が今に繋がっていようとも、親御さんにしたら想像もされてませんでしょうから・・・・
私も親になった今となれば自分もこの言葉は理解できますね。 でも私は私の方針として決して学校の勉強を優先させていませんけど・・・ これがどう出るかは楽しみでも有り不安でも有ります。

3次元グラフィックスに必要な演算や座標の演算なんて今や勝手にしてくれますし、何よりもCPUやGPUの速度や有り余るメモリ量が当時とは桁違いですので今の人は私たちの悩んでいた時点よりも、もう一歩か二歩先から考えるのが当たり前ですから。
でも、足元が疎かなような気がするんですよね、なんだか・・・「OSってどう言う作りなの?」とか、「この機能はどうやって実現しているのだろう?」とかっていつも思っていた人から見たら。

2021-02-18 10:17:27

> pinさん、

是非デモ書いてください！新しいプログラムが書かれている以上、FM TOWNSはまだプラットフォームとして死んでません！僕も今年はDemosplashに参戦する予定です。まだアイディアは無いんですが。

KhronosがVulkanなんていう失敗作を出してくれたおかげでOpenGLの先行きにまで影が落ちてしまって、今の計算力だったらソフトウェアのレンダラー書いても結構いけるんじゃないだろうかと思って、だったらCで書いたらTOWNSも対応できたりして、でも、486DX前提にしてもちょっときついか、とかいう思考が堂々巡りしてます。


> WINDIYさん

僕はC++を教えてますが、そこは難しい問題です。僕の脳内では、最近のコンピュータはものすごく脆い、工事現場の足場みたいなものの上に、大きなビルを建設しているように見えてます。既にあるものが多すぎて、学生さんに基礎をしっかり覚えてもらおうと思っても興味を持ってくれないんですね。基礎を知らない人がプログラムを書くから安定したものができるわけも無いように思います。COCOAの件なんか見てると、さもありなん、と思います。多分、基礎・基本を軽視する風潮が構造にまで悪影響を与えてるんじゃないですかね。なお、日本だけじゃなくて、アメリカも似たようなもんですね。

というような話を以前友達としたとき、だけど我々が30年以上かけて勉強してきたことを学生さんに2～3年で急に勉強しろって言ってもやっぱり無理なんだよね、ということになって、確かにその通りなんですけどね。でも、航空機だったらゼロから新しいの設計して作れって言ったらできる人もいるけど、例えばOSを作れって言ってできる人は、、、まあ、目立たないだけで、いるのかな。

ちなみに、INT 21H AH=02Hは多分なんとかなったので、今はFCLOSEをテイクオーバーしようとしてます。見れば、MSCDEXが面倒見てるドライブに関しては、単にINT 2FHにリダイレクトするだけなので、これは読み込みだけだったら案外早くできるんじゃね？と、思ったものの、ROMドライブ対応があったからやっぱりそう甘くないですね。僕は簡単なものでもOSを自分で書いたことはないので、興味深いですね。ただ、やっぱり書き方がBASICとアセンブラの時代の書き方ですね。かなりMSが公開してるV2.0のソースとマッチングが取れるのですが、取れない部分になると意味を理解するのがなかなか大変ですね。

2021-02-19 04:15:52

FM TOWNS、発表から32周年おめでとう!! …それだけなんですが(汁

2021-02-28 14:59:04

あ、そうか。キリのいい、020h周年記念ですね！二十h歳ですね！おめでとうございます！ (年齢の16進数表記推進委員会)

2021-03-01 00:06:59

もう20h年ですか。(←早速使ってます)
キリが良いので何か残したいな・・・・ と思いつつ、CD-ROMドライブの謎解析のためにロジアナを購入したりしました。
FDイメージの方もやり切れてないので、そっちが先ですね。(色々検討中ですが、やはりイメージデータはD77またはD77を拡張した物よりもFDX形式が良さそうな気がしています)

2021-03-01 23:33:25

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

2020-09-24 09:40:33

自己フォローアップです。

すみません、Super大戦略が特殊なことをしているのかと思ったら、実はそうでも無いんですね。さっきXM7で波形を出して確認したのですが、Key Off->Key Onしたとき、前のトーンがまだ鳴ってる途中だと、新しいトーンをゼロから始めず残ってる音のレベルから音を始めるんですね。いずれにしても、その場合だとスロットごとにタイマーを分ける必要があるので、やっぱりスロット単位でのコントロールが必要なのでその部分は必要ですね。(しかし音が鳴ってる途中から次の音を始めたらどうなるとかはさすがにマニュアル見ても書いてなかった)。多分、この修正を加えたらSuper大戦略もあの力強い音色が再現できるのではないか、と、思ってます

2020-12-18 07:30:45

リリース出しました！Super大戦略のオープニングはほとんど本物になったと思います！

悦に入って何度も聞いてしまいました。

2020-12-18 13:27:08

エンベロープを実機に近づけようと、実機MXを使ってDecay期間だけ音がなるようにして音の長さを計測していますが、実に興味深いですね。FM TOWNS Technical Databookの208ページの表は、まず「レート」のコラムが二つに分かれている意味がなくて(右半分がKCだと仮定してもKCは31段階)、レート0の場合は無限大になるのですが、何も書かずに省略してますね。この表、同じものをYAMAHAのYM2612じゃないチップのマニュアルで見かけたと思ったのですが、どこで見たのか思い出せずにいます。実測値と比べると208ページのdecay/sustain/releaseの時間は1割程度短い(速い)ですね。とりあえず、津軽弁は実測値ベースに修正しようと思います。

あと残っているのはAttack期間の計算とKCの最下位ビットの計算方法ですね。AttackはDecayでガクンと急激に落ちるようにパラメータを工夫してサンプルすれば長さを測れるし、KCはKS=3として実測を取ると解明できると思います。エンベロープを実測ベースにしたら、ほぼ本物を再現できるようになるのではないか、と、思います。あと、エンベロープを明示的に計算する方法をドキュメントできれば後世の誰かがYMチップを再現しようとするときに使えると思います。

しかしFM TOWNS Technical Databookは結構誤植や間違いとかあって、エミュレータ作りながら「まじかよ」と思ったことが何度もありましたが、10%の誤差があるとしてもYM2612のフェーズの長さの表を出していてくれたのは助かりました。それに10%だからそんな大きな誤差じゃないですね。ところどころで「おお、これは！」と思う情報が出てますよね。

引き続き精進します。

2020-12-20 00:51:51

ソースPUSHしました。今日は朝から実機でいろいろ設定を変えてトーンをサンプルして正しいattack/decay/sustain/releaseの時間を計測して、また、謎だったNOTEの計算方法も多分解明しました。YM2608公式マニュアル(YM2612と基本互換のはず)とFM TOWNS Technical Databookには、

N3=F11*(F10+F9+F8)+~F11*F10*F9*F8

と、あるのですが、多分F11がビット10なのはわかるとして(F_NUMBERは11ビットだからビット11は存在しない)、どうやら正しくはこうですね↓

N3=F11*(F10+F9+F8)

F_NUMBERをいろいろ変えてDecayにかかる時間を計測したのですが、F11がゼロのときは、続く3ビットを変えても時間に変化はありませんでした。具体的にどういうエンベロープになるのか、これで解明できたと思います。

多分津軽が出してくるエンベロープもかなり実測と合うようになったと思います。(が、ソースの中のテーブルその他は実測に合わせたつもりだけどまだ津軽弁出力と実測と波形比べてない)。

2020-12-20 06:38:29

ちょっと実機でスプライトの動作をみてみました。
こういう感じのようです。
https://imgur.com/a/6GVk68S

- SPEN: スプライトレジスタの1番にあるもの
- DP1: スプライトレジスタの6番にあるもの
- SPD0, PAGE: はI/Oポート044Chのもの
- display: CRTCのFA1は0として、スクリーン1の前半が表示されている場合は0、後半が表示されている場合は1

VSYNC:
- I/OポートFDA0hのVSYNCビットが0から1に変化するタイミング、すなわち垂直帰線区間に入った時
- （赤本のスプライトBIOSのところにはVSYNC終了のタイミングから画面消去・転送が始まるように書いてありますが…）
- VSYNCのアークがない状態ではこのタイミングで何も起きない
Finish:
- スプライトの転送が終了したとき

I/OポートFF82hのPS2ビットと同様に、SPEN/DP1による表示領域の切り替えは表示期間中にも起こりうるので、
スプライトコントローラを画面消去に使うソフトの対策は手間がかかりますね

2021-02-15 00:33:29

フリコレ11の「股を愛したいですねぇ」( \T_OS\DEMO\MOTPLAY )を津軽で動かすための調査の続きです

SPD1とPAGEレジスタの値を実機同様にVSYNCで変えてやると、とりあえずアニメーションが進むようになります
SPEN、描画、FA1の変更を観察すると、こんな感じのようです
https://imgur.com/a/sptRolL
- 上段: 改造した津軽がプログラムに提示するるポートの状態
- 中段: motplay.exp の動作
- 下段: 表示状態の推測
- w/o FA1: >>33 の観察結果に基づいたFA1の影響を加味しない表示ページ
- Display: FA1(0000 or 8000 が設定される)の影響を加味した実際に表示されると思われるページ

描画ピクセル数自体はそこまで多くないので高速なTOWNSだと1INTで描いているのに2INTの表示になってしまいそうですが、これはまた実機で試してみます

2021-02-22 03:05:17

pinさん、

Pull Requestありがとうございました。

なお、最新版ソースですが、シンボルテーブルの検索機能が増えました。今まで pri sym または dm sym で全部ドドーっと出てましたが、新しいやつをコンパイルすると、symfind (wildcard)で検索できたり、sym SEG で特定セグメントのシンボルが表示できたり、symproc/symlabelを使うと、プロシージャのみ、ジャンプラベル＋プロシージャのみの表示ができて、いずれもセグメント指定できます。よかったらご活用ください。

自作MSDOS.SYSは、FAT12/FAT16のクラスタ取得とバッファリングを自作プロシージャで置き換えに成功しました。CHARデバイスからの読み込みをひとまず無視すれば、FREADもなんとかなそうです。FOPENだと今度はまたディレクトリ探したりいろいろ解析し甲斐がありそうですが。しかし、CDドライブとROMドライブのみ対応版だったら案外早くできるかもしれない、そこまでできたらフォントROM空にしてもFractal Engineとか動くかもしれないという気になってきてます。MASMで書いてますが、うーん、しかし最近だとNASMにした方がいいのかな。でもシンタックス良く知らないし書き換えるの面倒だし。

2021-02-22 09:37:28

>>35
元々、MASM（や386|ASM）で書いててNASMに移行した経験から言うと、NASMに移行したほうが相当楽に書けると思います。コード部はほとんど一緒ですし、MASMですとCPUコード以外の部分が面倒くさくてしょうがないです。あとNASMのマクロ便利。

2021-02-23 01:32:46

FREAD (INT 21H AH=3FH)を独自コードに置き換えることができました。CHARデバイスからfreadしようとするととりあえず止まるようにしてあるのですが、あまり使ってる場面なさそうです。試しにリダイレクトとか使ってみたけどその部分に入ってこないし。

> [email protected]さん、

なるほど！NASMにするとDOSBox を使わずにアセンブルできるのが楽そうなんですよね。アセンブルしてMSDOS.SYSと混ぜて津軽起動するまでが一本のScriptでできるようになるし。FMT_SYSの方は既にNASMだし。確かに、それほど大きな書き換えせずに移行できそうな感じもしますね。一念発起して移行してみようかな。

2021-02-25 02:28:39

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

2020-07-28 12:41:40

>122 山川機長さん
メガドライブ(Genesis)の音周りの設計については、20年ほど前にXM7原作者のＰＩ．さんのサイトにも載っていました。
YM2612のPCM(ただのDACモード?)はポーリングする必要があるため、メインCPUである68000での制御には向いていないので、Z80Aから制御した方が音質的にも有利です。ただ、実際のところ、メガドライブ(Genesis)でYM2612のPCMの性能をある程度活かせたソフトはあまりなかったりしますが(大抵は風邪声)。

2020-12-28 13:00:42

リリース出しました！FMとPCMをひとつのチャンネルにまとめたところ、Emerald Dragonで出ていたチキチキノイズが無くなりました。

> りうさん、

現在、一部スロットだけのOn/Off機能を追加してみて試しています。リリースが残る問題を調べているのですが、YM2612って強制的に音を止めるレジスタなんてありましたっけか、と、書いている途中でひょっとして発音途中にRRを書き換えてるとか？と、思ったので実装してみます。うーん、しかしリリースが残る問題は、僕の環境ではStrike Commanderで着陸後ぐらいしかこちらで出てないんですよね。仕方がない、もう一周飛ぶか！(喜んでる)

と、思って読み返してみたら、

Key Off時にTotal Level(というか音色パラメータ全般?)の変更が

ああ！これはKey 「On」時にTotal Levelを変更してるんですね！なんか脳内でつながりました。やってみます！

2020-12-30 07:38:53

Strike CommanderでReleaseが残る現象解明できました！着陸して停止すると、BGMを止めるためにまずキャリアスロットのTLを126にして、その後キーオフしてるんですね。まずKeyOnの状態でのTL、RRの書き換えに対応したのですが、それでもまだリリースが残り、なんでかと思ったら、TLを126にしてからキーオフの間に一度もWAV生成が無かったので、直前の出力がまだTL更新前の出力レベルを元にしていたもんで、大きな出力レベルからリリースが始まってしまっていました。厳密には正しくないのですが、リリースに入った段階で最後の出力レベルがピーク出力を上回っていた場合はピーク出力に丸めるようにしました。リリースが残る現象はこれで解決したと思います。あと、リバーブも対応できているのではないかと思います。しかし、案外みなさんLFOは使わないんですね。ソースは先ほどPUSHしました。

2020-12-30 10:58:38

すんません、リリースが残る問題、直ってませんでした。今PUSHしたソースだと本当に直ってると思います。Strike Commanderは修正前から着陸後に「ツーン」というトーンが残る場合と残らない場合があったので、昨日テストしたときはたまたま残らなくて直ったと思ってたみたいです。

2020-12-31 01:24:53

Windows 3.1が行き詰ってますが、BRANDISHのマウスインテグレーションに対応したやつをリリース出しました。-APP BRANDISHオプションをつけると、486問題も一緒に解決するようにしたので、このオプションがあれば-PRETEND386DXはつけなくても走ります。D77形式イメージを作るとゲーム開始できることは確認しました。それと、富士通Air Warrior V2.1 L10のジョイスティックとスロットルインテグレーションも対応しました。-APP AIRWARRIORV2 を追加して、あとはWing CommanderとかStrike Commanderとかと同じようにジョイスティックの軸を指定すれば動くはず。オプションでRS232CをTCP/IPにリダイレクトする機能を追加しようと思ってるので、それができたらクロスケーブルによる直結対戦機能ぐらいは使えるようになりそうです。

2021-02-03 12:14:20

Wizardry Bane of Cosmic Forgeを試してみてるのですが、ハードディスクにインストールができないのですが、だれか成功した人いますか？フロッピーから起動するようにすればプレイには支障なさそうですが。デバッガでインストーラをざっと見てみたのですが、INSTALL.EXPに入ってから、INT 21Hでドライブ構成もチェックしている様子もなく、INT 93Hが出ている様子も無いのですが。RPGはクリア確認しようと思うとちょっと腰を据えてかからないとエンディングまで行けないのがつらいですね。それはシューティングゲームも同じだろうという話もありますが。いや、シューティングゲームの場合、腕さえあればかかる時間は短いはずですが、僕の場合シューティングゲームはあまり得意では無いですね。シューティングゲームはステートセーブができるようになったらある程度行けるかな。

2021-02-07 06:33:30

FM TOWNSの立ち上げから事業を牽引し、TOWNS現役時代には社長として手腕を発揮された富士通元会長の関澤義氏が1月20日に逝去しました。
https://pc.watch.impress.co.jp/docs/column/gyokai/1305033.html

自分のサイトにも文章を載せましたが、パソコン事業に於いても「柔の関澤」という表現がしっくり来るほどFM TOWNS時代のソフト開発者のバックアップ施策は強力で、TOWNSは個人市場・文教市場に於いて一定の支持を受け、ベンダーフォーラムからユーザーフォーラムへと移り変わったFTOWNSも1フォーラム体制となってしまった1998年4月から2004年9月まで継続して運営されてきました。
関澤氏の逝去を受け、ご冥福をお祈りすると同時に、自分も前任の故・山本卓眞氏がごく初期から携わっており、関澤氏にDNAが受け継がれたFMシリーズに縛られ続けるのももうやめようと思います。

…駄文ですいません。

2021-02-08 12:14:36

りうさん、

その記事、僕も見ました。FMシリーズをリードしてきた人たちが去ってゆくのは、仕方のないこととはいえ、寂しいですね。

そうですね、FMシリーズに縛られるように感じるかかわり方は健全では無いですね。

僕はFMシリーズでプログラミングを覚えて、そのおかげで今の自分があるので、あくまでも余力の範囲ですがFMシリーズに恩返しをしたいと思ってやってます。もしも自分の力が役に立つならば、FMシリーズの文化を後世まで残すことに何かの貢献をしたいと思っています。

そして、FMシリーズ動態保存プロジェクト、津軽プロジェクトは本業の方にもフィードバックできてることも少なくないんですね。研究業の方にはあまり役に立ってないのですが、プログラミングの授業ではいろいろネタになります。りうさんにも多くのヒントと助言ををいただいて、YM2612のエミュレーションをかなり改善できましたが、それを使ったMML再生ライブラリを作ったので、学生さんに使ってもらおうと思っています。自分はMMLで音楽を演奏するのが楽しくて時間を忘れて楽譜をMMLに変換して演奏したもんでしたが、最近C++で同じことをしようと思っても手軽に使えるものがありませんでした。津軽の副産物でライブラリを自作することができたので、何人かでもこれでプログラミングが楽しいと思ってくれる学生さんが出たら大成功です。これも、ある意味FMシリーズから僕がもらったようなもんです。

数年前、実家で眠っているFM-7とFM TOWNS 2Fを見つけたときは、古い友人と再会したような感動がありました。今は、主力PCの後ろにMXがあって、いつでも電源を入れることができるようになっていますが、気分としてはまさに旧友が後ろに座ってるような感じです。古い友はときどき疎遠になるときがあっても、再開するときはうれしいものです。

りうさんも、FMシリーズのコンピュータと、旧友のような付き合い方ができると良いですね。

2021-02-08 14:06:49

りうさん

何にしろ、縛られるのは宜しくはないですね。
とは言えいい年の人間となると何かに影響され、刺激を受け、ある意味縛られて人生を歩んできたのは誰しも同じだと思います。
「ここまで来たらトコトンやってやりゃ～」と思うも良し、「ここから方向転換だ」と思うも良し、りうさんには是非、「縛られているのではない,自分で選択しているのだ」と思って頂きたいと思います。

2021年現在、縁があって故障したFM77AV40SXが私の足元に有ります。
当時欲しくても買えなかった奴なんですが、30数年ぶりに所有する夢が叶ったので、こいつを修理して再稼働させるのが近々の夢になります。
(富士通はスローガンとして「夢をかたちに」を掲げていますが、まさにそれですね・・・ 良いスローガンだ)

2021-02-09 13:28:47

現在Windows 3.1の起動までこぎつけられないかと思ってCPUコアをいじってるのですが、まずLARインストラクションで詰まってたのでそれは単にLARを実装して突破したのですが、INT 91Hで詰まってます。

どうやら、Windows 3.1は、リアルモードのバイナリのうち処理を奪う必要がある個所に 63H (ARPL)を書き込んで、Virtual 86モードでINT 6を出させて処理をいったんカーネル側に移して、その後、IP+1から処理を再開、としているようです。最初ARPLを見たときは何かの間違いではないかと思ったのですが、最初のうちそのままで順調に進んでいるようだったので、どうやらARPLを書き込むこと自体は正しいようです。ARPLが書き込まれる場所の多くは、書き込み前は90H (NOP)になっているのも多分この書き換えが意図的なものであると考えて問題なさそうです。

INT 6ハンドラは、0048:00000102ですが、どうも169Cセグメント(DOS?)内でARPLが起きることを想定しているようで、INT 6を受けて、Exceptionが起きたインストラクションが63Hであった場合、Exception発生個所＋2バイトに飛び、その場でリアルモードへの切り替えが起こるように書いてあるようです。0048セグメントはひょっとするとEMM386かも。

しかし、あるタイミングでIDTが書き換わって、INT 6をハンドルするのが0028:80006E5Cに変わり、再度0048:00000102に変わった後で、INT 91Hのハンドラの入り口(07F9:000023F4)のARPLでINT 6が出た後、00B8セグメントのあらぬ場所にジャンプしてクラッシュしてます。INT 91Hのハンドラは先頭にARPLが書かれているのですが、+2バイトではリアルモードに切り替わるように書かれていない上に、00B8セグメントのベースは169C0Hを指したままなので、違うセグメントの無意味なアドレスにジャンプということになってます。

MSDOS.SYS以外のINTのARPLは0028:80006E5Cだとうまくさばけるようなので、IDTが書き換わるべきではないのか、INT 91Hは別の処理の仕方であるべきなのか、そもそももっと前の時点で何かがこわれててINT 91Hが出るべきではないのか、なかなか難しいですね。どうもこの INT 91H (コンソールBIOS) はコンソールに1BHを書き込もうとしてるようなので、すでにコンソールは表示されていないことを考えると実はINT 91Hが出ていること自体が間違ってるのか。

なお、Core i9のPCを買いました。最近シングルコア性能は世代が変わってもほとんど変わらんと思っていたのですが、案外変わってたんですね。多分486SXの66MHz近いスピードが出てるようでStrike Commanderが快適になりました。ただ、nVidiaのGPUだったので、OpenGLのVSYNC待ち（なぜかnVidiaはデフォルトでオンにしている)をオフにしないと待ちが入ってスピードが落ちるという問題がありました。

2021-01-21 00:40:27

その後、どうやらクラッシュしてるのはWIN386.EXEが起動に失敗してDOSに戻ろうとする途中のような気がしてきました。なにやらPage Faultが起きてるんですね。そして、そのハンドラの中で同じ場所に突っ込んでPage Faultが起きて、それをハンドルしようとしたところでどうやらあきらめてDOSに戻る途中三度目同じところに突っ込んで、三度目はIDTがEMM386のIDTに書き換わっているようで対応しきれなくてクラッシュ、みたいな感じです。そのPage Faultは000C8000～のFM-R VRAMにアクセスしようとして発生しているので、その領域にアクセスしようとしたらPage Faultになること自体は正しいっぽいのですが、多分、その領域にアクセスするパスに入ってくるべきではなさそうです。

それで、WIN386.EXE （DOS6もだけど)の中で、RETFをCALLFとかJMPFとして使ってる個所がたくさんあって、コールスタックがめちゃくちゃになってしまうんですね。ということで、シンボルに情報としてJMPF_BY_RETF, CALLF_BY_RETFを記録してそこに突入したら適宜コールスタックの更新の仕方を変えてデバッガで流れが見やすくするところから始めようと思ってます。先は長そうですね。IRET_TO_VM86 （Stack Return to Virtual 86）は考えてみたら検出可能なので対応したのですが。

2021-01-23 02:25:01

↑の問題は、Page FaultでCR2にリニアアドレスを入れてないという問題でした。それを直して、今は、INT 31Hが出てるのですが、対応するIDTのエントリが壊れているらしい (80286の16-bit Trap Gateだと思ってる) というとこですね。一応、今Unit Testを流してるので、通ったらそのバージョンのソースをPUSHする予定です。

2021-01-24 07:51:07

異なるPrivilege間のINT/IRETは同じPrivilege間のINT/IRETと微妙に動作が違うことに気が付いて実装したら↑の個所は通過したんですが、INT 31H AX=0602H (Mark Real Mode Region as Pageable)の中で戻るべきリニアアドレスのページテーブルエントリのPresentビットを0にしてしまって、IRETでPage Faultになってるところで止まってます。ひょっとするとこれが正しい動作でPage Faultを出すべきなのかもしれないんですがね、ただ、そこらじゅうでPage Faultのチェックを始めるとCPUコアが明らかに遅くなることが想定されるので、やるならIRETで抜けるところでチェックかと思ってるのですが、しかしここでPage Faultを起こすのも何か変な気がするので現在 INT 31H AX=0602H の中身を見てます。いやな予感としては、メモリを十分搭載していればPage FaultでSwapは起こらないだろうとみていたのですが、V86モードのかたまりのWindows 3.1だとPage Fault起こしまくりでリアルモードメモリをスワップしてたりして。それだと、それに対応するためにTownsオリジナルアプリの動作を遅くするぐらいならWindows 3.1は対応しない方がいいかもしれないですね。ある程度はFractal Engineのために対応してはいるのですが。

2021-01-30 02:36:21

山川機長さんのお気持ちとしては、"FMTOWNSで動作していたソフトウェアは全て動作する"を目指されているのだと思うのですが、状況を見ていると仰る通りTOWNSオリジナルアプリの動作が遅くならない方法が見つかるまではWINDOWS3.1を先送りしても良いように思います。
幸いにしてTOWNSでWINDOWS3.1を動かさないとならない人もかなり少ないでしょうし、実際の所はWINDOWS3.1に対応してもインストールする人は(ほぼ?)いらっしゃらない物とも思われます。(個人的には、WINDOWS3.1<Linux<WINDOWS95の順のような気がします)

それにしても、WINDOWS3.1って相当アクロバティックな作りなんですね・・・

2021-02-01 15:27:12

まさにその通りで、Windows 3.1はとりあえずこの間実機のHDDから既にインストール済みのイメージを抜き出すことができたのでやってみている感じで、Windows 3.1そのものにはあまりモチベーションが無いんですよね。Windows 3.1が動作しなければWindows 95も動作しないと思うのでやってるというか。ひょっとするとLinuxの方が素直にできているかもしれません。

それにしても、本来であればタスクを切り替えるとき、Page Faultが起こらないようにページをマップしたうえで切り替えるべきな気がするんですけどね。試しにIRETしたところでPage Faultを出してみたのですが、これで正しくメモリがマップされて戻ってきたらPage Faultをわざと出させている可能性が高まったのですが、ぜんぜん無関係の領域がマップされたので、それほど単純でもなさそうです。

春学期も始まってしまったので、多分この問題はしばらく放置状態になりそうです。

2021-02-03 00:41:18

ありがとうございます

2021-02-04 11:18:48

スレッド分けました。内蔵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

WINDYさん、

テストありがとうございます！ロストテクノロジーでも何か記録に残しておくと100年後ぐらいに誰かが見つけて役に立つかもしれませんね。

レトロPCはこうやって資料を保存できるけど最近のオンラインゲームとか将来に残らないんじゃないかと非常に不安です。まあ、この心配は今のゲームに燃えてる若い人たちがしてくれればいいことですが、学生さんとかには折に触れてコンピュータプログラムは工業製品であると同時に芸術性もあるというようなことを言う変な教員をやってますが。

2020-11-07 10:16:40

> 山川機長さん
起動オプションが保存されているのはいいですね。
今回のは津軽で見てみると16進数でカウントダウンしてブートするのですが、カーソルが2行ずつ動くようです。
実機ではブートローダーの画面が一瞬出た後に「不法な割り込みが発生しました」と表示されて落ちてしまいました。
カーソルは本家のブートセレクタとの兼ね合いもありますし、パッドでもキーボードでも動くほうがいいかと思います。

2020-11-08 00:48:20

むむむ、そうですか。やっぱ実機テストは必要ですね。というわけで今FM77AVにどいてもらったので今からMXでテストします(^_^;)

2020-11-08 03:53:54

大変失礼しました。直ったと思います。 MOV DL,60 DIV DL とすべきところを MOV DX,60 DIV DX と書いてました。津軽のCPUコアは割り算のオーバーフローを無視していたもんで。MXのFDIMAGEで動作確認したので多分大丈夫だと思います。キーボード対応も実機で確認しました。

2020-11-08 04:29:57

> 山川機長さん
無事実機での起動に成功しました。38400bpsでROMDUMPを実行してdecomrom.pyで生成したROMをTsugaruで認識できました。
Townsでこういうことが可能になるなんて凄いです。

なお、あまり重要ではないかも知れませんが、2行ずつ移動するのは津軽の起動オプションで解決しました。
"-GAMEPORT0 KEY"と"-keyboard trans2"(またはtrans1)を有効にしているときのみおきる現象で、
ANA0にしたりtrans0にすると起きないようです。
よくよく考えてみるとtrans2とKEYを同時に有効にしていること自体ちょっと変でしたね(^-^;

以上、ご報告でした。

2020-11-08 18:12:55

おおなるほど。不正な割り込みの方に気を取られてカーソルがふたつ動く問題の方が目に入ってませんでした。

矢印キーとパッドが同じ機能を持ってしまっている影響ですね。津軽の方で直す方が良さそうなので、直しておきます。津軽と実機で同じ環境が使えるのが理想ですね。

しかし、TOWNSのキーボードはキーが多いですよね。日ごろUSキーを使ってるのでそもそも変換と無変換が無く、全角・半角も無く、カタカナ・ひらがなも無いという、まさに津軽だけに「おら日本語キーボードさ行くだ」、と言いたくなってしまうのですが、日本語キーボードでもカバーしきれないですよね。実行キーないし。津軽上で長い日本語をタイプすることは無いとはいえ、仮に日本語をタイプするとしたらどうするのがいいんでしょうかね。

2020-11-09 01:00:13

キーボードエミュレーションモードの問題だから津軽側で直そう、と、思ったら実はブートローダーの方の問題でしたね。

実機でも同じことが再現できます。まずパッドの十字ボタンの下を押し、放す前にキーボードの↓キーを押し、十字ボタンを放すとカーソルが二段動きますね(^_^;)

まさにこれが発生してました。なので、ブートローダーの方を更新してパッドのリリース待ちの中でキーボードのバッファもクリアするようにしました。時間の都合でまた実機テストしないままPUSHしたのですが、さすがにキーボードバッファをクリアするだけだから実機での実害はないと思います。（でも一見無害な更新がよく大ダメージを及ぼしたりするんだな、これが。）

副産物でコード見直したらトランスレーションモードで日本語キーボードの数々のキーを送ってないことに気が付いたので送るようにしました。日本語キーボードだとタイプがちょっと快適になった鴨しれません。

2020-11-09 02:01:07

なるほどブートローダー側でしたか。判明して良かったです。実機でも津軽でもばっちりです。

キーマップの件は難しいですね。普段は別のキーボードを変換アダプタを通して使っているので、純正キーボードを引っ張り出して繋いで思い出していました。

英語キーボードの場合は英語が打てれば良いかと思いますが、日本語キーボードで現状の最低限の英数記号が入力できてWindowsのIMEが有効な状態から長い日本語を打てるように変えるとすると、IMEを無効にする必要があると思います。

ソースを見てkeytrans.cppのNULLの部分を、townsdef.hを参考に書き換えればいいのかと思ったのですがビルドは通るものの、うまくいきませんでした。

文章を入力するとしたら、最低限「ひらがな」「変換・無変換」可能なら「漢字辞書」で足りると思います。
漢字辞書キーはありませんのでShift+かな漢字とかShift+Insとかコンビネーションに割り当てればいけるでしょう。
あまり使わないキーは単語登録、単語抹消、実行と取消です。取消はごく希に使うかも知れません。

ちなみに自分の使ってるクラシックPC研究会さんのアダプタは取消がEND、実行はShift+Enterになっています。

2020-11-10 03:06:45

ありゃーす

2020-12-06 22:08:24

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

たまにはこっちにも書いてみます(?)

TownsOSや起動時の処理に影響するCMOSの内容を、既知の物も含め2点あげておきます。

3C1A 起動時メモリ診断モード(0=通常モード、1=簡略化モード) 3代目あたりから有効
3AD8 各種フラグ (bit7が1の場合、高解像度モードモードON) ハイレゾ機で有効(とはいっても起動時に参照するわけではない)

2020-11-07 12:31:39

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

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