GitHub – yanataka60/MZ80K_SD: MZ-80KシリーズでSD-CARDからのアプリケーション起動、BASICなどのアプリケーションからSD-CARDへのロード、セーブを実現するものです · GitHub

これに基づいて、製作された基板を手に入れて、MZ-80Kで試したのだが、FDLコマンドによる ファイルリストの表示が途中でとまってしまったり、FDでファイル名指定で読み込み開始までこぎつけても途中で通信エラーになってしまったりで、一度も成功しませんでした。

一方、同志によるMZ-700向けやPC-8001向けの基板はすんなり動いていますので、この基板固有の何か問題があるんだろうなと思って、Arduino pro や micro-SD ユニットなどを疑って、交換してみたものの、逆に症状が悪化したりしていました。

しまいには、Arduino pro の プログラムソースを書き換えて、通信速度を落としたりもしたのですが、ダメでした。

そこで、こうなったらできることはすべてやってみるかということで、ロジックIC 74LS30と 74LS04 について、調べたところ、74HCT シリーズのほうが出力波形が綺麗であるという情報があったので、74LS30, 74LS04 の代わりに 74HCT30, 74HCT04 を購入して、差し替えたら、なんと一発でエラー解消。

MZ-80K2、MZ-80C、MZ-80K2E を所有していまして、どれも同じ症状でしたらので、MZの個体の問題ではないと思いますので、MZ-80K/Cシリーズでは、ノイズの話や通信制御の能力という点で結構きわどいのか? その辺はよくわかりません。

もし同様の悩みを持っている、またはこれから基板作成に挑戦するという方はぜひ 74HCT シリーズをご検討ください。

ちなみに、ノイズも疑って、ノイズ除去のデカップリング用途を狙って、いくつかコンデンサも同時に購入しましたが、今回は不要のようでした。

ついでといってはなんですが、 CG-ROMの 2316 → 2732 の回路図も後半に掲載します。

最初は、 EPROMに書き込んで、差し替えればいいのかなと思っていたのですが、ピン配列の差異があるため、そのままというわけには行きませんでした。PROMの2332 を EPROM 2732 に換装するという事例は、海外のCommodore PET-2001や C64 をターゲットにした記事がいくつかあるのみ。日本でも紹介されている記事はあるものの具体的な配線については言及されていませんでした。

仕方ないので、まずはそれぞれのデータシートのピン配列を確認して、結線について考えました。

2332と 2732 は、その「32」が示す通り、 32KBit すなわち 4KByte のROMですので、容量は一緒。そしてピン配列もおおよそ一緒。違うのは 3ヵ所のみ。

2332 の /CE1 と M2732Aの E̅ は、両方とも Low で ROM が有効 (Active Row) という意味なりますので、これを結線。
M2732Aの ピン20 ( G̅Vpp) は、2332 の ピン12 (GND) に繋ぎます。
それと、それぞれの A11を結線。

ということで簡単なのですが、ユニバーサル基板にコンパクトに作成することを考えると、少し工夫が必要でした。
実は、基板作成には 2回失敗して、3回目にうまく行きました。しっかりとMZ-80K/C側のICソケットに刺さることが必要です。不安定になってしまいます。

うまくいった作成方法

最初に失敗だったのは、手持ちの角ピンのピンヘッドを使ったこと。これが結構 ICソケットに対しては刺さりが悪いです。Arduino や ESP32などの Break out 作成やジャンパ用には良かったのですが、適材適所ということで。

秋月で、両端がピンのものと、片側が丸穴ソケットになっているものを購入。

ユニバーサル基板の端っこに、写真のようにハンダ付け。ピン位置が同じ部分は「渡しハンダ」(言い方が古い? ) 、今風に言えば ハンダ ブリッジ (solder brigde) かな?
作成手順

① 基板をランド側 (ハンダ付けする側) を上にしてテーブル上に置いて、片側丸穴ソケットのピンを刺します。つまり、ピンの脚が浮いた状態で、基板の逆側に飛び出さない形にしてハンダ付け。垂直になるように一カ所だけハンダ付けして、垂直を調整して固定します。そのあと残りのピンをすべてハンダ付け。これを2つ分。 ( 2732を刺しますのでピッチに注意 )

