PC-1600KでBad Apple!! 高速化編

先日、SHARP PC-1600KでBad Apple!!を表示させる実験をした。

主な目的は、搭載されているメモリを使い切る「何か」をしてみたかったのであり、それ以上の目的も目標もないままだった。

 

Twitterおよびこのブログに投稿後、改めてYoutubeなどにあるBad Apple!!の動画を見てみたが、音楽と映像がマッチしていてとても軽快に見られる!うーん、これは…サウンドはどうあれ動画速度はもう少し速めないと制作者に失礼だなぁ…と思った。

 

というわけで!今回は高速化がメインのお話(^-^)

 

速度計測をしてみる!

さっそく高速化を始めてみたい……が、その前に速度を正確に計測する仕組みが必要だ。

その仕組みが無いと、実際に入れたコードで速度が速くなったのか、逆に遅くなってしまったのかを知る方法が無い。人間の感覚ほどアテにならないモノはないw

 

どこかのI/OポートにTick値が出てないかな…。タイマー割り込みでも良いのだが…。

エミュレータがあれば楽に速度計測が出来けど、そのためだけに作るのは忍びない(否定はしないw)。

 

そしたら「PC-1600K データブック」に情報が載っていた。

f:id:PocketGriffon:20210226132629j:plain

こういう情報が掲載されている書籍があるのは、本当に助かる!

 

だがしかし……なんと1/64秒の割り込みしか用意されていなかった!処理速度を測るための数値としては、だいーぶ大雑把な数字だ。うーん…これで測るしかないかなぁ…。

サンプリング数を多くして、大きな値で見ていくしか無いな。

 

現状、64KBの拡張メモリ(CE-1600M * 2)に1086枚の画像が入っている。これを全て表示させた後に掛かった数字(時間)を目安にする。

初期の状態では「10784」という数字が出た!

この数字を64で割ると、表示に掛かる秒数が出てくる(168.5秒)。1086枚の画像を168.5秒で表示しているので、秒間6.445枚の絵が表示出来ている。これが現状だ。

