SHARP MZ-2500を使う! その2

引き続きMZ-2500で開発環境を整えている!

Hello World、そしてメモリダンプが作れたので、これまでのレポートをば。

 

f:id:PocketGriffon:20210930191231j:plain

MZ-2500といえば、CPUにZ80Bが積まれている事が有名だけど、私の人生におけるZ80BはMZ-2500で2台目だ。1台目は沖のif800 model30を使った時だった!

 

当時はBタイプのZ80なんて聞いたことがなく、かつif800のとてももっさりとした動作を見ていたので、BタイプはAよりも遅いんだと思いこんでいた。

その後、MZ-2500が発売された時に6MHzと聞いてたいそう驚いた!

実は速かったんじゃないの、if800は…と思い、もう一度触るチャンスが欲しいと思っているが、あのでっかい筐体を手に入れる気にはならず…今に至る(^^;;

 

先日「Hello Worldが表示できたよ」とツイートしたが、あれはどちらかと言えば「開発する環境が整ってきたよ」的な意味合いが大きかった(^^)

前回のブログで「RS-232Cでの通信が出来たよ」と書いたが、もう少し詳細を書いてみようと思う。この時代にそんな情報が欲しい人がいるかどうかは疑問だけど(^^;;

 

ファイル形式と通信速度

MZ-2500に送り込むプログラムの形式は、こんな感じになった。

f:id:PocketGriffon:20211001103117j:plain

行番号はゼロサプレスされてるんだけど空白が残るという不思議な形式。これはMZ-2500本体から「SAVE "COM:",A」とした時にこのように送られてきたので、それを真似るようにした。

4桁分しかないんだけど10000超えたらどうなるんだろ…汗

 

マシン語領域は(暫定的に)&HE000からとし、マシン語データはそのままPOKEする形とした。MZ-2500はこの形式が一番速そうだったので!(事実、実行開始の待ち時間はほぼ無い)

予約語はなぜか小文字。これはなにかスイッチがあるのかも???

 

改行コードはCRLF(&H0D,&H0A)。

ファイルの最後には&H1Aではなくて改行コード2つ。この改行コード2つがないとMZ-2500側が通信終了を検知してくれない。

 

このフォーマットのファイルをホストマシン側で作り、MZ-2500へ送り込むようにしている。通信に時間は掛かるけど、フロッピーでやりとりしたり実機で開発するよりは効率が良いのでは…と思っている(^^)

 

しかし、なぜか通信速度がとても遅い。9600bpsを設定しているけれども、実際に転送に掛かってる時間から考えると1500bpsくらいしか出ていない。これも何か設定の不備があるんだと思うけれど、今のところ分かってない(-_-;

 

開発環境と開発言語

RS-232Cでプログラムを流し込むことを前提としているという事で、開発自体はMZ-2500本体ではなくてホストマシンで行っている。

 

編集は、普段から使い慣れたMacで行っている。私はMacBookPro(ノート型)使い。

アセンブラはLSIC-80付属のものを使用している。ということで、C言語も使う。ブート+速度を要する部分はアセンブラ、それ以外はC言語という感じの構成だ。

 

残念ながらLSI-80はMac上では動かない。仕方ないのでファイル共有をしたWindowsマシン上でビルドをしている。Remote Desktopで繋げたWindowsで「make」と打ち込むだけの簡単なお仕事だ(^-^)

 

LSIC-80付属のアセンブラは、そもそもの使い方がCコンパイラが出力したアセンブラファイルを扱う事を前提しているせいか、機能が豊富ではない。そこで単体でも使いやすいようにプリプロセッサを通すようにしている。おかげでマクロや条件アセンブルが出来るので使い勝手は上々だ(^-^)

f:id:PocketGriffon:20211001105712j:plain

自分なりのライブラリを整備していってるおかげで、なんとなくBASIC感覚でプログラムが組めている。こうなってくると楽になるね(^-^)

 

IOCSを介さずにテキスト表示を行ってみたかったので(単なる興味)、あれこれ画策していた。テキスト画面に書き込むコードに面食らい、スクロールに追従する方法が分からずに苦戦したが、なんとか表示出来るようになった。

 

メモリダンプを作ってみたい!

せっかくテキストに表示出来るようになった、あーんどメモリの内容を見てみたい!って事で、いつもの流れでメモリダンプを作ってみた。

f:id:PocketGriffon:20211001110108j:plain

作ったメモリダンプはメモリマッピングに対応していて、MZ-2500の全メモリを見る事が出来る……と書きたかったが、辞書ROMなどのバンク切り替えには対応出来てない。これはダンププログラムを作るタイミングで、バンク切り替えの存在に気がついてなかったからだ(ToT)

 

表示はリアルタイムに更新されていて、割り込みなどで値が変わるメモリはその状況が見える。おかげで割り込み時のワークエリアなどは見つけやすい。しかし今回はプログラム解析をするつもりがあまりないので、そのまでの必要性は無かったのかも(^^;

 

これを作る際、いろんな本を参考にしていた。

主観では有るけど、本について思ったことを書いてみたい。

f:id:PocketGriffon:20211001110823j:plain

工学社から発売されていたテクニカル・マニュアル。

基本的に工学社から発売されていた活用研究的なものは、無条件に全部手に入れていた。

基本的にIOCSの使い方が書かれていて、サンプルも少なめ。今のところ使用頻度はそこまで高くない。というか、ほぼ参考に出来てない(^^;;

これからMZ-2500を覚えていったら使うのかな…という印象。

 

f:id:PocketGriffon:20211001112100j:plain

かなり幅広く解説されている電波新聞社版の活用研究本。この頃って工学社電波新聞社の両方から「活用研究」という本が出ていて、どっちがどっちなのか一瞬分からなくなる(^^;

実際に手に取ると、紙質で気がついたりするんですが…汗

この本のI/Oポート、ワークエリアは参考になった。この本が無かったらテキスト表示でスクロールに追従するのは難しかったかも?

今回のダンププログラムでは比較的開いた回数が多かった。

 

f:id:PocketGriffon:20211001112840j:plain

今回はこの本を一番参考にしたかも?!

メモリマッピングの説明がほどよくまとまっていて、見やすかった。

グラフィックのモードについても個々の説明が多いので、この先も活用しそうな予感!

 

で…作ってみたダンププログラムなのですが、直接テキストVRAMをアクセスしているのにも関わらず、画面を書いてるところが見えちゃう!想像していたよりも3倍くらいか、それ以上に遅いイメージ。なんで???

 

テキストVRAMの構造が複雑で、そのままアスキーコードを入れたらいいのかと思っていたら、実は3バイトの書き込みが必要だった。ここの変換が遅いのかなぁ…とか、メモリから1バイト取ってくるごとにメモリマッピングを変更してるところかなぁ…とか、いろいろと思いつくとこがあって修正をしたけれども改善されず。

 

最終的に考えが行き着いたのは「もしかしてVRAMのアクセスが遅い?」だった。

単に遅いのではなく、表示期間中にアクセスしたらブランク期間まで待たされるくらいでないと遅さに説明が付かなかったので、もしや…と思って調べてみたら、いろんなところで書いてあったw

f:id:PocketGriffon:20211001114802j:plain

てっきりMZ-2500クラスならばサイクルスチールなどの技術が入ってるんだと思いこんでいたけれど、そうでは無かったのか…。MZシリーズの伝統なのかな(^^;;

 

ゲーム機みたいなプログラムの作り方をした方が、頭の中がしっくり来て良いかもね!基本的にブランク期間中以外はVRAMは触らない方がよさそうだ。なんだろう…MZ-2500に感じるちょっとしたじゃじゃ馬感は…(^^;;

 

テキストの書き換えに、アドレスの離れたところに3バイト書き込む必要がある事、そもそもの構造でブランク期間に書き込むようにはしていなかった事、この先はあんまりテキスト表示をしまくる予定もない事…などの事情により、今回は改造しない事にした!

 

という感じで少しずつ触っていってる!

最終的に「よーし、MZ-2500は大雑把に理解したぞ」くらいまで行けたらいいんだけどな(^^) 機能が豊富なゆえ、そこまでたどり着けるのか…汗

 

ではまた次回!(^-^)ノ