HC-88でプログラミング! その7

6301アセンブラ

Twitter等で6800アセンブラの情報をありがとうございました。

全く探していなかったので、いろいろと試すチャンスが出来ました!

で…いろいろとやってみたのですが、どうもしっくりこず…

結局、自作してしまった(^-^;

教えてくださった皆さま、すみませんでした…orz

 

何年か前にも必要にかられて6809のアセンブラを書いた事があったが、その時は富士通のアブソリュートアセンブラソースコードがそのまま通るようにしようと頑張ってしまったため、大変な労力が必要になってしまった汗

 

今回は適当にも適当に作った自分アセンブラ(^-^;;

アセンブラを自作するのってアマチュア時代から数えて何回目だ?もはや覚えてないw

6301CPU側の空きメモリを考えても、多分数百行のソースがアセンブル出来れば良いレベルなので、豪華仕様は全てカットした!

f:id:PocketGriffon:20201024003832j:plain

↑こんな感じに書いたコードが…

↓こんな感じにアセンブル出来て、これまた自作逆アセンブラでちゃんと出た!

f:id:PocketGriffon:20201024004123j:plain

実はまだ変な書き方をしたりするとSegmentation faultで落ちてしまったりするんだけど、これはもう使いながら直していくしかないw

 

よしコレでじっくりとスレーブCPU側のプログラムを作ろうって気になってきた!

今回は「アセンブラ作った」の報告だけ!(^-^;;

 

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

 

メモ

・6301はリセット後、初期設定が終わるとスリープモードに入る。その後、IRQ割り込みにより起こされてZ80とのやりとりを始める。

・他にもタイマー割り込みなどもあるみたい。

・ダイレクトページの$A8に重要なステータスが入ってるようだけど未解析。

・割り込みや重要な処理ではRAMへのフックが存在しているので、ここを書き替える事で拡張が容易に出来る。特に6301へのコマンド番号$80以降は拡張しやすそう。

 

 

 

 

EPSON PX-8

このところ、HC-88の調べ物をする時に海外のサイトを利用させてもらってる。

海外にHC-88のマニアがいるのか…というワケではなく、実はHC-88は海外ではPX-8という名称で販売されていたのだ。そのため、PX-8の資料が大量にある…というワケだ。

 

残念ながら私はHC-80系のマニュアルを所持していない。主に国会図書館で複写サービスを受けた資料を見ている。でも資料としては断片的なので、主に海外のサイトを参考にしている。そのため、日本特有の設定には気がついていない。先日もSCREENコマンドの引数に4(日本語モード)が指定出来るのを初めて知ったくらいだ。

 

他にもスレーブCPUのメモリをアクセスする際に"とある"アドレスのフラグを操作しないといけないのだが、実はこのアドレスもHC-80とPX-8では違っている。

この情報もPX-8の資料にはあるのだが日本語版の資料には存在しない(この設定を知らないと6301CPUの制御は出来ない)。

 

こうなってくると海外のPX-8も使ってみたくなる!どんな感じに違っているのかをこの身に感じてみたい!

…という事で、PX-8を手に入れた!!

せっかくなのでHC-88と並べて見た。

f:id:PocketGriffon:20201022010335j:plain

……これは…ww

見た目の区別が付かないww

ちなみに←左がPX-8、右→がHC-88だ。

双子を見間違える親の気持ちが分かる!(多分違う

立てて見るとこんな感じ↓

f:id:PocketGriffon:20201022010520j:plain

上がHC-88、下がPX-8。

HC-88には日本語を表示するための拡張ユニットがついているが、PX-8には何もついていない。どうやら海外では128KBの増設メモリユニットがついたりするらしい。残念ながらソレは入手出来ていない。

 

f:id:PocketGriffon:20201022010702j:plainf:id:PocketGriffon:20201022010720j:plain

キーボードはさすがに違っていた!

←左がPX-8、右→がHC-88だ。

でもPX-8は海外なのにキーボードが日本語っぽい(*が8の位置にないなど)。

これは海外では使いにくかったのかもなぁ。

 

手に入れたPX-8だけど、立ち上がったり立ち上がらなかったりと調子が悪い。

分解してみるとなるほど…な状態。

f:id:PocketGriffon:20201022010957j:plainf:id:PocketGriffon:20201022011018j:plain

コンデンサの周りが緑色になってたり、足が粉吹いた状態になってる。

遅かれ早かれ、これは起動しなくなるだろうな…。

というわけでコンデンサを交換した。

f:id:PocketGriffon:20201022011135j:plain

手持ちのコンデンサが足りず、交換を急ぐモノを優先的に交換した。

残りは後日コンデンサを入手してから交換となった。

 

分解したついでに、HC-88とPX-8の液晶ユニットを交換した。

HC-88の液晶ユニットはビネガーシンドロームが始まっていて、写真に撮ると非常に見づらい。ブログに載せる写真も、何度も何度も角度を変えて撮り直しているのだ。PX-8の液晶ユニットは綺麗な状態だったので、こりゃいいや…と(^^;;;

そのため、液晶にHC-88と表記されているのに中身はPX-8だったりと非常に分かりづらいw

この先はいちいち機種を書いていこうと思うw

 

そんなワケで現在のPX-8の姿はこんな感じ。

f:id:PocketGriffon:20201022011832j:plain

こんな感じで液晶ユニットはHC-88だ。でも中身はPX-8だww

 

せっかく分解したので、各パーツをぴっかぴかにした。キーボードもキーを1つずつ引っこ抜いて綺麗に拭いた。幸いな事にえぐれるような傷がなかったことも幸いした。

 

f:id:PocketGriffon:20201022012323j:plainf:id:PocketGriffon:20201022012341j:plain

光の加減もあるが、左と右が同じパーツだと誰が信じてくれるだろうか(^-^)

 

よし!この先はPX-8でも動作確認しながら作っていくよ!

作業のベースはHC-88だけどね(^^)

 

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

 

HC-88でプログラミング! その6

HC-88はワリと手軽にROMを交換する事が出来る。

背面にあるフタを開けるとROMが顔を覗かせる。

ROMの両脇につまみがあり、それを引っ張る事で簡単にROMが外れる。

ソケットは2つあり、それぞれB、Cドライブとして見えている。

BASICは常駐かなーと思っているけれども、UTY-Jは使ったり使わなかったりするので、たまに変更して立ち上げてみたり。これだけでも楽しいw

HC-40にも同じように2つのソケットがあるが、HC-45にはなぜか3つある。

f:id:PocketGriffon:20201021010330j:plainf:id:PocketGriffon:20201021010351j:plain

 

6301マシン語入門

昔の書籍を見ていると、どうやら6301マシン語入門という本があったらしい。例によってまーったく手に入らない。いつか巡り合わせがきたら手に入れたいな…なんてことを思いつつ、無いならば国会図書館行かなくちゃ…くらいに思っていた。

f:id:PocketGriffon:20201021011236j:plain

で、そうなんですよ…。

いつもの事なんですが…

f:id:PocketGriffon:20201021011336j:plain

↑すでに複写サービスを利用していた事をすっかり忘れてた!!!

なんだ、手元に資料たくさんあるじゃん(T-T)

でもどの書籍も特徴的で、あっちに書いてある事とこっちに書いてある事をあわせて読まないと全体像が分からなかったりする。やっぱり何種類は欲しいところ。

 

6301アセンブラ

結局、自作を始めてしまったw

cppを有効活用、マクロ機能は無し、後方参照はサポート、分割アセンブルしない…など、手を抜けるところを抜きまくれば、1日あれば作れるか…と思いつつ作っていたが、ちょっと思うところがあり一旦中断した。

 

HC-88のメインCPUはZ80だ。なぜスレーブCPUの6301にこだわっているのか、気になっている方もいるだろう。

 

実はHC-88はスレーブCPU側にプログラムを送り込んで、実行する事が出来るのだ。

FM-7やFP-1100みたいだ」というフレーズを何度となく使っているが、実はプログラム実行が出来るというところまで同じなのだ!

f:id:PocketGriffon:20201021012658j:plain

出来るとなったらやりたくなるのがオトコノコだ!ごりごりに組まなくても良いから、単純なプログラムでも良いから作ってみたい!

そんな事情があって、6301のアセンブラを探していたのだ。

 

ともかくやってみよう!

ちゃんとした開発環境はあとから作るとして、まずはとりあえず版でも良いのでスレーブCPUでプログラムを実行してみたい!

そして速度的にどのくらいになるのかを知っておきたいのが心情だ!

試しに同じ事をするプログラムを3パターン作ってみた。

 

画面全体(480x64ドット)を反転させるプログラムを作ってみた。

・単純にBASICで作ったモノ

Z80マシン語で動くがVRAMアクセスはスレーブCPUを介するモノ

・スレーブCPUにプログラムを送り込んで直接実行するモノ

これらの速度を比べてみよう!

 

BASICで作ってみた

まずは一番単純な構造のBASICプログラム。

必要な命令としては、画面のドットを読み取るコマンド(POINT)、ドットを書き込むコマンド(PRESET)が分かればなんとかなる。

そして横480ドット×縦64ドットで30,720回ループを作れば良い。

ドットの反転は「PRESET(X,Y),POINT(X,Y) XOR 7」とすれば条件判定が入らない。

これで実行してみたところ、画面全体が反転するまでに813秒掛かった!

BASIC = 813秒

f:id:PocketGriffon:20201021015559j:plain

 

Z80マシン語で書いてみた

BASICで書いた場合とはFOR〜NEXTの部分が単純に高速化される。あくまでも速くなるのはメインCPU(Z80)側だけであり、スレーブCPUは基本的にBASICの速度と同じだ。

 

ちょっとだけ変わったのは、データのアクセス方法だ。

BASICではドットを読んで→XORして→書き込みとしていたが、マシン語でVRAMをアクセスをする場合には「VRAMのメモリを読んで、論理演算して書き戻す」という機能(CMD=01h)が存在する。これを使えば8ドット単位に、しかもメインCPUから見たVRAMアクセスは、書き込み動作だけで処理が終わる。単純に1/16くらいの時間になりそうな雰囲気。

 

ちなみにスレーブCPUのメモリ書き込みの機能としては「ANDして書く」「ORして書く」「XORして書く」「そのまま書く」の4種類が存在する。

なんとなく「そのまま書く」が一番速そうな雰囲気があるが、実は処理の順番的にANDが一番速くOR→XOR→直接の順番で遅くなる。せめてコンペア3回ではなくテーブルジャンプにしてくれたら速度は同じだった気がするのだが…。

 

そして気になる画面反転の速度は……21秒でした!BASICからマシン語に変換されただけでも相当速くなるね!でも1画面反転に21秒はやっぱりまだ時間が掛かってるね…。

Z80マシン語=21秒

f:id:PocketGriffon:20201021015824j:plain

 

6301CPU上でプログラムを動かしてみる!

スレーブCPUは6301なので、マシン語も当然6301(6800)で書いてやらないといけない。アセンブラを用意していたが、それよりも先に実行したい欲求が強いので、ハンドアセンブルする事にしたw そんな大きなプログラムは書かないので大丈夫!

それで用意したのがこんなプログラム↓

f:id:PocketGriffon:20201021020101j:plain

特徴的な命令としては「eim」がある。これは「メモリの内容とオペランドをXORしてメモリに書き戻す」という動作をしてくれる。面白い事にアキュムレータを汚さない。上のプログラムではインデックスアドレッシングを用いているが、ダイレクトアドレッシングでアクセスする事でメモリ効率も速度も速くなるため、ダイレクトページにワークエリアを置くプログラムはとても作りやすい。アセンブラの醍醐味は、こういう高級言語では書く事の出来ない命令を使う事…ではないだろうか(^-^)

 

プログラムを見て分かる通り、おそらくマシン語プログラムとしては最低速度だと思う。適度なループ展開などをしてやればすぐに2倍3倍の速度にはなるだろう。そういう楽しみはこの先の楽しみとして、まずは動かす事を優先しよう!(^-^)

 

さてこのプログラムをCMD=01hでメモリに書き込み、CMD=02hで実行してやる。

問題は、スレーブCPUのメモリ空間の「どこ」にプログラムを置けば実行出来るのかが分からない事だ…。これはもう地道に実験するしかない。

で、試してみた結果、グラフィックモード(SCREEN 3)の時は、$8000〜$837Fまでの896バイト、$9541〜$9764の558バイトにプログラムを置ける事が分かった。全体で1454バイトのフリーメモリだw

 

さて、これで実行してみた結果!なんと1秒以下の速度となった!動画をTwitterへ上げておこうと思うので、ぜひ見てみて欲しい(画面が反転するだけの動画w)

6301マシン語=1秒以下

 

HC-88、面白い!!!

レトロパソコンでサブ側のCPUを制御するのは、FM-7PC-8801(ディスク側)についで、これが3台目だ(仕事ではもっと大量にやっているが…)。 6800というCPUも相まって、とても面白いマシン!!

こうなってくると絵とか動かしたくなる! HC-40の時にやってたみたいにタロットデータを動かしてみるか…それとも何か簡単なデモでも作ってみるか…夢が広がるw

 

何をするにも、やっぱり6301アセンブラ欲しいですね。

ちゃちゃっと作ろうと思います!

ぎゃー!楽しいww

 

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

HC-88でプログラミング! その5

f:id:PocketGriffon:20201016214758j:plain

ぎっちぎちなROM空間!

6301CPU側のROM解析を始めて1日経ちました。

だいたい覚えた&理解した(^-^)

むしろ逆アセンブラ(自作ツール)を充実させてた時間の方が長いと思うw

エントリアドレスやらワークエリアの情報を設定ファイルに記載して渡してやると、自動的に逆アセンブルリストに追加してくれるようにした。このおかげで、解析しながら設定ファイルを充実させていく事でどんどんリストが見やすくなる。

↓これはツールが出力された状態のファイル。

f:id:PocketGriffon:20201016213809j:plain

 

長年アセンブラばっかり触っているので、大体どのCPUのニーモニックであっても読み書きするのに困らない…と自負してるが、6301の「AIM / OIM / EIM / TIM」には慣れない…。それぞれ「And Immediate Memory」「Or / Eor / Tst」らしいのですが、アキュムレータを介さずに演算出来るところが素晴らしい。

アタマの中で「あいむ、おいむ、えいむ、ていむ」って呼んでますw

 

解析してみて分かってきたんだけどが、よくぞこれだけの機能を4KBのROMに納めたなぁ…って思う。今わかっている範囲だけど、なんと5バイトしか空いてない!(^-^;

もちろん、プログラムには省メモリ化のテクニックもちりばめられている。

 

例えばこんなコードがある。

$F000から実行されればAレジスタには$03が入り、その下の2行(CPX)は実行されるけど結果は気にせずJSRでサブルーチンコールされる。

F000 8603 LDAA #$03
F002 8C8602 CPX #$8602
F005 8C8601 CPX #$8601
F008 BDFF00 JSR $FF00

↓このコードの面白いところは、$F003から飛び込めばプログラムが変化するところだ。

F003 8602 LDAA #$02
F005 8C8601 CPX #$8601
F008 BDFF00 JSR $FF00

↑の場合はAレジスタに$02が入るのだ。

本来ならば↓のようなコードになるんだと思う。

F000 8603 LDAA #$03
F002 2006 BRA $F00A
F004 8602 LDAA #$02
F006 2002 BRA $F00A
F008 8601 LDAA #$01
F00A BDFF00 JSR $FF00

たかだか数バイト減らすためにこんな事を…とか言う無かれ! 1バイトを減らすために、ものすごく苦労した時代なのだ! 速度を取るかメモリを取るか、そんな事を大の大人が考え抜いてコードを書く時代だったのだ!(ちょっと大袈裟)

そしてこのようなテクニックがROMの至るところに入っている。
同じようなコードを昔FM-7(6809)で見たことがあったため、すんなり頭に入ってきた。

 

やりことをやるための調査が必要という大義名分…!

「HC-88でやってみたい事がある」という事を、以前ちょろっとだけ書いた。

実際に出来たらご紹介してみたいが、今のところは机上の空論に過ぎない。

作るためにはまだまだ調べないといけないことが残っているのだ。

 

アセンブラのソースを見てるだけではラチがあかず、エミュレータ書くか…って何度も思ったw でもエミュレータを書くには、今度はハードの情報が足りなさすぎる。途中でハマる事が見えているので、極力手をださないで行こうとココロの中で決めているw

 

今、これはどうしよう…と思っているのが6301用のアセンブラ。手元に適したアセンブラが無いのだ。そもそも6800のアセンブラを調べたこともない。

そんな大きなプログラムは組まないだろう…って自分でも思ってるんだけど、でもソースコードが変わるたびに相対ジャンプのアドレスを数えたくない!

過去にアセンブラは何度も書いているので、今回も書くべきか…

これはマジで悩み中(^^;

 

そんな事をもんもんと考えながら、今日も逆アセンブラリストとにらめっこするよ!

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

 

HC-88でプログラミング! その4

f:id:PocketGriffon:20201015214539j:plain

HC-88というマシンに惹かれるところ

先日からV20エミュレータの開発作業を中断して、HC-88にドハマりしている。

HC-88というマシンの、いったいどこにそんな魅力を感じているのか…をちょっと書いてみようと思う。

 

まずひとつにZ80+CP/M80という、とても使いやすいマシン構成が気に入っている。これはHC-40にも言える事なんだけど、根底にCP/MというOSが載っている事の安心感は凄まじい。使い方で困った時にはCP/Mまで立ち戻れば、解決出来ない事はほとんどない。その上でどう使うか…を楽しめるのだ!

 

もうひとつ、HC-40と大きく違う点は画像周りを別CPUが管理している点がある。これはFM-7やFP-1100を想像してもらえれば大体あってる。サブCPUが使えるメモリはFM-7ほど大きくないがFP-1100ほど小さくもない、速度はFM-7 > FP-1100 > HC-88と最も遅いと思われる。

こんなワケの分からない構造……楽しくて仕方が無いじゃないか!(^-^) 資料も少なく解析のしがいがあるっていうのも大きな魅力だろう。

 

とどのつまり、謎パーが大好きな私にマッチしてるってのが一番なのかもしれない。

複雑すぎず簡単すぎず、適度に遊べるマシンというのは本当に楽しい。

HC-88ではやりたいことがはっきりしているので、それをやるまでは頑張ってみるつもり。

 

6301CPUの制御プログラム

HC-88のスレーブCPU(PX-8ではSlaveCPUと呼ばれてるっぽいが日本の書籍ではサブCPUが一般的…どっちにあわせたらいいのさ…orz)を制御しているプログラムがある。

6301CPUのメモリマップ$F000から4KBに収まっている。6301が担当している処理を考えると驚異的に小さい気がするんだけど、ホントに???

それも含めて確かめるために、6301CPUで動いてるプログラムを解析したい。

 

それでメモリをダンプするプログラムを作っていた。当初からの目的は6301CPUのプログラムを覗く事だったのだ!BIOSコマンドのSLAVE機能を使えば、6301CPUのメモリを覗くことが出来る。これを利用すれば簡単だ。

 

で…問題は、その覗けたプログラムを、どうやってホスト側に持ってくるのか…という事だった。RS-232Cでの通信は、Mac→HC-88は問題ないのだが、なぜか逆(HC-88→Mac)が失敗してしまうのだ。これが成功していればとても簡単に転送出来たのだが…無いものは仕方が無い!

というわけで…画面に表示したバイナリデータを手で入力した!!!(^-^;;

プログラムは$F000〜$FFFFの4KBと分かっていたので、そんな大きな労力じゃない。たったの4096バイトだ!でも入力し間違いは避けられないので、ダンププログラムにチェックサム機能を付けたw

f:id:PocketGriffon:20201015221404j:plain

ホスト側ではテキストデータとして入力していき、それをバイナリに変換する時にチェックサムを確認するプログラムを作った。これでかなりの確率で間違いがなくせたはずだ!

 

昔むかしその昔、I/Oなどに載っていたバイナリダンプを入力する時に、マシン語入力ツールなるモノを利用していた。一番古くは、中村光一氏がI/Oに投稿していたマシン語モニタを利用した。仕組みが理解出来てからは、自分が使うマシン用に自作しまくった。

その時にテンキーを16進数のA〜Fに見立てて入力をする事をしていた。当時はタッチタイプなんぞ出来なかったので、一本指打法の王道として有効な方法だと思う。

それがここ数年、何度となくダンプリストを打ち込んでいるのだが、両手でタッチタイプしながら打ち込む方が圧倒的に早いのだ。昔は256バイト打ち込むのに10分くらい掛かっていた記憶があるのだが、今だと256バイトに3分掛からない。間違いを修正して5分前後だ。そんな感じだったので4KBというのはワリと現実的なサイズだった。

 

6301CPUのアセンブラ表記

私は6301というCPUを使った経験が無い。6301が6800とマシン語レベルで互換性がある…という事を知ったのも、ここ数年の間だ。そんな状態だったので手元に資料が全く無いわ…と思っていた。

 

そしたら……HC-20のCPUが6301だった!6301と聞いてピンと来ていない辺り、HC-20を使いこなせていないのがバレバレだ(TOT)

f:id:PocketGriffon:20201015223111j:plain

↑いつかちゃんと使おうと思って、マシン自体は持っているのだ。でもHC-40/88が楽しいので、HC-20を使うか…と聞かれたら、ちょっとだけ疑問(^-^;;

 

HC-20だったら本持ってる!

f:id:PocketGriffon:20201015223215j:plain

なんと!しっかりと「6301プログラミング」と書いてあるじゃないか!

これを参考にしながら、6301の逆アセンブラを作ってみた。

f:id:PocketGriffon:20201015223951j:plain

2パス逆アセンブラになっているけれども、2パス目をまだ手抜きで作っているので、せっかくプログラムコードとデータを分離しているのに、ちゃんと表示されない(^^; これからもう少し解析を進めていきつつ、機能を充実させていくつもり。

 

よーし、これでしばらくは解析時間に入るよ!

この先、6301用のプログラムを組むって考えたらアセンブラをなんとかしないといけないかもなぁ…小さいうちはハンドアセンブルでいいか。この時代にハンドアセンブルする?(^^;

こっちもさくっとアセンブラ作ろうかな…。

 

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

HC-88でプログラミング! その3

スクリーンモード4

HC-88のマニュアルが手元にない状態なのですが、資料を見ていたらどうやら拡大文字モードというモノがある事に気が付いた!

今まで、主にPX-8(海外向けのHC-80)の資料を見ていたので存在そのものに気が付いてなかった。海外の資料を見る限りSCREEN0〜3までは理解していたけれども、SCREEN4ってのが存在してた!しかも日本語モードになるとはw

 

f:id:PocketGriffon:20201014181640j:plain

この画面モードになればタッチ16での日本語入力が可能。しかもPRINT "日本語"なんて感じに全角文字を入れる事も出来る。てっきり「BASICはPX-8と全く同じ」くらいに思い込んでいたけれども、かなり拡張されているのかもしれない。

きっとこの辺りのプログラムは拡張ユニット側のROMに載っているのかも知れないけれど、解析をまーったくしていないので憶測の域を出ない。

 

f:id:PocketGriffon:20201014210240j:plain

この(SCREEN 4)モードでBASICのLISTをするとインパクトでかい!PC-1600Kでも同じ感じに見えるモードがありましたね、確か(^-^;

ROGANには優しいけれども、CTRL-Sで止めると1行しか見えないのは残念(T-T)

 

ダンププログラム仮完成!

先日から開発していたメモリのダンププログラムが、仮に完成しました。

仮に完成ってなんだ?

とりあえず動きますってバージョンw

 

f:id:PocketGriffon:20201014221650j:plain

ただ単にメモリが見えるだけのプログラムですが、64KBのメモリ空間がなんとなく分かるってのは嬉しいですね!

 

f:id:PocketGriffon:20201014221654j:plain

実は今回はこんな機能を入れてまして!

上の写真と下の写真、実は上がメインCPU(Z80)のメモリ空間、下はスレーブCPU(6301)のメモリ空間が見えているのです!

巧妙にも画面右下に「M」と「S」の違いがww

 

今回のダンププログラムはオールC言語で書いた。一部、システムコールを呼ぶ部分についてのみインラインアセンブラを使ってる。やっぱりC言語使えると違うなー。

 

HC-88でのプログラミング10/14版

今回のダンププログラム、前回のシリアル通信プログラムを通じて分かった事。

HC-88はスレーブCPUを介して表示や通信を行うのだけど、そのスレーブCPUとのやりとりがボトルネックとなり、全体的な速度が上がらない。

特にダンプの表示については、1文字ずつスレーブCPUに指令を渡していたら「なんか遅いね」程度では済まないほどの速度低下が起きる。仕方ないので、出来る限りメインCPU側でデータをまとめるなりして、出来る限り大きな単位でスレーブCPU側に渡すようにした。

そのため、キー入力に対するレスポンスが非常に悪く、「仮」と言いたくなるほどの完成度となりました…orz

 

今回の「メモリの内容を見てみたい」という目的は達成できたので、一旦ダンプ表示はキリとします。

この先はスレーブCPU側に入っているプログラムの解析をしていきたいと考えているのですが…困ったことにHC-88→ホストマシンへの通信がうまく行かず、データを引っ張ってくる事が出来ない。

これは…データを目コピーするしかない?4KBのダンプリストを??(T-T)

…ちょっと方法を考えてみますw

 

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

HC-88でプログラミング! その2

開発効率をもっと上げたい!

先日からメモリダンププログラムを作っていましたが、もーガマンの限界でした…。

何がって…編集→転送→実行に掛かる時間が長すぎて!

 

マシン語データを直接送り込むことの出来ないHC-88。

仕方が無いので、BASICのDATA文にマシン語データを内包しておき、HC-88へ転送後にメモリへPOKEするようにしていた。バイナリをテキストに変換しているだけでもサイズ的に倍、POKEするプログラムを含めたりすると1.5倍くらいのサイズになっていた。それに加えてBASICの遅さよ(T_T) なんで1.5KBをPOKEするだけで1分以上も掛かるの…。

ターンアラウンドタイムを短くするのは、作業においての基本中の基本だと思う!

 

というわけで、バイナリデータを直接転送する事の出来るプログラムを書く事にした!

ただでさえメモリが多くないところに、常駐させたい系のプログラムを置くわけだから、出来る限りサイズは小さい方が好ましい。それに加えて速度を上げた方が良いだろうから…という事で、オールアセンブラで書くこととした。

 

アセンブラは使い慣れたzasmを使う。そんな大きなプログラムを書くつもりでもないので、正直に言えばどれでもOK。アセンブル時間だって今の時代では気にならない(^^;

 

必要な材料&情報

アセンブラRS-232Cを扱うプログラム…と言っても、そんな構える必要は無い。なぜならば、便利なBIOSコールが用意されているから。何も通信ドライバを1から書くワケではないw

 

f:id:PocketGriffon:20201013163022j:plain

↑これはHC-40のオペレーションマニュアルに記載されている情報なんだけど、この当時のマニュアルにはこんな細かいことまで書かれている!

HC-40にはこのBIOSコールがあるけれども…HC-88にはどうなんだろう…。BIOSコール自体は良く似たものが用意されているのではないかと予想。エントリアドレスを調べてみてると、E839hとそれっぽいアドレスへ飛んでいる!なんらかのエントリは存在しているらしい。

 

BIOSコールのRSIOXが存在するものとしてHC-88上でプログラムを組んでみる。OPENしてみると戻り値がそれっぽい!よーし、きっと使える!

途中、CLOSEの処理がどうしても正常に動かず、やっぱり互換性が無かったのか…と思ったが、実に面倒な仕様になっていた(これはまた機会があればw)

 

バイナリデータを転送する際に、転送先アドレスと転送バイト数の情報が必要となる。これはHC-40でBLOADする際のフォーマットがあるので、それをそのまま採用した。HC-40用に作ったツールがそのまま利用出来る点は便利だ。

先頭1バイトが0xFD固定、次の2バイトが転送先アドレス、その次の2バイトが転送バイト数という、とても単純なフォーマットだ。

先頭1バイトが0xFDというのがちょっと気になるが、Z80の場合0xFDはPrifix命令となり、IYレジスタを扱うコードを一番先頭に置くイジワルをしない限りは問題にならないw

 

転送プログラムの開発

構造自体は難しいものではない。

先頭の5バイトを読み取り、必要なバイト数分だけ受信してメモリへ書き込むだけだ。

通信プログラムで面倒なのはエラー処理だろう。今回のプログラムでは以下の種類のエラーを出力する。

RS-232CをOPEN出来なかった

・途中でCTRL-Cが押された

・通信バッファが溢れてしまった

マシン語バイナリでは無いものが送られてきた

 

加えてプログラムサイズにも気を使いたい。メモリに常駐させたいので、小さければ小さいほど良い。実行速度については1サイクルを気にするようなプログラムではないため、変なテクニックは使わないw

 

方針さえ決まってしまえばテストを含めて半日も掛からず出来上がった!

 

高速バイナリ通信ツール

f:id:PocketGriffon:20201013160827j:plain

↑起動した直後の画面。

自分で「HIGH Speed」とか書いちゃうイタさは生暖かく見守って欲しいw

 

通信が終了するとこんな感じの表示となる。

f:id:PocketGriffon:20201013204610j:plain

なるべく表示は出さないようにしようと思っていたが、ホントに通信しているのか不安になるので、256バイト受信すると「・」を表示するようにしてみた。

プログラム開発していると、コードサイズは常に把握しているので、何個表示されたら通信終了か分かる。これで気持ち的にも安心するってモンですw

f:id:PocketGriffon:20201013204934j:plain

ちなみにマシン語じゃないファイルを読み込もうとすると↑こんな感じのエラーが出る。

間違いが起こることもないのでちょっと安心(^-^)

 

どのくらい速くなったのか?!

開発をしていて気が付いたのだが、通信速度が設定値MAX(19200bps)になる前に、機械的な限界に達してしまう模様。9600bpsフルスピードすら出ない事が分かった。受信バッファの数を増やそうが効果無し(T-T) 限界値を探りつつ、その範囲で高速化を狙う事にする。

 

さて、実際のところ、どのくらい速くなっただろうか。

実験に使うマシン語プログラムは開発中のメモリダンプ、サイズは1553バイト。

これを転送する時間を計ってみよう。

 

マシン語プログラムをBASICに内包して転送する方法で…

・BASICをHC-88へ転送する時間 31秒

・RUNしてマシン語データをPOKEする時間 51秒

という感じで、合計82秒掛かっていた。

 

開発したツールで転送してみると…なんと3.8秒!

これは…満足出来る結果になったと思う!(^-^)/

 

開発中は19200bpsのノーウェイトで送れたらカッコいいなぁ…なんて思っていたのですが、その前にRS-232Cのデータを受け取るスレーブCPU側が悲鳴を上げるみたい。LCDの表示を消したりしたら速くなるのかも知れないけれども、まぁそこまで頑張らなくてもいいかな。

 

ちなみにプログラムサイズは478バイト。エラーなどでたくさん文字列を入れてあるけれども、この文字列を抜かした純粋なプログラムだけのサイズで言えば310バイト。通信バッファを含めて812バイトと、まぁコンパクトに作れたかな。アセンブラで作っていると余計なコードが入らないので、むしろ狙わなくても小さくなりますね(^-^)

 

よし!これで開発効率が上がったぞ!

メモリダンププログラムに戻りまーす!

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