最初が秒間1枚くらいの速度だったので、まぁ速くなってはいるんだけど(^^;

オリジナルが秒間30枚らしいので、それから比べたらだいーぶ遅い。

 

高速化開始!

さて、正確な(でも大雑把な)速度が測れるようになったので、これから楽しい高速化作業といきますか!

 

まずは「何を高速化するのか」を検討してみる。

処理の流れは、ものすごく乱暴に書いて以下の通り。

1、画像を展開するバッファをクリア

2、圧縮されたデータをバッファへ展開

3、展開されたデータをVRAMへ転送

この3つだ。

1のバッファクリアは、点を打つ/消す、のどちらかの処理を端折るために入れている。先にクリアされている事が保証されれば「点を消す」処理はいらなくなる。黒い部分が多い画像では逆に不利となるが、多くの場合は有利に働くため入れている。

 

2は多分、イチバン重たい処理。データによって縦方向と横方向があり、2つの展開ルーチンが存在する。縦方向に圧縮されたデータが多いため、縦方向のルーチンを最適化したい。

 

3はIOCSの処理をそのまま利用している。問題は横方向の156ドット全てを転送するサービスしか提供されてなく、なんとなく無駄が多そう…という事だ。

 

それぞれの速度を測ってみたが、1はほとんど負荷がなく誤差の範囲程度、3は全体の25%くらい掛かっている事が分かった。残りが2の時間だ。

 

実際の描画処理は、最終的にはアセンブラ化すればいいか…と思っているが、でもC言語で究極まで高速化してから、そのアルゴリズムアセンブラ化するのが良いかなと思ってる。LSIC-80が出力するアセンブラコードを参照しながらコードに手を加えていくが、むしろ「アセンブラコードでこう吐かせたいから、C言語でこう書く」という感じ(^^;;

 

久しぶりにLSIC-80でガリガリ組んでみたが、register宣言でコードをコントロール出来たり、auto変数よりもグローバル変数の方が良いコード吐いたりなど、自前コントロールがとてもし易いコンパイラだと思い出した。

 

その結果、「これをアセンブラ化してもたいして速くならん」というところまで攻め込む事が出来たので、これはもうコレで(^^;; C言語状態で満足いくモノが出来てしまったw

まぁデータの持ち方などアルゴリズムを変更したら良かったな…と思うところがいくつか出てきたが、今回はこれ以上はやらないという事にした(^-^; キリ無いからね!

 

LCDCを直接アクセスしたい!

3の「展開されたデータをVRAMへ転送」を高速化してみる事にした。

 

実はIOCS経由でしかLCDにアクセス出来ない事が気になってた!(^-^;; 「出来ない」というと言い方がアレだけど、「やり方を知らない」と言った方が良いかも。

 

「PC-1600K データブック」にもLCDへの直接アクセスは詳しく書かれて無いのだ!

f:id:PocketGriffon:20210226153853j:plain

↑この図しか書かれてなかったんだけど…見る人が見たら理解できるんだろーか?

なんとなく分かるのは、左64ドットと次の64ドットではコントローラが違うらしい事、右の28ドットも特別扱いっぽくなってるらしい…。

ここから理解できるのは、表示しようとするモノが「真ん中の64ドット境界」をまたぐと処理が面倒になりそう…って事だ。

 

詳しいI/Oポート情報が欲しい!

仕方ないので…ROMを解析する事にした!

最低限ではあるけれども分かった事を書いておく。

I/Oポート58h〜5Ahをアクセスすると左64ドット、右28ドットがアクセス出来る。

58hがLCDの座標設定、59hのMSBにBusy信号、5Ahにデータを出力する…らしい。これが左64ドットをアクセスする時。右28ドットにアクセスする際にはY座標の指定を+4する。今回は使わないけど!

そして中央の64ドットにアクセスするには54h〜56hポートをアクセスをするようだ。

なるほど…そういう感じなのか。

これらを組み立てる事で、IOCSの156ドット全てではなく、必要最小限のドット数のみ更新する事が出来そうな雰囲気。

 

どうやらPC-1600Kにはハードウェアスクロールっぽい仕組みがあるようで、オフセット座標を加算しないといけない事に気が付かずに一晩ハマった。その後、なんとか問題を解決してLCDCへの直接アクセスが可能となった!

 

その影響として、画面中央に表示していた画像が、左から64ドットに変更となった。でもそのおかげで効率の良い表示が出来るようになった。

 

LCDCの速度はPC-G850シリーズのそれとは違い、CPUの速度に追いついてこない。Z80のOTIRで一気に転送ってのはLCDCの速度的に無理で、1バイト送信するたびに40クロック以上待つか、律儀にBusy信号を監視する必要がある(今回はちゃんとBusy信号を監視した)。

※PC-G850Sで実験した際には、OTIRどころかOUTIを144個並べても問題なかった

 

以上の工夫をする事によって、初期状態で10784(168.5秒)掛かっていた処理が、6378(99.65秒)まで縮める事が出来た!

f:id:PocketGriffon:20210226155730j:plain

この先、圧縮データの展開処理をアセンブラ化としたとしても、6000を切る事は難しいかも知れない。とりあえずこの辺りでキリを付けるのが良いかな…と考えた。

 

動いたばかりの時は秒間1コマしか動かなくて、こりゃどうしたらいいんだろう…と思ったが、なんとかアニメーションっぽく見えるようになったのは嬉しい(^-^)

データ量もどどーんとでっかいし、とりあえず満足かな!

 

最初に公開した状態↓に比べても速くなってるのが分かると思う(^^)

 

これをやってる最中に気が付いてしまったんだけど……ウチのFX-890Pだったらメインメモリが256KBあるなぁ…とか、PC-E500に取り付けてある増設メモリも256KBだったなぁ…なんて思ってしまった。やらないよ!やらないんだからね!(TOT)

 

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

 

 

PC-1600KでBad Apple!!

このところ体調が良くなかったりして集中力がゼロ…。

よーしやるぞ!…がなかなか出来ない状況の中でも何かやりたい(^^;

こういう時にはチマチマしたデータを加工するプログラミングが捗りますw

そんなコトない?? 

 

まずはこれは見て欲しい。

これはPC-1600Kで「Bad Apple!!」の動画(元から影絵)を表示させてみたものだ。

今回はこれの解説をしてみたい。

あんまり面白い内容じゃないかも(^^;;

 

PC-1600Kのメモリを使い切ってみたい!

やっぱレトロやってると空きスロットは埋めたくなりますよね!

私は使う使わないは別にしても、埋めるチャンスがあるのならば埋めますw

f:id:PocketGriffon:20210221201233j:plain

我が家のPC-1600Kさんには増設メモリ(CE-1600M:32KB×2)を取り付けてある。最初は辞書ROM(CE-1650M)が付いてたんだけど、プログラム開発には何も使わない事に気が付いて、それ以降は増設メモリだけを取り付けるようになった。

でも……せっかく取り付けても使う機会が無かったんですよね…。まさかBASICでそんなでっかいプログラムを組む事も無いし…。

 

開発環境も整った事だから、何かメモリを埋め尽くすような「なにか」をしてみたい!

そんな事を漠然と考えながらアイディアを探していた。

そもそも、PC-1600Kの画面(156×32ドット白黒)で何かをやるにしても、世の中で参考に出来るものが少ない。他のポケコンシューティングゲームとか凄いなぁ…とか思うけれども、あれを移植する気には到底なれない(^^;;

 

何気に見ていたyoutubeで出てきたBad Apple!!というPV。実は何度となく名前は見たことがあったけれども、動画を見るのは初めて!なるほど……そうね、これをPC-1600Kで動かしたら…と頭によぎってしまうのには時間が掛からなかったw

拡張メモリの64KBにどのくらい入るのか分からないけれども、頑張ってみるには楽しい題材だと思った!

 

検討!

そもそも…こんな大きくて長い動画、どうなってるんだろう…と思って探してみたところ、mp4ファイルが存在する事が分かった。調べてみると、動画の画像サイズは512x384ドットのグレイスケールだった。

PC-1600Kで表示出来るのは156x32ドット、常識的に考えてもそのまま綺麗に変換という感じにはならないだろう。

まずはこのオリジナルの画面サイズを小さくしてみて、見るに堪えられるかどうかを検討してみる。

ffmpegというコマンドを使えば、アスペクト比を固定したまま画像サイズが変更出来る。

 

さっそくやってみたが……縦サイズを32ドットにしようとしたところ、横方向が割り切れない(アスペクトを維持したまま変換出来ない)というエラーが出てしまった。そうか、縦も横も綺麗に割り切れる数で変換してやらないといけないのか…そりゃそうだ。

 

そこで、縦サイズを64ドットにして変換してみた。この場合、縦サイズは48ドットとなりPC-1600Kではそのまま表示出来ない。でもまぁまずは変換してみる事が大切だ。

f:id:PocketGriffon:20210221204815p:plain

うーん…見られなくはないけど、相当厳しいかも?でもこのくらいが現実的だろう。

で、表示仕切れない部分については、上下8ドットずつ削る事にした!単純明快w

 

表示するサイズは横64ドット、縦32ドットと決めた!

PC-1600Kの画像は縦8ドットで1バイトの構成。という事は64x4バイトで1つの画像に256バイトが必要となる。64KBのメモリで256枚の画像。これを高速に切り替えてやればアニメーションに見える…という算段だ。

だがまてよ……オリジナルのデータは秒間30フレームで作られているっぽい。という事は256枚という最初の8秒だけ表示されるって事なのか…。うーんさすがに少ない??圧縮してもう少し入るように頑張ってみよう!

 

データ抽出の旅!

mp4フォーマットのままでは加工がしづらいので、扱いなれたjpegに変換する。

  ffmpeg -i movie -f badapple.mp4 data/%04d.jpg

これでフレームごとにデータを出力する事が出来る。

そしたら…なんと6566ファイル出力された!!

これを…うまいこと加工して64KBに納めないといけないが、そもそもこんな沢山のファイル全部納めるのはまず無理だw この時点で全データ格納は諦めた。

 

元のデータは白黒と言ってもグレイスケールのデータだ。しかしPC-1600K用のデータに変換する際には白黒の2値に落としてやらないといけない。真っ黒が0、真っ白が1とした場合、0.5までの色は白にする事にした。この辺りは良い感じの値が必要だが、まずは決めちゃうことが大事。気になったらあとで調整すればいーのよ(^-^)

 

圧縮アルゴリズムは迷わずでRLE(Run Length Encoding)とした。理由はいくつかあったが、PC-1600K上でリアルタイムに展開して表示しなければならない。潤沢なCPUパワーがあるマシンでは無いので、展開処理が簡単な方が良い。そう考えると選択肢がどどーんと限られてくる。今回のように色が2値限定の場合、ランレングス圧縮との相性は抜群だ!

 

ここではランレングス圧縮の細かい説明をするつもりはないので、ネットで検索してもらいたい。

 

絵によって縦方向を基準で圧縮した方が良いか、横方向を基準として圧縮する方が良いのかを見極める必要がある。

例えばこんな感じの絵↓

f:id:PocketGriffon:20210221212830p:plain

これは縦を基準として圧縮した方が良さそうだ。

逆にこういう絵↓は横を基準とした方が圧縮率があがる。

f:id:PocketGriffon:20210221213034p:plain

まさかデータを1つずつ見ていくわけにもいかないので、ツールの中で両方の圧縮を試してみて、1バイトでも縮まった方を採用する事にした。同じサイズだった場合は縦を採用した。これはPC-1600KのVRAMの都合で、縦方向の圧縮が都合が良いからだ。

 

拡張メモリで使える詳しいサイズを知りたい!

拡張メモリを積んでも「MEM」しかしたことが無い人は多いと思うw 数字が増える満足感は計り知れないw かくいう私もそのひとりだ!

 

しかし今回はCE-1600Mの32KBメモリ全てを使い切る事を前提としているため、使い方について正しく理解しなければならない。

なぜこんな風に強調しているのかと言えば、今回エラくハマったからだww

 

目的としては拡張メモリの64KB分をデータ領域として使いたい。出来ればファイルとして置くのではなく、普通にアクセス出来るメモリとして扱いたい。

マシン語領域として宣言する必要があるんだろうな…と思ったので、何も考えずに「NEW "S1:",&8000」としてみたがERROR 24になってしまう。

ERROR 24というのはパスワードが宣言されている場合に禁止されているコマンドを実行しようとすると出るエラーだ。

パスワードなんて設定していないよ…

知らぬ間に何かをしてしまったのかも…と思い、本体を完全リセットしてみるが全く変わらず。これだけで丸2日くらいハマってしまった(やる気なしモードなので実際には数分x2日分)。

 

散々調べてみて分かったのだが、どうやらINIT命令でRAMモジュールのモードを切り替えてやらねばならなかったらしい!これって基本中の基本???

  INIT "S1:", "P"

普通に増設メモリを取り付けるとINIT "S1:", "M"としたのと同等のようで、メモリモジュールは拡張メモリに設定される。MEMするとメモリが増えて見えるのはそのおかげだ。

"P"を指定すると、通常のプログラムから保護される場所になるらしく、マシン語データなどはここにいれるっぽい。プログラムからは保護されるのでMEMしても容量は増えて見えない。

そもそも「プログラムから保護」って言い方が分かりづらい(T-T) マシン語のプログラムは、プログラムではなくデータとして扱われるって事なのかな…。

 

ここで疑問がひとつ。標準メモリの16KBはモード的には"M"みたいなんだけど、INITでマシン語エリアも設定出来る。なんで???これがいらぬ混乱を引き起こす(T_T) アタマの中にメモリマップやモジュールの事が入っていないと理解する事は不可能だと思った…orz

 

  INIT "S1:","P"
  NEW "S1:",&7F3B
  INIT "S2:","P"
  NEW "S2:",&7F3B

よし!これでようやく拡張メモリにデータを置けるぞ!(^-^)

データが置けるのはBANK0では&80C5〜&BFFF、BANK1では&8000〜&BFFF…という感じにものすごーく分かりにくくなってる…。

今回のプログラムでは以下のように決めた。

  BANK0 &8100 - &BFFF
  BANK1 &8000 - &BFFF
  BANK2 &8100 - &BFFF
  BANK3 &8000 - &BFFF

アドレスが連続しないという問題は解決しないけれども、脳内での変換はだいぶ楽になるはずだ!拡張メモリ2つで64KBのうち、利用出来るのは65024バイト(63.5KB)となった。

 

ちなみにプログラムはBANK0の&C100から置いてある。ここは本体標準メモリ。ワークなどもここに置いてある。なんとなくこういうメモリ構成で作るのが作りやすいかもな…と思った。

 

実際の画像データ自体は、ランレングス圧縮して出来たファイルをcatで繋げて大きなサイズのファイル(65024バイト以内)にし、それを各バンクごとのファイルに分割した。その際、BLOADで読めるヘッダ(16バイト)を付けて終わり。あとはPC-1600K本体に読み込ませるだけだ。

f:id:PocketGriffon:20210221221636j:plain

結局、このサイズの中に1086枚の画像が入った!

 

実機でプログラミングする前に…

この手のプログラムを、PC-1600K実機で作っていくとデバッグが結構大変だ。出来る限りホストマシンで作り、動作的に問題ないものを実機に送り込んだ方が良い。そのためのC言語開発でもある!

このブログを読んでる界隈の方々に伝える事でもないが、C言語であればMacとPC-1600Kの両方で動くプログラムを作るのは簡単だ。

f:id:PocketGriffon:20210221222629j:plain

こんな感じでテキストで構わないので、確実にMac上で動くモノを作ってから実機に送り込む。おかげで実機での動作確認は数回程度で済む。

 

速度が出ない!

まずは動かす事が大事!速度は後回し!…といつも言ってます、はい。

そして今回もそういう作り方をした。まずは確実に動くようにしてからでないと工夫のしようがないからね。あ、メモリに関しては最初から工夫しとかないとダメ!!後からなんとかするのは大変だよw

 

今回は出来る限りC言語(LSIC 80)で書いた。アセンブラ化したところは

・バンク切り替えして拡張メモリから1バイト取得

・出来上がったデータをVRAMへ転送

の2つくらいだ。他はインラインアセンブラも使わずに作った。

 

実際にPC-1600K実機で動かしてみたのだが……こりゃあかん(^^;; 秒間1コマ程度しか動かない!うーん…予想では秒間3コマくらいは出そうな気持ちだったんだけど(T-T)

この状態で、取り切れるだけのバグは取ることにした!実際に表示がちゃんとしないデータなどが残っていたのだが、これらを全て片付けてからの高速化だ。

 

一通りバグが取り終えたところで、改めて高速化について考えてみる事に。

基本中の基本として、C言語で書いたモノがどんなアセンブラコードに変換されているのかをチェックする。すると仮想VRAMアドレスの計算時のy/8などが除算処理されていた。これは数の暴力、テーブル化で単純化して解決した。

 

次は圧縮されたデータの展開処理。展開処理は2つあり、縦方向を基準とした展開と、それを横にした展開ルーチンだ。この2つが非常に重たいのは明白。ちなみにデータは縦基準で圧縮されてるものが圧倒的に多いので、まずは縦展開処理の高速化を考える。

 

パッと考えられるのは、縦1ラインが全て黒または白の場合だ。これは判定も簡単だ。

次は1バイト全てが黒または白の処理も簡単に対応が出来た。

この2つの処理を入れてみたところ、かなり高速化された。やっぱりビット演算は得意では無いZ80。特に高級言語で書く際には注意が必要って事だ。

 

横展開処理に関しては、横方向にアドレスが連続しているので仮想VRAMの計算そのものを外した。さらにビット演算もテーブル参照をやめて計算するようにしたところ、想像以上に速くなった!

 

とりあえず完成ということで…

なんかやる気が出ないモードに突入しているにも関わらず、ちまちま作業は出来るんだなと実感。気合い入ってる時は30分で出来る事が1週間掛かってる感じだけど!

 

この後やるとしたら、ついにアセンブラ化かなぁ…でもとりあえず動いてるので、これでいいかなーって気持ちにもなるw きっと今よりも3倍くらい速くなる気がする…。

 

あと、アニメーションが最後まで流せないのも残念なので、オンメモリにこだわらずRS-232C経由でデータを読みつつ表示…なんてのも楽しそうだ。これは画像処理が速くなればなるほど厳しくなってきそう。目一杯高速化したのちに可能かどうか検討するのが良さそうだ。

 

当初の目標だった「メモリを目一杯使って何かをする」は達成出来た気がする!ちゃんとバンク切り替えてデータ読めた!グラフィックも表示出来たので一定の達成感はある。

よーしよし、PC-1600K面白いぞ!(^-^)

 

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

SHARP PC-1600KでBLOAD!

f:id:PocketGriffon:20210213105642j:plain

私の中ではMAXお気に入りポケコンとして君臨してるSHARP PC-1600K!

機能や性能的にはPC-G850VSやPC-E650の方が上だったりするんだろうけれども、見た目大きさ重さなども含めてのお気に入り度合いは群を抜いている。

 

まだこのブログを始めるよりも前、ちょうど1年前の2020年2月頃にPC-1600Kの開発環境を整えた。

当時はSDCC(Z80 Cコンパイラ)を中心に環境を組み立てたけど、アセンブラとの連携のやりにくさから主にアセンブラでの開発っぽくなっていた。とりあえず画面にグラフィックスを表示して終了となった(まぁ私のいつものパターンだw)

 

今回、PC-8300用にLSIC80の環境を整えた流れで、もう一度PC-1600KでもLSIC80を中心とした環境を整えてみようという気になった。ビルドする環境自体はPC-8300と全く同じだが、本体へプログラムを送り込む方法だけが異なる。

 

PC-1600K自体、マシン語プログラムをBSAVE、BLOADする事が出来る。

前回の作業ドキュメントを漁ってみたが、どうも当時はBLOADの存在に気が付いていなかったようだ。BASICでマシン語データを送り込む方法だけが試されていた。

せっかくある機能を使えてないのはもったいないので、頑張って解析してみる事にした!

 

BASICでBLOADするのは?

何にしてもBASICからBLOAD出来るのが一番効率良いに決まってる。でもそのためには、PC-1600Kへ送り込む「データのフォーマット情報」がどうしても必要だ。

本体のマニュアルを見ても、残念ながらそういった情報は書かれていない。

PC-1600Kデータブックに、テープへ記録するフォーマットについて書かれていたが、RS-232Cでも同じとは限らない。むしろ同じであるハズがない。

f:id:PocketGriffon:20210213122243j:plain

BSAVEのパラメータ(開始アドレス、サイズ、実行アドレス等)から想像出来るヘッダを付けて、いくつかのロード実験を繰り返したが、成功にもエラーにもならずPC-1600Kは沈黙状態(T-T) こうなるとリセットするしか止める方法が無い。

 

うーん、やっぱり解析するのは簡単じゃ無いなぁ…

 

BASICROMを解析しようとも思ったが、これまた壮大な話になってしまう。

フォーマットを調べるのは簡単じゃないかもな…。

仕方なく別のアプローチを検討する事となった。

 

バイナリロードプログラムを移植する?

HC-88で開発をしたバイナリロードプログラム。先日このプログラムをPC-8300へ移植して、ロード→実行の時間が劇的に改善された。

このプログラムをPC-1600Kへ移植する事も、比較的簡単と思っていた。

まずはこちらを実用化するべきかも知れない…と思い、移植に必要な作業を開始した。

 

このバイナリロードプログラム自体はオールアセンブラで書かれているため、移植そのものには大した手間は掛からない。シーケンスはそのまま利用出来るので、RS-232Cを使う部分だけPC-1600K用に書き替えてやれば良いはずだ。

 

バッファサイズの変更、通信パラメータの設定、通信デバイスの選択等、HC-88やPC-8300には無かった初期化が数多く存在した。特にバッファサイズを変更出来るのはありがたい!HC-88などは明らかに通信バッファが足りなくて速度が出ないって感じだったもの(T-T)

通信速度を38400bpsにするための推奨バッファサイズは1100バイト以上らしい。そんな速度で通信出来たらマジで嬉しい!そんな事を考えながら準備を進めた。

 

そしたら……なんとドハマりしたのは別のところだった! 文字列表示関数でコントロールコードを解釈してくれないみたいなのだ!&12(画面クリア)、&OD&0A(改行)などがことごとく処理されない(T-T)

何かメモリ中にスイッチがあるのかも知れないと思い、あちゃこちゃ探してみたがどうにも見つからない。試しにBASICで「PRINT CHR$(12)」とやってみたが画面クリアがされない!え??もしかしてそういう仕様なの??

 

仕方ないのでいくつかのコントロールコードを解釈する事の出来る1文字表示処理を自前で書くことにした。きっと同じような処理がROMに含まれてるんだろうな…と思いつつも、今は動かす事を急ぎたい!

 

突破口!

コントロールコードを含んだ文字列が問題なく表示出来るようになった頃、少し落ち着いて資料を見返してみる事にした。ずっと他の機種に取り組んでいたため、PC-1600Kデータブックを手に入れてからも熟読出来ていなかったのだ。この本は国会図書館で複写サービスを受けていた事もあり、ある程度の中身は読めている自覚があった。

 

そうか…BLOADのフォーマットばかり気にしていたけど、考えてみればRS-232Cに対してBSAVEしてみたらデータが出力されるのではないか…と気が付いた。もちろん当初テストもしていたが、PCG-LinkMacにはなんの情報も出力されなかったため、後回しにしていたのだw

 

Macコマンドラインで以下を打ち込む(XXX...の部分は通信アダプタによって異なる)

  cat /dev/cu.usbserial-XXXXXXX > m.bin

PC-1600K本体で以下を打ち込む

  BSAVE "COM1:",#0,&C000,&C00F

 

Mac側は自動停止しないのでCTRL-Cで中断。

これでPC-1600Kから送られてきたバイナリデータがm.binとしてファイルに入るはずだ。

そうして出来たのが↓これ。

f:id:PocketGriffon:20210213124855j:plain

これを見てピンときた!

なんだ、これはディスクへBSAVEした時のデータと同じじゃ無いか!と(^^;;

f:id:PocketGriffon:20210213125427j:plain

実行アドレスのところにそれっぽいアドレスを入れてしまうと、BLOADした後に「実行されて」しまう。実行されて困る場合には、実行アドレスを&FFFFにしておけば良いようだ。

 

それじゃあ…という事で、簡単なHello Worldを作成し、出来上がった(PC-1600Kでの)実行ファイルに、ヘッダーをつけてやるツールを作成した。

f:id:PocketGriffon:20210213125954j:plain

完璧!!!(^-^)/

BLOADした後、そのまま実行されて「Hello World!」が表示された!

 

出来上がった開発環境

今回もLSIC80を中心に環境を構築したため、Macだけでは完結していない。

編集とPC-1600Kへの転送はMacで行うが、ビルド自体はWindowsで行っている。普段からWindowsを使っている方であれば、Windowsマシン1台で完結する開発環境が作れるだろう。やっぱりWindowsへ移行した方がいいのかなぁ…なんて事も頭によぎるけれども、使い慣れるまでにストレス過多になりそうなのでどうしても決心が付かない(T-T)

 

まだ通信速度のテストとか一切していないので、9600、19200、38400と試してみたい!

少し大きめな何か作りたいなー(といつも言いつつ何も出来ない…)

せっかくなので何かやります!

PC-1600K、久しぶりに触るので楽しみです!(^-^)

 

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

増設メモリを集めてみた!(CASIO以外)

f:id:PocketGriffon:20210206001215j:plain

PC-1360とPC-1360Kのメモリ容量を調べている流れで、

そういえばウチにはどんなポケコン用増設メモリがあるんだっけ?…と気になったので、引っ張り出せる範囲で並べてみた!

 

しかしCASIO系のポケコンは増設メモリを確認するために裏ぶたを開ける分解が必要で、さすがに気がめげてしまった!いつか気力がみなぎってる時にチャレンジしてみたい!

 

では写真と簡単なご紹介をば!

 

PC-1350系

f:id:PocketGriffon:20210206001800j:plainf:id:PocketGriffon:20210206001749j:plain

f:id:PocketGriffon:20210206001515j:plain

少し大きめのサイズをしているこのメモリ。ウチではPC-1350に取り付けられている。

PC-1360とはメモリのサイズが違うため流用できない(T-T)

しかもPC-1350は16KBまでしか認識しないので、32KBのメモリを取り付けても無意味だったという…orz

f:id:PocketGriffon:20210206003237j:plain

これもPC-1350に取り付けられるサイズのメモリ。珍しくRICOH製。

互換メモリも存在してたのかぁ…。

 

PC-1360/60K、PC-E500シリーズ系

おそらくシャープのポケコンの増設メモリと言えばみんなが思い出すのはコチラかも?

f:id:PocketGriffon:20210206003438j:plainf:id:PocketGriffon:20210206003417j:plain

f:id:PocketGriffon:20210206003428j:plainf:id:PocketGriffon:20210206003447j:plain

f:id:PocketGriffon:20210206003407j:plain

これ以外にも64KBメモリがあるらしいけれども、私は所有していなかった(^^;

バックアップ電池を年に1度は交換した方がいいのかなぁ…なんて思いつつも、ここ2年くらいの間に交換した事が無い!

主にPC-1360系に取り付けてる。

 

番外編として、このようなカードもある↓

f:id:PocketGriffon:20210206004248j:plainf:id:PocketGriffon:20210206004228j:plain

どちらも高松製作所製のメモリ。256KBと256KB*2の2種類所有。

PC-E550でSepiaを起動する際にとても役にたった!(^-^)

256KB*2の方は、(1 2と印刷された場所にある)スイッチで切り替えられるんだけど、一度も切り替えた事が無い…。という事は半分は使われてないって事ね…汗 私の運用の問題だと思うけれども、もったいない!

f:id:PocketGriffon:20210206004929j:plain

↑これが上で出てきたSepiaというゲーム。

ディスクドライブ、(PC-E500では)メモリ増設必須という過酷環境を要求するソフト!

プログラムを書き替えて増設メモリドライブで動くようにして遊んでました(^-^;

 

PC-1500系

f:id:PocketGriffon:20210206005223j:plainf:id:PocketGriffon:20210206005237j:plain

PC-1500系に取り付けることが出来るメモリモジュール。

他にもCE-161というのがあるけど、他機種用でご紹介。

8KB増設で当時の値段で30,000円、4KBで15,000円だった。

本体が59,800円だったことを考えると、いかにメモリが高かったのか分かる!

 

f:id:PocketGriffon:20210206005209j:plain

↑こんなモジュールもあった。

カナテープではなくてカナモジュール。

おそらくカナ表示機能?を追加しつつ4KBのメモリ増設をするモノで、当時25,000円。

 

PC-1600K系

f:id:PocketGriffon:20210206010108j:plainf:id:PocketGriffon:20210206010126j:plain

みんな大好きPC-1600K用のメモリ(^-^)

ここに来て接続端子が隠され、電池交換もだいーぶ楽ちんになった。SHARPポケコン用増設メモリの完成形な感じがする!

ちなみにCE-161はPC-1500にも取り付けられる。

 

その他

思ったよりも数が無かったので、「その他」でまとめてしまったw

 

PC-2001

f:id:PocketGriffon:20210206010525j:plain

NEC PC-2001用の増設メモリ。おそらく8KB。

本体の8KBと合わせて16KBの大容量を扱えた!

f:id:PocketGriffon:20210206011038j:plain

中にバッテリーが入っているんだけど、外見でバッテリーを匂わせるような表記が全く無いため、バッテリーの存在を知らずに使ってる人も多い気がする!

 

NEC PI-ET1

f:id:PocketGriffon:20210206011338j:plain

…写真を載せてみたけれども、NECが発売していたPDAを知らない人も多いかも?

f:id:PocketGriffon:20210206011552j:plain

↑こんな形をしている。色違いで2台所有。

 たまーにハー○オフなどで、ジャンクコーナーの電子辞書に紛れて入っている。
しかも税別100円!

このPDAの増設メモリが上にある64KBのカードで、おそらく強烈レア(^-^;;

 

PASOPIA mini

f:id:PocketGriffon:20210206012036j:plain

PASOPIA mini用の増設メモリで容量12KB。

メモリの物理的サイズは結構大きい。

 

 

あ、なんか気力が切れてしまったので、この辺で終わりにしときたい!(^^;

CASIO系、その他デスクトップなどもご紹介出来たらいいな!

意外に増設メモリって「これはどれのだっけ?」と覚えとくのが大変だったりするので。

 

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

PC-8300でプログラミング その3

f:id:PocketGriffon:20210202124236j:plain

せっかく高速バイナリ通信の仕組みを作ったので、それを活かした大きめサイズの何かを作ってみたい…と思った!

内容よりもデータ量よ!←割とひどい暴言

 

グラフィックデータを入手せよ!

もう次の事を始めたい気持ちが一杯で、時間が掛かる複雑なプログラムは無理だなぁ…と思い始めてしまったw HC-40とかHC-88の時にも「絵がない絵がない」と言い続けていたので、ここいらでまとまったモノクロ画像を用意しとこうと考えた。

 

f:id:PocketGriffon:20210202125749j:plain
工学社から発売されているI/O(今も出てるよ!)に、MZ-80B用の「グラフィック花札こいこい」というゲームが掲載されていた!私は当時のI/Oを別の場所に置いてしまっているため、手元にあった「MZ-80B活用研究」という書籍を参考にした。

ここから花札のグラフィックデータを借りることにした!(すみません)

 

データを借りる…と言っても、ダンプリストのどこからがグラフィックデータなのかを解析しなくてはならない。これはゲームプログラムの説明記事とBASICプログラムから比較的簡単にアドレスを割り出す事が出来た。そこで震え上がったのが、約10KBというデータ量…。

256バイトのブロック38個分だ!いやはや…しびれるww

 

若い頃は本当に沢山のダンプリストを入力した。一番長かったのがI/Oに掲載されていたFM-7用のゲーム「NOBO」じゃないだろうか…。64KBかそれ以上あったような気がする。掲載ページを減らすためかダンプの文字も小さくなっていたが、当時は気にせず打ち込んでいた。

最後にダンプリストを打ち込んだのは何だったのかなぁ…ポケコンかも?

 

それから長い月日が流れ、2年ほど前に必要に迫られてFM-8のゲームのダンプソフトを打ち込む必要が出てきた。昔、1ブロック(256バイト)を打ち込むのにチェックサムまで合わせて10分くらい掛かった記憶がある。そこから計算しても時間が掛かりすぎるな…と思い、OCRにてバイナリを入手する方法をとった。

OCRで読み取ったデータをテキスト整形してチェックサムを合わせて…とやると、1ブロック10分以上の時間が掛かったが、それでも手間を考えたらいっか…と思っていた。

f:id:PocketGriffon:20210202130617j:plain

最近はOCRに頼らず手入力している。OCRしたデータの間違いを修正しチェックサムを合わせるという時間が、実は結構掛かると気が付いたのだ。OCRに比べて入力の手間は掛かるが、時間は圧倒的に短い。当時は1本指でテンキーを16進数に見立てて打ち込んでいたが、今はフルキーを両手で打ち込んだ方が速いのだ!

ウソだと思ったら、試しに今、256バイトを打ち込んでみて欲しい。昔よりも高速に入力出来るはずだ!(^-^)

そしてチェックサムまで入力したテキストをチェックするツールを作った。これで相当なスピードアップとなり、2年前から何度となくダンプリストを打ち込むようになった。

 

データフォーマットを解析せよ!

私自身、MZ-80Bは所有した事が無い。当然、プログラムも作ったことがない。

 

しかしこれまた2年ほど前、1日だけお披露目する目的のためだけにMZ-80Bエミュレータを書いた事があった。開発も一晩というお気楽実装ではあったが、ちゃんとゲームが動いたw

その際、グラフィックのデータフォーマットは理解したつもりでいたので、だいーぶ楽観視していたのだが……今回、なぜかその形式に基づいて解析しても元の絵に戻らない問題が出た。

 

あれー……なんでだろ???

いろんな資料を漁るが、どうにも理解が及ばない。

オリジナルプログラムを解析してみたところ、BASICのPATTERN命令で表示しているようだ。ここに何か秘密があるのか…と思い調べていくと、なんと想像とだいぶ違うフォーマットになっていた(^^;; これは…分からないww

 

というわけで。外部ツールにてさくっと変換!

f:id:PocketGriffon:20210202131837j:plain

そのままC言語の8bit配列のカタチに変換する事にした。

こうしておけば、将来的に他のマシンでも使えるはずだ!

 

実機で表示させてみる!

PC-8201系のプログラムで難しいだろうな…と感じるのは、LCDへグラフィックを表示する辺りだと思う。アドレスが連続していないうえにLCDCのアクセスが少しばかり面倒だ。

まともに計算して描画しようとすると、条件判断文だけでそれなりになってしまう。

 

そこで、前回PC-8201でプログラミングした時だが、仮想VRAM→実際のVRAMへの転送処理を書いた。ユーザープログラムでは連続したアドレスの仮想VRAMに絵を描く、転送処理で複雑なVRAMアクセスをしてくれる…というわけだ。

下のリンクに詳しい概念を書いていたので、興味あったら参考にしてほしい(^-^)

 

ここまでお膳立てが出来ていたら、C言語で絵を表示するのは簡単だ。

f:id:PocketGriffon:20210202134506j:plain

マジックナンバーばりばりのコードで申し訳ないw

お前ホントにプロか?との声が聞こえてきそうな気がするけどキニシナーイw

8085アセンブラで書こうとすると少々面倒な気持ちになってしまう処理でも、C言語で書いたら一瞬だ!レトロマシンでもこういう効率の良さが必要だよね(^0^)

ちなみに上記のコードをそのままコンパイルすると、結構悲惨なコードが出てくる。速度的にはアセンブラで書いたのに比べて1/3以下くらいかも知れないが、まずは動かす事が重要よ(^^)

 

当たり前なのだが…C言語使うと四則演算が簡単に書けて本当に助かる。アセンブラで書いてると乗算ひとつとっても大変だ!(^^;;

 実際に動かしてみたのがこちら↑

 

例のバイナリ転送プログラムを使ったよ!

先日開発したバイナリ転送プログラムを最大限に活用した!

今回は花札のグラフィックデータだけで10KB近くもある巨大なものだ。BASICのテキストに変換してみたら、37KBにもなってしまった。実機にロードするためのメモリが足りない!

これもバイナリ転送さまさまだ!

 

転送速度を測ってみたが、約10KBの転送に掛かる時間は手動計測で10.5秒ほど。きっちり9600bpsで転送出来ているとみて良いだろう!(^-^)

表示プログラムが単純すぎて、2〜3度しか転送しなかったのはナイショだw

 

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

PC-8300でプログラミング その2

f:id:PocketGriffon:20210131172415j:plain

HC-40/88の時に開発して利用していた、バイナリファイル転送プログラムをPC-8300にも作ってみた! まだ試していないが、PC-8201でも無変更で動くはずだ。

 

開発のきっかけ

PC-8300でプログラミングしてて、段々とダウンロードに掛かる時間が耐えられなくなってきた!最初のうちはプログラムのサイズも小さく、数秒でロード→実行とサクサク進められるだが、コードサイズが大きくなればなるほど実行に時間が掛かるようになる。

 

先日作っていたメモリダンププログラムは、生産性を上げるためにC言語を用いたため、コードサイズは大きくなりがちだ。

先日の時点で実行バイナリで1215バイト。え?たったのそれだけ?と思うか、意外にでっかいね…と思うかは、それぞれ生きてきた年代で違う気がする(^^;

 

このバイナリをRS-232Cでロード出来るようにBASICプログラム(テキスト)へ変換し、PC-8300へ送り込んだ後に実行(RUN)してPOKEでメモリへ書き込む。この行程で掛かる時間は、

ロードで20秒、RUNして動き出すまでに10秒。

転送速度を9600bpsに設定しているが、1文字送るたびに4msのウェイトを入れておかないと途中で通信に失敗してしまう。おそらく…通常の通信は大丈夫だが、1行をロードし終わるたびにBASICの中間コードへ変換してメモリへ格納する作業に時間が掛かってるのだろう。

 

移植する?新規作成する?

やりたいことは単純明快で、バイナリデータをロード出来るようにしたいだけだ。処理の内容的にもHC-40/88で作ったプログラムと全く同じ。だとしたら移植する道もあると考えた。

 

通信プログラムと聞くと構えてしまう人もいるかと思うが、実際には通信の根幹部分から書くことなどない。ROMの中にあらかじめ用意されているであろう「RS-232Cから1バイト受信」ファンクションを上手に利用すれば良いのだ。

 

HC-40用に作ったプログラムで、実際にHC-40に依存しているところと言えば、RS-232Cの初期化、1バイト受信、RS-232Cの終了、そして1文字表示処理の4つだけだ。あとはCPUがZ80だったので便利な命令を使っていたが、これを8085に置き換えれば…そのまま動くのでは??

 

なんとなく見通しが立ってきたので、方針は「HC-40版からの移植」とした!

 

移植作業

やりたいことははっきりしているが、残念なことにPC-8300で通信のプログラムを組んだことが無い。まずは必要なエントリを探すところから始まった。

RS-232Cの初期化と終了の処理は、HC-40と全く違う構造になっていたため、完全な作り直しとなった。

他にもPC-8300では受信バッファが溢れたことを知る方法が無いなど、仕様の違いはちょこちょことあった。

一応、PC-8300の名誉のために書いておくが、バッファ溢れが検知出来ない事に関しては、そもそもバイナリを送る事を想定していない+内部でXon/Xoffの制御を完璧にしているため、事実上必要の無いと判断した可能性がある(^-^) これは不備じゃなくて仕様だ。

 

結局、ROM関数のエントリーを調べるのに時間が掛かったが、移植作業自体は1時間も掛からなかった!Z80で書かれたコードも多くなく、シフト命令と相対ジャンプを変更しただけで修正出来た。

 

出来上がったバイナリ転送ツール

f:id:PocketGriffon:20210131175919j:plain

動かしてみた画面の感じも全く同じだ。

まんま移植してるんだからそりゃそうだ(^^)

 

通信環境そのものが高機能なゆえに速度が遅かったHC-40に比べ、PC-8300の通信プログラムは単純明快だ。そのため、HC-40に比べても高速な通信が出来るようになった。

上にも書いた通り、メモリダンププログラムをBASICでダウンロードすると20秒、RUNして10秒と、合計で30秒掛かっていた。

それがこのプログラムでダウンロードすると、なんと1.5秒で通信が終わるw

まさに一瞬だ。

通信速度は9600bpsノーウェイトで転送が出来る。試しに19200bpsにしてみたが処理が間に合わなかった。おそらく画面表示を止めたら間に合う気がするが、まぁそこまでやる必要もないだろう。

 

はー、これで相当便利な環境になった気がする!

PC-8300/8201は「アセンブラしか使えない」+「バイナリ転送が出来ない」と、いろんな理由をつけて大きなプログラムを組まない方向でいたが、それらの制限が無くなってしまった!w

何か大きいものを作りたい気持ちはあるが…さてどうしよう(^-^)

 

実はとっても楽しいマシンが手に入ってしまい、そっちへ流れてしまうかも知れない!

ドはまりするのが目に見えているので、やり始める時期を見極めたい(^^;;

うーん、PC-8300で何か作りたいよぉ…(アイディアと絵が欲しいw

 

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

PC-8300でプログラミング その1

f:id:PocketGriffon:20210130213008j:plain

PC-8300でプログラムを楽しみたい!

NEC PC-8300を手に入れて以来、バッテリーなどハード的な部分を充実させてきた。

そういえばあれ以降も充電し続けているので、最新のバッテリー電圧を測ってみた。

f:id:PocketGriffon:20210130213651j:plain

うん、良い感じの上限で止まっているみたいだ。

充電機構は正しく動作してると解釈しても問題なさそう!(^-^)

 

こうやって満足出来るマシンになってくると、次はプログラムしてみたくなる!

このブログでも紹介しているが、過去にPC-8201でガリゴリとプログラムしている。あの頃はプログラム全体をアセンブラで書いていた。これは8080に対応したコンパイラが手元になかったのが大きな理由。

 

EPSON HC-40でコンパイラを活用した際にはSDCCというコンパイラを活用した。このコンパイラZ80とさらに上位のCPUが対象となっている。8085(8080)は対象外だったため、PC-8201では利用出来なかった。SDCCで対応しているgbz80(ゲームボーイのCPU)を改造して使えないかとも思ったが、そんな簡単な話でもなかった(T-T)

 

他にもMSX-Cも8080コードを吐けそうな雰囲気だったが、リンクされるライブラリがZ80で書かれている事に気づいた。実験している最中に自宅のMSXFDDが壊れるなど不運にも見舞われた(そういえば修理してない…)。

 

私はアセンブラで書くのも楽しいと感じられるタイプの人種だが、それでも大量にアセンブラを書くとなると寿命が縮まってしまう。可能ならば速度やメモリ量を気にしなくても良いところは生産性を上げたい。

というわけで、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で試してみたところ……

f:id:PocketGriffon:20210130222007j:plain

ですよねー(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用だ。

f:id:PocketGriffon:20210130223044j:plain

書籍はこの本をとても参考にしている。ROM内ルーチンやワークエリア、I/Oマップなどが詳しく書かれている。サンプルなども多めなので、PC-8201ユーザーはぜひ手に入れておくと良いだろう。ただ誤植も多い上に説明足らずな部分も多々ある。
この書籍を補完するカタチで、こちらのサイトにもお世話になっている。

英語のサイトだけど技術資料を読むのに英語も日本語も変わらんと思うw

特にPC-8300の技術資料もあるのは助かる(^-^)

一番参考になるのはROMデータを逆アセンブルする事だと思うが、まだダンプを作るのに必死になっていて手つかず。今回のダンプで十分なテストが出来たので、このあと吸い出しにチャレンジしてみたい。

 

今回はC言語が使える…とは言っても、アセンブラをゼロに出来るわけではない。ユーザープログラムのブート部分(スタックの初期化など)はアセンブラだし、LCDCをアクセスする部分などもフルアセンブラだ。大雑把に、全体の8割がC言語、2割がアセンブラという割合だ。

 

開発したプログラムは、PC-8201シリーズの大半のメモリを覗くことの出来るメモリダンプ。RAMおよびROMをリアルタイムにバンク切り替えする事が出来る。

f:id:PocketGriffon:20210130224229j:plain

開発中のPC-8300の様子。

RAMカートリッジを取り付けて、背中にはRS-232Cをしょってる。

 

フォントは4x7ドットで描画しているので標準よりも情報量が多い。240x64ドットの仮想VRAMを持ち、そこにビットマップフォントを書き込み、マシン語でLCDCへ一気に書き込む。この辺りの実験は、過去にPC-8201でやっているので参考にしてほしい(^^)

f:id:PocketGriffon:20210130224927j:plainf:id:PocketGriffon:20210130224845j:plainf:id:PocketGriffon:20210130224905j:plain

右上に現在のバンク番号が出ている。0と1が本体標準メモリの64KB、2がRAMカートリッジのメモリが見えるようになっている。

あれ?今気が付いたけど、これは1〜3の表示にした方がいいね(Menu画面の#1〜#3とあわせるため)。あとで直しておこう。

f:id:PocketGriffon:20210130225149j:plainf:id:PocketGriffon:20210130225127j:plainf:id:PocketGriffon:20210130225258j:plainf:id:PocketGriffon:20210130225236j:plain

同様にこちらはROMの切り替え。バンクA〜Dの4バンク切り替え。これは内蔵の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の時のように、バイナリ転送プログラムを作らないといけないかなぁ…これは!

 

よし!とりあえず開発環境を整えるってのと、全メモリをアクセス(表示)するプログラムを作る事は出来た!せっかくなのでもう少しだけ使いやすくしていきたいと思う。

何かゲームの移植でもしたいところだけど、絵心のない私にはそこの敷居が高すぎて超えられないw PC-8001やMZ-80Bなどの移植したいんだけどなぁ…(T-T)

 

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