② 両端がピンになっているものをハンダ付け。ピンをブレッドボードに差して、そこに基板を乗せてハンダ付けするとかなり垂直になります。ブレッドボードがあれば是非そうしてください。

③ 同一ピンは、渡しハンダで導通させます。テスターで1つずつ確認しましょう。

④ 18,20,21ピンを写真のように配線。

とりあえず以上でハンダ付け完了です。

そのままトライしてみる

基板が大きいままなので、コンデンサに当たってしまうため、2段下駄を履かせて高さ調整。

そして MZ-80K2の電源をON!

モニターのプログラムを改造したことがわかるように、SP-1002A (Aの文字を追加) としましたので、配線がうまく行ったことが確認できました。

基板を加工する

作成した基板のままでは大きすぎるので、コンターマシン (エンドレスのバンドソー) でおおよその大きさに切り出し。
写真では2つありますが、これは 2316 → 2732 (キャラグラROMの換装 ) 基板も同時に作ったためです。こちらはまた配線が少し違いますので、別途紹介いたします。

次にグラインダーで細かく、できるだけ小さくなるように加工。

出来上がり。

実装

写真の下側が モニタROMを換装したもので、上部は CG-ROM を換装したものです。モニタROM が4KBなのに対して、CG-ROMは2KBですので、配線は少し違います。

起動そして確認

今回は、MZ-80K/C で SDカードから mztファイルを読み込む基板を手に入れたので、それを利用するため モニタROMの改造をしました。また CG-ROMについては、MZ-80Aという海外版に実装されたキャラクター ROM の内容に差し替えてみたかったからです。海外向けは「カタカナ」が不要ですので、そこに結構面白い記号や図形が登録されています。PCGがなくても面白いキャラグラができそうな感じです。

二つの ROMを換装して電源を入れて、キー入力で表示できるものを表示してみまたした。

あとで、256個のキャラをすべて表示するプログラムを作成して公開いたします。

CG-ROM (2316 → 2732) の換装

CG-ROMは、 8×8ドットのキャラ文字 256種ということで、2046byte (2KB) のPROM 2316 となっています。これを EPROM 2732に換装するということで、前半2KBだけ利用します。ということで A11はGNDに固定。

切り替えスイッチを付けて 日本版と輸出版のCG-ROMデータを切り替えなんてこともできると思いますが、とりあえずは換装するだけの回路図となります。こちらはとてもシンプルです。

道具は重要

最初の2回の失敗は、基板の設計や部品に問題がありましたが、そのほかも重要でした。

ちょっと良いハンダこて、フラックス、ハンダ吸い取り線、テスター

失敗の巻 (第一回トライ)

初回、2回目は、基板の設計の問題、ハンダ付け、ピンの刺さり具合など問題だらけでした。反省の念を込めて写真をアップ。

ずっと行方不明だったのですが、 重ねてあった古い I/O の間にありました。よかったよかった。

何年か前に、MZ-80K2のエミュレータを作り出したつきに色々と資料を漁っていたのですが、

これが見つからなくて、Web上で公開されていたぼやけたの文字を読んでました。

とりあえず、さっそくデータ化ということで、PDFにしてみました。

この中で重要なのは、8255と8253 の メモリマップド I/O の部分です。これがはっきりしないとエミュレータが完成しない。

著作権上はちょっと問題ありますが、重要な情報ということで公開します。

問題がある場合は、お知らせください。すぐに非公開いします。

キーボードの実装に当たっては、MZ80K がマップドI/O方式について理解する必要がある。

今、この瞬間に押されてるキーボードは何か? あのキーボードは押されているのか押されていないのか? リアルタイムなゲームを作るうえでは欠かせない情報である。MZ80KのBASICでは、キーの状態をリアルタイムに検知する機能はない。

MZ80KのBASIC ( SP-5030等) の場合、INKEY$ でキー入力が発生するまで、ループして押された瞬間を検知することはできるが、今どんな状態かを知ることができない。しかしマシン語を使えば、簡単である。
メモリの $E000 と $E001 に接続された Intel 8255 ( Programmable Peripheral Interface ) PPI の対して、操作を行えばいいのである。

