amelog

MSX-DOS2 TOOLSを買う前に、
MZ-2000でCP/Mのフロッピーを読み込み、M80やL80などを自作の通信I/FでMSXに送り、MSX-DOS1上で動かしていた話を以前書いた。
だから、別に買わなくて良かったような気もするが・・・

CP/Mのフロッピーを読み・・・といってもMZ-2000用ではなく、他機種（確かX1とかPC-8001用)のフロッピーだからファイル直接操作できなかった。
先頭から順番にセクターダンプして、このへんからこのへんまでが、どうやらM80らしい、と目星をつけていた。
ひたすら根性ですよ。ずっとダンプを見ていかないといけないから。

一旦、MSXのフロッピーに持っていった後は楽だった。これでMSX-DOSはCP/Mの上位互換なんだなと実感した。

CP/Mを作ったゲイリー・キルドールは、MS-DOSはCP/Mのパクリだと訴えていた。「新・電子立国」のソフトウェア帝国の回で、そんなインタビューがあった。
そのインタビューの直後になくなられたという。

ゲイリー・キルドールの会社（デジタルリサーチ）はDR-DOSというのを出していた。

フリーソフトでは、FreeDOSというものがある。

M80の話に戻ると、
まずM80でアセンブルして、その後L80にかける必要があった。
それ以前に使っていたアセンブラは1パスでバイナリが出てくるので、そっちのほうが便利そうだった。やっぱり今まで通りでいいじゃないかと思った。
本末転倒ってやつか。
しかし本格的にZ80の開発をするにはやっぱりM80などを使っていかないと・・・。
バッチファイルを作って、簡単な操作でできるようにした。

M80はマクロアセンブラなので、マクロを組むとプログラミングを少しでも楽にすることができる。あるいは応用として、別のマイコン用のアセンブラを作ることもできる。
そんな実例を雑誌の付録か何かで当時見たけど、こんなの今となってはどうでも良いことですね。

MSX-DOS2 TOOLS
MSX-C
これらは私が学生だった頃、アスキーが現役でソフトを販売していた頃に通販で買いました。
金銭的に厳しかったので、ずいぶん思い切った買物でした。

後にMSXマガジンの付録になるとは思いもしませんでしたが、その当時に買っておいて正解だったでしょう。
MSX-Cの解説書も買いました。最初は使い方がわかりませんからね。うまいこと商売に乗せられた感じもします。その解説書も後に、MSXマガジンの付録になりました。
後に、といっても10年後ぐらいです。

MSX-DOS2 TOOLSは特にアセンブラのプログラム開発には役立ったと思います。
テキストエディタ KID/AKID
アセンブラ M80
リンカ L80
などなど・・・

テキストエディタは、それ以前に使っていたPEDのほうが慣れていて好きだった。
慣れてきたらKIDかAKIDを主に使うようになったけど、変な文字コードが混ざったりしてアセンブルエラーの原因になったりしなかったっけ。
何も文字がないところでバックスペースやDELETEを押しまくったりして、その後にアセンブルしてみると通ったりする。
相棒はPEDを愛用していたな。
自分は、せっかく買ったので仕方なく使っていた感じ。

当時テキストエディタといったら、PC98の世界ではMIFESを使っていたっけ。あとでVZを知ったけど、操作に馴染めなかった。
それとフリーソフトではSE3というのがあって、京都コンピュータ学院が製作したもの。
実際、自分が通っていたコンピュータ学校ではMIFESをみんながピーコして使っていたのだけど、そういった問題がないようにとSE3が作成されたのでした。

アセンブルのたびにフロッピーの読み書きが遅いもんだから、RAMディスクを活用していた。
これも思い切った買物だったFS-A1ST、RAMは買ったままの状態で256KBだったと思う。

当時手作りしていたマイコンのBIOSからモニタから、ライブラリやアプリケーションまでプログラムを作っていた。
8251カートリッジも最初作った時は失敗したけど、後に作り直してちゃんと使えるようになり、マイコンの開発にも活躍した。そのターミナルプログラムも自分で作ったっけ。

なにしろ当時はパソコン通信がなかった。自分にとっては。
電話回線を引いてモデムをつければできただろうけど、お金に余裕がないのに課金されるようなものは手を出さないほうがいいなと思った次第。

MSX-Cは結局よくわからなくて、たいして使わないでそのままだったような気がする。

学校でPC98を使い、C言語のプログラミングをやっていたけど、どっちかというと当時アセンブラ至上主義者だったのでMSXでC言語はチョット・・・と思っていたようだ。
メモリを食いそうなので。（そんな大きなプログラム作ったっけ）

いまの話ではなく、’90年代始めの頃の話
まだまだ未熟だった私でした。

MSXマガジンか何かの改造記事を見て、自分のFS-A1STもRAM増設しようとした。
空きパターンにDRAMをはんだ付けして、あとは抵抗をチョコチョコと。簡単だ。

そうだ、念の為にソケットを使おう。（これが悪夢の始まり）

その時に使ったソケットは、ご覧の通り（実際は18Pか20P、忘れた）


無事、改造は成功した。
起動画面に表示されたRAM容量を見て大喜び。
（実際に使うのか？）
RAMディスクとして使った。アセンブル、コンパイルが速くなった。
それ以前の学生時代からRAMディスクは重宝していて、容量が増えてありがたい。
だけど作業が終わった時点でフロッピーに書き戻すのを忘れてしまい、一気に天国から地獄の底まで落ちたこともあるけどな。
(そこで、書き戻すバッチファイルを作った。確か、ソースだけはコンパイル時に必ずフロッピーへ書き込むようにした気がする。)


