PC-8300でプログラムを楽しみたい！
NEC PC-8300を手に入れて以来、バッテリーなどハード的な部分を充実させてきた。
そういえばあれ以降も充電し続けているので、最新のバッテリー電圧を測ってみた。
うん、良い感じの上限で止まっているみたいだ。
充電機構は正しく動作してると解釈しても問題なさそう！(^-^)
こうやって満足出来るマシンになってくると、次はプログラムしてみたくなる！
このブログでも紹介しているが、過去にPC-8201でガリゴリとプログラムしている。あの頃はプログラム全体をアセンブラで書いていた。これは8080に対応したコンパイラが手元になかったのが大きな理由。
EPSON HC-40でコンパイラを活用した際にはSDCCというコンパイラを活用した。このコンパイラはZ80とさらに上位のCPUが対象となっている。8085(8080)は対象外だったため、PC-8201では利用出来なかった。SDCCで対応しているgbz80(ゲームボーイのCPU)を改造して使えないかとも思ったが、そんな簡単な話でもなかった(T-T)
他にもMSX-Cも8080コードを吐けそうな雰囲気だったが、リンクされるライブラリがZ80で書かれている事に気づいた。実験している最中に自宅のMSXのFDDが壊れるなど不運にも見舞われた(そういえば修理してない…)。
私はアセンブラで書くのも楽しいと感じられるタイプの人種だが、それでも大量にアセンブラを書くとなると寿命が縮まってしまう。可能ならば速度やメモリ量を気にしなくても良いところは生産性を上げたい。
というわけで、8080のコンパイラが使えないかと思っていたのだ。
実はもう20年ほど前になるが、LSI JAPANのLSIC-80を個人で購入した。当時も今も98000円と震え上がっちゃう金額だったが、それに見合う性能だと考えて手に入れた。これでレトロなプログラムを組むぜ…と意気込み、実際に何年か使っていた。その後、度重なる引っ越しでパッケージが行方不明になってしまったが、このLSIC-80こそ、8080コードを吐けるコンパイラだ。
数ヶ月前、ようやく押し入れの奥底にあったハードディスクからLSIC-80のファイルのみを見つける事ができた。これを今回のPC-8300の開発で使ってみよう！という事だ(長い
LSIC-80の実行環境
LSIC-80はexe形式の実行ファイルであり、MS-DOSで動いたんだったかなぁ…どうだったかなぁ…と忘却の彼方にあった。確か当時はWindowsマシンで開発はしていたものの、コマンドラインらぶな私なので開発はbash+makeで行っていた(今もそうだけど)。
DOSBoxで試してみたところ……
ですよねー(T-T)
DOSそのものではだめで、Windowsのコマンドプロンプト相当で実行しないとダメらしい。
ということはWindowsマシンが必須だ。
残念ながら私はMac使いであり、常日頃からWindowsマシンは使っていない。所有はしているので使えばいいのだが、Macで困る事が滅多にないのだ。
今回、事情があってPallales Desktopは使えない。
試しに…と思い、Windows10を少し使ってみたが、操作方法に慣れずストレスばかりが溜まってしまう(T_T) Windows95やXP時代の記憶がまるで役に立たない(^^;;
仕方ないので、MacのフォルダをWindowsと共有し、編集はMac、ビルドはWindows、PC-8300に送り込むのもMacとした。途中のWindowsマシンはMacからMicrosoft Remove Desktopで繋ぎ、「make」とだけ打ち込めば良いようにした。これでWindows特有の使い方は覚えなくても済みそうだ！
PC-8300でプログラミング！
基本的な使い勝手はPC-8201と全く同じなので困る事は何も無い。
見ている資料もPC-8201用だ。
書籍はこの本をとても参考にしている。ROM内ルーチンやワークエリア、I/Oマップなどが詳しく書かれている。サンプルなども多めなので、PC-8201ユーザーはぜひ手に入れておくと良いだろう。ただ誤植も多い上に説明足らずな部分も多々ある。
この書籍を補完するカタチで、こちらのサイトにもお世話になっている。
英語のサイトだけど技術資料を読むのに英語も日本語も変わらんと思うｗ
特にPC-8300の技術資料もあるのは助かる(^-^)
一番参考になるのはROMデータを逆アセンブルする事だと思うが、まだダンプを作るのに必死になっていて手つかず。今回のダンプで十分なテストが出来たので、このあと吸い出しにチャレンジしてみたい。
今回はC言語が使える…とは言っても、アセンブラをゼロに出来るわけではない。ユーザープログラムのブート部分(スタックの初期化など)はアセンブラだし、LCDCをアクセスする部分などもフルアセンブラだ。大雑把に、全体の８割がC言語、２割がアセンブラという割合だ。
開発したプログラムは、PC-8201シリーズの大半のメモリを覗くことの出来るメモリダンプ。RAMおよびROMをリアルタイムにバンク切り替えする事が出来る。
開発中のPC-8300の様子。
RAMカートリッジを取り付けて、背中にはRS-232Cをしょってる。
フォントは4x7ドットで描画しているので標準よりも情報量が多い。240x64ドットの仮想VRAMを持ち、そこにビットマップフォントを書き込み、マシン語でLCDCへ一気に書き込む。この辺りの実験は、過去にPC-8201でやっているので参考にしてほしい(^^)
右上に現在のバンク番号が出ている。０と１が本体標準メモリの64KB、２がRAMカートリッジのメモリが見えるようになっている。
あれ？今気が付いたけど、これは１〜３の表示にした方がいいね(Menu画面の#1〜#3とあわせるため)。あとで直しておこう。
同様にこちらはROMの切り替え。バンクA〜Dの４バンク切り替え。これは内蔵のROM(128KB)だ。本体裏側に取り付けるROMは現在は見られない(処理を入れてない)。
※写真のサイズがまちまちで申し訳ない(T-T)
メモリダンプと同時にASCII表示も入れようと思ったが、4x7ドットでアルファベットを用意するのはめげてしまった！特に小文字！(^^;; 別のフォントで表示する方式にしようとも思ったが、そこまでしなくても良いか…と割り切りという名のあきらめをした！
PC-8300でプログラミングしてみて…
PC-8201のプログラムがそのまま動く！
まず驚いたのが、PC-8201とはROMのバージョンが違っているはずなのに、PC-8201の資料に書かれているアドレスがそのまま使える。つまり移動していないのだ。どうやらマシン語レベルで書かれたプログラムでも互換性があるようだ。
RAMカートリッジ(BANK #3)で速度低下？！
RAMカートリッジ(BANK #3)上では動作するプログラムの速度が若干違うっぽい。これはRS-232Cでプログラムを転送する際、BANK #3のみウェイトを多くしないといけない現象が出て気が付いた。外部にメモリが付いているので、もしかしたらウェイトが入るんだろうか？？実際に使ってて気が付くレベルの速度差ではない。
やっぱり転送速度が気になる…
転送速度を9600bpsにしていても9600bpsフルには出ていなさそう。HC-88よりは若干速い気がするが、それでもウェイトを入れなくてはならないのでフルスピード出ていない。そしてBASICのDATA文からマシン語としてPOKEする時間も気になる…。
HC-88の時のように、バイナリ転送プログラムを作らないといけないかなぁ…これは！
よし！とりあえず開発環境を整えるってのと、全メモリをアクセス(表示)するプログラムを作る事は出来た！せっかくなのでもう少しだけ使いやすくしていきたいと思う。
何かゲームの移植でもしたいところだけど、絵心のない私にはそこの敷居が高すぎて超えられないｗ PC-8001やMZ-80Bなどの移植したいんだけどなぁ…(T-T)
それではまた次回！(^-^)ノ