具体的には、メモリの$E000 の 上位4ビットは常に1111B として、下位4ビットには下図の知りたいキーがある場所のKEYSTROBE番号をセットして、$E0001 のDATAビットの状態をしらべれば良い。 MZ700やMZ1500のキーマトリクスはネットでもちらほら散見するが、今となっては MZ80Kのキーマトリクスの情報が無いと思われるので、ここに情報を公開しておこう。だれかの役に立つかもしれないので。

例えば、【V】キーが押されているかどうか知りたかったら、$E000 に F7h (11110111B) をセットして、$E000 の値が FDh (1111 1101B) ならば、Vキーがおされているということになる。

Z80のマシン語だとこんな感じ。BITの状態を調べて条件分岐。

LD ($E000),$F7
LD A,($E001) 
BIT 2,A
JP Z,V_KEY_PRESSED

もしくは、AND (論理積) を使って明示的に下記のようにするのも良い。

LD ($E000),$F7
LD A,($E001) 
AND %00000100     ; Bit2だけマスク（0b00000100）
JP Z,V_KEY_PRESSED

鋭い人であれば、これが複数キーの状態も検知できそうだと気づくだろう。つまり同時押しも検知できるのである。

ただし、キーマトリクスの回路の弱点として、ある特定のパターンで3つ以上のキーを押すと回路のショートルートができ、違うキーが押された誤検知するという現象があり、ゴーストキーと呼ばれています。

エミュレータでどのように組み込むか

エミュレータでは、マップされたI/O $E000～$E008 のメモリに対して読み書きがあったら、上記処理をすれば良い。

その原因が、いわゆる V-Sync (垂直同期) の問題と思っていて、どうやって Raspi Zero 2Wから V-Sync完了の情報をもらうか、そしてどれだけ速く書き込むか (次のV-Syncまでの間に画面生成完了させる。) 、Double Buffer にしてどうするとか。。

さんざんいじくりまわした挙句、元に戻すこともできなくなり、前回の投稿のように Z80エミュレート部分のスピードアップにいそしんだというわけです。

まぁしかし、怪我の功名。Z80のスピードは3.5倍になっただけでなく、新たなアプローチで原因を探すきっかけとなり、見事解決。

結果からいうと、CPUのL1 キャッシュの問題でした。

どういうことかというと、現代のCPU は、プログラムを先読みしてキャッシュしたり分岐の予測をしりして動作スピードをアップさせているわけなんですが、その先読み部分のデータについては、画面描画プログラムは高速で随時書き換えているわけです。

ですから、CPUが先走って読み込んだあとに対象の部分をプログラムが書き換えているので、データの不整合がおきるわけですね。

その結果画面はゴミが残ったような状態になったり、文字が欠けていたりしたわけです。

そこで、VRAM書き換え直後に キャッシュクリアしたら、あっさり解決。勉強になりました。

気晴らしに、Z80エミュ部分のスピード改善に集中することにした。

Z80エミュを 10MHz まで上げたい!

最初、とりあえず動作するようになった Z80エミュですが、当初は実機を下回る。1.727MHz

エミュなのでいうなれば、内部的な構造はZ80インタプリタという感じではあるが、Cortex-A53（64-bit）@ 1GHz のマシンで 1.7MHz では、なんとも悲しいではないか。ここに画面描画 Thread が動いたら、どんだけ遅いんだってことになってしまいます。

それで、いろいろとムダ改善 ( 工場らしい単語だね ) を行いまして、スピードは徐々に改善し、3.367MHz と約2倍に。

それでも、まだまだということで、絞りまくって、なんと 6.098MHz まで到達。

とりあえずここまでくれば、一段落。

今回、どんなことをしてスピードを上げたのか。箇条書きで記します。

Z80エミュレーション スピードアップ施策（時系列）

【初期】〜 1.73MHz 程度

1. Z80の命令実行部を関数ポインタ配列で管理（Opc_mainなど）

　初期は Delphi 的なスタイルで、オペコードごとにメソッド参照で分岐。