ところが・・・ある日、RAM容量表示が増設前と同じになった。アレ？
勝手に変わったりする。おかしいなあ？

ははあ、ソケットの接触が悪いんだ。こんなソケットだからイカンのだろう。
接点が片側しか接触しない構造になっている。
わかっていて使ったが、こんなにダメとは思わなかった。
少なくとも、両面から接触しないとな。丸ピンだったら周囲から包むように接触するから信頼性が高い。

とりあえず、この板バネソケットを取り外して、丸ピンソケットに交換しよう。

その取り外し・・・
当時はハンダ吸い取り線とスッポンしか持ってなかったから、結果から書くと見事に失敗。パターンを壊してしまった。剥がれて切れたり、スルーホールが抜けたり。

FS-A1STの基板は特殊で、配線パターンが見えない。当時のエレクトロニクス雑誌に載っていたけど、銅ペーストといって配線パターンの上を銅でシールドしてしまい、輻射ノイズを抑える狙いが有った。
しかしそれだと修理ができない。パターンを切ったりつないだりなんてあり得ないという思想だろうな。量産基板に適用するから良いんだと。

いまでこそ回路図は出回っているが、当時は回路図なんて手に入らなかった。修理に出したら高額になるだろうな。就職したばかりでお金もない。
DRAMの配線を可能な限り追って調べた当時のメモが今も残っている。あきらめきれなかったんだろうな。

結局あきらめてしまったのでした。

ソケットの接触を改善する方法を最初に試したらどうなのか？って思うでしょうけど、その当時に思いつかなかったでしょう。何度か抜き差しをしてみたりしたかもしれない。覚えてない。
あとから色々言うけど、失ったものは取り戻せないんだからなあ。

・・・・・・

幸い、どうにかこうにか基板だけ手に入れて交換し、復活したわけです。

二度とあんなソケットは使わないと心に決めました。（某＊＊で当時よく売られていたものでした。安かった）

MSX BASICのソースを見れば乱数発生の仕組みがわかると思うけど、いや、昔調べたような気がする。覚えてない。

学生時代に同級生がテトリスを自作して、その時に使った乱数ルーチンはMSXのROMではなく、独自に組み込んだもの。Z80マシン語秘伝の書に載っていた乱数ルーチンをアレンジしたと思う。

当時でも議論したけど、じつは乱数ってのは意外と難しく、完全な乱数って作れないのです。

BASICに内蔵されている乱数は、算術乱数というやつだったと思う。計算で次の値を求めている。どうしても偏りがある。
ある数に別の数をかけたり足したりして、その下位桁を取るとか、そんなやり方です。だからパターンが決まってしまう。不確定な要素が含まれてないわけ。

MSX-BASICにはTIMEという変数(カウンタ)があって、1/60秒ごとにインクリメントされているから、これを利用する手がある。何か押した瞬間の値を取るとか。プログラムをRUNした時に値を取り込んで乱数の種にする。
別に、TIMEに依存しなくても入力を待っている間にカウンタを適当に回しておいて、HIT ANY KEYで押した時の値でも良い。

パチスロ機の場合は、ハードウェアカウンタを回しておき、レバーを叩いた瞬間の値をとるというやり方でした。
これは昔、体感機で同期できてしまっていたので、その後に対策がとられて、ずっと高速で回るようになっていると思われます。

完全な乱数が必要なら物理乱数になります。電気的なノイズを利用したものがよく使われると思うけど、それだって外乱を受けるようではダメです。

MSX用乱数発生カートリッジとか？　需要ないだろうな。

あと、円周率を小数点以下何万桁までテーブルに記憶しておいて、そこから値を拾ってきて使うと乱数代わりになると本で読んだ事があるけど、良いのかどうか知らない。
この場合でも、順番に読むんじゃなくて、さっきのキーを押したタイミングでどこを読むかというやり方を組み合わせたものだと良さそう。

乱数の再現性を求める場合は、あらかじめデータとして蓄えておかないといけないな。ゲーム等では再現性は求めない場合がほとんどだろうから、いかにばらつかせるか、偏らせないかということになる。

プログラムが残っていました。中学生の頃の古いノートからです。

改良前のプログラムで、バカ正直にIF文で処理しています。




バカだなあ・・・と笑ってやってください。
一方で、動けばいいんだ、という考えの方もいらっしゃると思います。

オモテとウラ、というのはコインの裏表の確率をシミュレーションしています。

乱数RNDはゼロから指定の数値未満まででした。確か。
それにわざわざ+1して1～6にしたのでしょうけど、最初から1～6を0～5に置き換えて処理したって構わないわけです。
表記としてはわかりにくくなるかもしれませんが、計算をひとつ削って処理時間を少しでも節約できます。

冒頭のRND(-TIME)は乱数のタネでしょう。（初期値）TIME変数を元にしています。

それから、
いま何回目かを常時表示しているとその表示に時間をとられます。そこで、たとえば100回とか1,000回おきに表示したかった。
これも馬鹿正直にIF文で判定させています。そうじゃなくて、1,000で割り切れて余りが0かどうか見ればよかったのではないか。あるいは、別にカウンタを回してIFで判定するほうが早ければそっちを採用しても良かったのではないか。

当時そのことは気づいていて、実際にそのような判定を入れた記憶があります。

処理速度を上げるには、整数型変数を使うようにプログラム先頭にDEFINT A-Zとすれば改善が見込めたものと思います。
しかし32767までしか扱えないのと、相対度数の計算で小数点が出てきます。
とりあえず3万回までのシミュレーションに限定すればよいでしょう。
あとは、相対度数の計算に関係する変数だけ浮動小数点のままにすればよかったでしょう。