2. Z80_RDMEM/Z80_WRMEMの抽象化

　メモリアクセスを関数化したが、処理分岐が多く遅延の原因に。可能な限りダイレクトにメモリの読み書きをするように書き換え。

3. Z80のClass化を廃止、Cライクにべた書き

　意外にこれはすごく大きく改善した。Class は便利だが、やはり動作は遅くなることがわかった。

【中期】〜 約3〜5MHz台

　4. 関数ポインタ呼び出しの高速化検討

　　Opc_main[opcode]() での呼び出しが遅いか検証。

　5. 命令デコードの分岐を単純

　　caseやif-elseの多重分岐を避け、直接ジャンプに近い構造に。

　6. 読み出し回数が多いところでのムダな関数呼び出し排除

　　関数呼び出しがネストしていっている部分がかなりムダが多かった。

【最適化フェーズ】〜 約6.06MHz 到達

　7. 変数の型のオバースペックを解消

　　なんとなく Int32 となっていたところを、厳格に Word (UInt16) にしたり、byte (Uint8) にしたら、内部的なムダなキャスト処理が減ったということで、これも大きくスピードアップに貢献

　8. メモリマップドI/Oを早期に除外

　　MZ80がメモリマップドI/Oの構造をとっているため、 $E000～$E008 のアドレスに読み書きがあったら、pio8255、pit8253 の処理と連動させなくてはいけないので、メモリに読み書きがあるたびに判定を繰り替えしていたが、初期の段階で $E000以前のアドレスだったらすぐに手続き離脱 (exit ) することで、かなり速くなった。

ということで、これからはVRAM描画の最適化に挑戦。 (今のバージョンをバックアップしておこう。。)

画面描画にメスを入れる

★ カラーを 32bitから16bit にして描画コストを半分にする。

エミュレートする対象がMZ-80Kなので、カラーが 32bit というのはかなりオーバースペックであることに気づいたので、16bitモードに変更。これに伴って、 ARGB (LongWord) で記述していたコードを RGB565 (Word) にすべて書き換え。

//==============================================================================
// 指定した X,Y (40x25) にキャラを表示  (RGB565形式バージョン)
//==============================================================================
procedure DrawCharToSurface(X, Y: Integer; CharCode: Byte);
var
  Line, Bit: Integer;
  Data: Byte;
  PixelAddr: PWord;
  BaseAddr: PtrUInt;
begin
  // 1文字目の先頭アドレス（1ピクセル=2バイト）
  BaseAddr := FBInfo.PixelAddr + Y * FBInfo.Pitch + X * 2;

  for Line := 0 to 7 do
  begin
    Data := FontRom[CharCode * 8 + Line];
    for Bit := 0 to 7 do
    begin
      PixelAddr := PWord(BaseAddr + Line * FBInfo.Pitch + Bit * 2);
      if (Data and (128 shr Bit)) <> 0 then
        PixelAddr^ := FG   // FG は Word 型（RGB565値）
      else
        PixelAddr^ := BG;  // BG も Word 型
    end;
  end;
end; 

こんな感じで、すべて Word型に。 RGB565変換は、下記のようなfunctionを作成。

//==============================================================================
// RGB565 形式に変換する関数
//==============================================================================
function RGB565(R, G, B: Byte): Word;
begin
  Result := ((R shr 3) shl 11) or ((G shr 2) shl 5) or (B shr 3);
end; 

これは、ARDUINO や ESP32 などのSBCで、外部LEDに出力するときに RGB565仕様のLEDモニタが多いので役立ちそう。あまり考えずに RGB を 255,255,255 で指定して、自動変換。

★ フレーム描画を間引き

禁断かどうかわかりませんが、フレーム描画を4回に1回だけ描画して、フレーム描画をすっとばす。

//==============================================================================
// Draw Screen Thread Execeute
//==============================================================================
procedure TDrawScreenThread.Execute;
var
  FStartVSync, FEndVSync, FVSyncTime: QWord;
  FrameCount: Integer;
begin
  FrameCount := 0;

  while not Terminated do
  begin
    FStartVSync := GetTickCount64;

    Inc(FrameCount);

    if hw80.v_gate then
    begin
      if (FrameCount mod 4 = 0) then
        update_scrn;
    end
    else
    begin
      // 描画間引きに関係なく、背景は毎回クリア
      ClearGameAreaFast16(BG);
    end;

    FEndVSync := GetTickCount64;
    FVSyncTime := FEndVSync - FStartVSync;

    if SYNCTIME > FVSyncTime then
      Sleep(SYNCTIME - FVSyncTime)
    else
      Sleep(1);
  end;
end;

update_scrn の呼び出し頻度を変えている。

★ Thread の優先順位を設定

画面描画をLOWEST にして、 Z80のThreadをHIGHEST に設定

結果は?

少し早くなったが、まだまだぜんぜん。なかなかなやましい。

画面描画処理をストップしてZ80だけ動かして計測してみた

そもそも Z80 部分は十分なスピードで動いているのか? という疑問があったので、計測用のソースに書き換えてテスト

//==============================================================================
// Z80Thread Execute
//==============================================================================
procedure TZ80Thread.Execute;
var
  i: Integer;
  T1, T2: QWord;
  Hz: Double;
begin
  // 描画がない状態で、Z80処理速度を測定
  T1 := GetTickCount64;

  for i := 1 to 1000000 do
    z80.Z80_Execute;

  T2 := GetTickCount64;

  // ミリ秒 → 秒へ変換して Hz 計算
  if (T2 > T1) then
  begin
    Hz := 1000000 / ((T2 - T1) / 1000);
    ConsoleWindowWriteLn(Console1, 'Z80: ' + FloatToStrF(Hz / 1000000, ffFixed, 5, 3) + ' MHz');
  end
  else
    ConsoleWindowWriteLn(Console1, '計測エラー');

  // スレッド終了
  Terminate;
end;  

1,000,000個の命令を処理して、何ヘルツで動いているか計測してみた。

ガーン! ショック。テスト結果は 1.727MHz。実機の 2MHz に達していないではないか!

そりゃ、描画処理も入れたら遅いわけだ。。

ボトルネックは何んなのか考える

ChatGPT に相談してみた。

そしたら、以下のような指摘が帰ってきました。(致命的!!) と言ってます。

問題点①：ExecMethod2 の文字列分岐（致命的）

ExecMethod2(op, ‘main’, opcode); // ← これが非常に遅い
文字列で分岐しています：
if kind = ‘main’ then
op.opc_main[opcode]()
else if kind = ‘cb’ then …

改善策：直接呼び出しに置き換える
op.opc_main[opcode](); // ← これで高速化（関数ポインタ直呼び）
25%以上の速度向上が見込めます。

先生了解しました。直接呼出しにしてみます。

す、すごい 倍速になりました。

やはり、Z80などのエミュレーションは、とにかく繰り返し処理なので、繰り返しの中のオーバーヘッドをなくすってことですね。

昔のマイコンプログラムを思い出す。

現代のゆるーい感じのコーディングのぬるま湯に浸かりすぎてました。反省。

まだまだ、改善できそうなので、次回に続く。

Delphi で開発したソースは、メモリからオペコード（1byte）を読み込んで、事前に用意したオペコードに対応するプロシージャ名の配列から、対象となるprocedure 名を取得して、そのprocedure名からプロシージャを呼び出すためのポインタを取得してマシン語の実行というプログラムだったのですが（ややこしいですけど効率的）、なんとベアメタルでの Free Pascal では構文でエラーは出ないものの、ポインタの値が null しか戻ってこないという大ピンチに陥っていまして、ちょいとなやんでいました。

色々と調べて、トライしてやっと求めている動きになりました。

具体的には、procedure（ ）of object 型の配列を準備して、オペコードに対応するprocedure のポインタを設定するという方法です。

TOp という class にマシン語命令を処理するprocedure がすべて入っていて、そのインスタンスをop とした時、クラス外で準備した配列に次のようにポインタを代入します。

opcode_main[$C3] := @op.jp;

Z80 ではメインとなる命令群が256個、2バイト命令が、CB, DD,ED,FD ということで、4*256個、3バイト命令で、256*2の512個、合わせて 1792 個の命令（その中には未定義の部分もありますが）なので、ポインタを利用した呼び出しをしないと、大量のif then else if をずらーっと記述しなければいけないはめになり、かつ遅いプログラムとなってしまいます。

まぁとりあえず、解決策があって良かった。

ということで、Z80の動作もレジスタの値の変化を表示して、うまくいってるようなので、VRAMの内容を画面に書き込むモードに切り替えて実行!

とりあえず、モニタプログラムが動いて、画面にSP-1002 の表示が出ました。

しかし、めちゃくちゃ遅い! これはなんとかせねば。

MZ80Kのメモリ領域全体は、8bitマシンということで、64KBとなります。

unit mem;
interface
var
  memory: array[0..65535] of Byte;
implementation
end. 

メモリ内容を保持する unit として、上記のように準備しました。

ここに、MZ-80KのモニタROM (SP-1002) を読み込んでみましょう。

//==============================================================================
// Load MONITOR ROM
//==============================================================================
procedure LoadMonitorRom;
var
  FS: TFileStream;
  MonitorPath: string;
  I: Integer;
begin
  ConsoleWindowWriteLn(Console1, 'Waiting for drive...');

  // C:\ または fat:\ が使えるのを待つ
  while not DirectoryExists('C:\') and not DirectoryExists('fat:\') do
    Sleep(100);

  if DirectoryExists('C:\') then
    MonitorPath := 'C:\mon_rom'
  else
    MonitorPath := 'fat:\mon_rom';

  ConsoleWindowWriteLn(Console1, 'Drive is ready.');

  if FileExists(MonitorPath) then
  begin
    ConsoleWindowWriteLn(Console1, 'Loading monitor ROM file...');
    FS := TFileStream.Create(MonitorPath, fmOpenRead);
    FS.Read(MonitorRom, SizeOf(MonitorRom));
    FS.Free;
    ConsoleWindowWriteLn(Console1, 'Monitor ROM loaded successfully!');
  end
  else
  begin
    ConsoleWindowWriteLn(Console1, 'Monitor ROM file not found at ' + MonitorPath);
  end;

  // 読み込んだ内容を memory[] にコピー
  for I := 0 to SizeOf(MonitorRom) - 1 do
    memory[I] := MonitorRom[I];
end;                  

メモリの先頭 $0000番地から4KBのモニタROMを読み込んでセットします。

今後、Z80のエミュレータがうまく動けば、このモニタ部分を実行して、VRAMへの初期表示もされることになります。

まだそこまでは行けないので、今回はVRAMとして割り当てられた $D000 からの1000byte の内容を画面に表示するところまでやってみましょう。

つまり画面表示部分だけ先にテストしておこうというわけです。

VRAMの内容を画面に表示する

とりあえずざっとソースプログラムを見てみましょう。

//==============================================================================
// スクリーン描画スレッド
//==============================================================================
procedure DrawScreenThread;
var
  FTimeValue : QWord;
  FTimeDis   : QWord;
  FStartVSync: QWord;
  FEndVSync  : QWord;
  FVSyncTime : QWord;
  Amin       : Integer;
  Asec       : Integer;
  DrawFreq   : Integer;
  i, j       : Integer;
begin
  // すでにスレッドが開始されていたら停止
  if Assigned(ScreenThread) then
  begin
    flgStop := True;
    ScreenThread.Terminate;
    FreeAndNil(ScreenThread);
  end;

  // スレッド開始
  flgStop := False;
  ScreenThread := TDrawScreenThread.Create(False); // False = 自動起動
  ScreenThread.FreeOnTerminate := False;
end;

//==============================================================================
// Draw Screen Thread Execeute
//==============================================================================
procedure TDrawScreenThread.Execute;
var
  FStartVSync, FEndVSync, FVSyncTime: QWord;
begin
  while not Terminated do
  begin
    FStartVSync := GetTickCount64;

    //if hw80.v_gate then
    if true then  // z80動かすまでの仮設定
    begin
      update_scrn;
    end
    else
    begin
      ClearScreenFast(BG);  // 事前定義された背景色
    end;

    FEndVSync := GetTickCount64;
    FVSyncTime := FEndVSync - FStartVSync;

    if SYNCTIME > FVSyncTime then
      Sleep(SYNCTIME - FVSyncTime);

    Sleep(1);
  end;
end;

//==============================================================================
// 画面アップデート処理  (v-blank) [書き換えが必要部分だけ画面を書き換える]
//==============================================================================
procedure update_scrn;
var
  i: Integer;
  CharCode: Byte;
  Row, Col: Integer;
begin
  for i := 0 to 999 do
  begin
    CharCode := Memory[$D000 + i];
    if ScrChar[i] <> CharCode then
    begin
      Row := i div 40;
      Col := i mod 40;
      DrawCharToSurface(Col * 8, Row * 8, CharCode);
      ScrChar[i] := CharCode;
    end;
  end;
end;

//==============================================================================
// 指定した X,Y (40x25) にキャラを表示
//==============================================================================
procedure DrawCharToSurface(X, Y: Integer; CharCode: Byte);
var
  Line, Bit: Integer;
  Px, Py: Integer;
  Data: Byte;
  Color: LongWord;
begin
  for Line := 0 to 7 do
  begin
    Data := FontRom[CharCode * 8 + Line];
    for Bit := 0 to 7 do
    begin
      Px := X + Bit;
      Py := Y + Line;

      if (Data and (1 shl (7 - Bit))) <> 0 then
        Color := FG
      else
        Color := BG;

      PutPixel(Px, Py, Color);
    end;
  end;
end;

//==============================================================================
// 点を描画
//==============================================================================
procedure PutPixel(X, Y: Integer; Color: LongWord);
var
  Offset: PtrUInt;
begin
  Offset := FBInfo.PixelAddr + Y * FBInfo.Pitch + X * 4;
  PLongWord(Pointer(Offset))^ := Color;
end;

//==============================================================================
// 画面を高速クリア
//==============================================================================
procedure ClearScreenFast(Color: LongWord);
var
  PixelPtr: PLongWord;
  Count: Integer;
begin
  PixelPtr := PLongWord(Pointer(FBInfo.PixelAddr));
  Count := (FBInfo.Pitch div 4) * FBInfo.Height;

  while Count > 0 do
  begin
    PixelPtr^ := Color;
    Inc(PixelPtr);
    Dec(Count);
  end;
end;                 

画面を一定周期で更新するThread を定義して実行します。

Thead内から、update_scrn (画面の更新処理) を呼び出します。

update_scrn では、高速化のためVRAM 上の値が前回と違う部分だけ更新するようにしています。

この中で、指定のX,Y 座標に文字を書き込む処理 DrawCharToSurface(X,Y,CharCode) を呼びだしています。

DrawCharToSurfaceでは、フォントデータに基づいてドットで画像を生成 ( PutPixel) しています。

PutPixel では、文字単位ではなくドット単位で書き込む処理が記述されています。

このように階層的に処理をしています。

ランダムな情報をVRAMに書き込む

まだ Z80が動いていないので、VRAMエリアに情報が書き込まれない状態ですので、とりあえずVRAMエリアにランダムに値を書き込みます。

procedure FillVRAMWithRandomChars;
var
  i: Integer;
begin
  Randomize;
  for i := 0 to 999 do
  begin
    Memory[$D000 + i] := Random(256);  // ランダムなキャラクターコード（0〜255）
  end;
end;   

これで、元データはできあ゛かりますので、テストしてみましょう。

それと、プログラムがちゃんと動作していることを確かめるため、MZ700風に背景を青にして描画するようにしてみましょう。

うまく行きました。

Z80部分もコンパイルできるところまでは修正したのですが、まだうまく動いていないので、とりあえず今日はVRAMの表示をスレッドでできたというところまで。

今回は、Z80の実装とMZ80のハードウェア定義もすべてソースに含まれていますが、まだZ80の実装部分のテストができていないので、動作からは外しています。

しかし、Z80部分のDEBUGをどうやってやろうかな。今の開発のやり方だと、まともにデバッグできないので、Raspi の エミュレータを開発環境に絡めてやるしかないんだろうな。。また開発環境の設定を触るしかないね。