キーボードの実装に当たっては、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 の エミュレータを開発環境に絡めてやるしかないんだろうな。。また開発環境の設定を触るしかないね。

ファイルの読み込みの準備

ファイルをmicroSDから読み込む想定で考えていきます。

調べたところ、uses には色々と追加しなければならない。

uses
  RaspberryPi3, // ← ここが機種名
  GlobalConst, GlobalTypes,
  Platform, Console, SysUtils,
  Framebuffer,   // HDMI出力のある場合
  BCM2837,       // SoC定義（Zero2Wならこちら）
  Classes,       // TFileStreamやTStringList用
  FileSystem,    // コアファイルシステム
  FATFS,         // FATファイルシステム
  MMC,           // SDカードアクセスの中核
  BCM2710,       // Raspberry Pi向けMMC実装
  BCMSDHOST;     // SD Hostドライバ    

この後、画面出力もあるので、 Framebuffer も一緒に追加しますが、なんか色々と追加。参考資料がないとお手上げですね。

ファイル読み込み

Raspiでは、C:ドライブが規定のドライブになるらしい。またドライブの準備ができるまでは、C: が見つからないのでエラーになってしまうから、C:の読み込み準備ができるまで待つ。ベアメタルの場合はいきなり起動するので、こういった処理も必要なんですね。

procedure LoadFontRom;
var
  FS: TFileStream;
begin
  ConsoleWindowWriteLn(Console1, 'Waiting for C:\ drive...');
  while not DirectoryExists('C:\') do Sleep(100);
  ConsoleWindowWriteLn(Console1, 'C:\ is ready.');

  if FileExists('C:\cg_rom') then
  begin
    ConsoleWindowWriteLn(Console1, 'Loading font file...');
    FS := TFileStream.Create('C:\cg_rom', fmOpenRead);
    FS.Read(FontRom, SizeOf(FontRom));
    FS.Free;
    ConsoleWindowWriteLn(Console1, 'Font loaded successfully!');
  end
  else
  begin
    ConsoleWindowWriteLn(Console1, 'Font file not found.');
  end;
end;  

今回は、Dlephi で開発した MZ-80K エミュの時に作成したフォントデータファイル [cg_rom] をそのまま使うことにする。

ちなみにフォントデータ用に配列を次のように定義している。

FontRom: array [0..2047] of Byte;       // キャラクタフォントデータ 

こちらご自由にお使いください。

フォントを画面に書き込む

フォントを 16 × 16 で順番に並べ画面に書き込む。

procedure DrawFontGridFromProperties;
var
  FB: PFramebufferDevice;
  Props: TFramebufferProperties;
  BaseAddr: PtrUInt;
  ch, cx, cy, x, y, bit: Integer;
  PixelAddr: PLongWord;
begin
  FB := FramebufferDeviceGetDefault;
  FramebufferDeviceGetProperties(FB, @Props);

  // 画面クリア（黒）
  for y := 0 to Props.VirtualHeight - 1 do
    for x := 0 to Props.VirtualWidth - 1 do
    begin
      PixelAddr := PLongWord(Props.Address + y * Props.Pitch + x * 4);
      PixelAddr^ := COLOR_BLACK;
    end;

  // フォント描画（8x8）
  for ch := 0 to 255 do
  begin
    cx := ch mod 16;
    cy := ch div 16;

    for y := 0 to 7 do
      for bit := 0 to 7 do
        if (FontRom[ch * 8 + y] and (128 shr bit)) <> 0 then
        begin
          x := cx * 8 + bit;
          PixelAddr := PLongWord(Props.Address + (cy * 8 + y) * Props.Pitch + x * 4);
          PixelAddr^ := COLOR_WHITE;
        end;
  end;
end;    

コンパイルして実行

先ほどの [cg_rom] をmicroSDのルートにコピーして、コンパイル済の kernel7.img もコピーして、実機を起動。

表示されたが、なにやら緑の線がいっぱい。でもしばらく放っておいたら落ち着いたのか、ちゃんと表示されました。

準備が整うまで、少し待つというのが基本なのかな? ベアメタル。
ところで、このキャラクタの並びですがこれはディプレイコードというものです。MZ-80Kは、キャラクターコード (ASCIIコードみたいなもの) とディスプレイコードというのが別になっていて、プログラム中で扱う文字としてはキャラクターコードなのですが、VRAMに表示するときは、このディスプレイコードに基づいて表示されるのです。私も長年不思議におもっていましたし、小学生の時は意味が分かりませんでした。

エミュレータをつくる際に、マシンの回路図を見ていて思ったのが、当時はこの方式が回路をシンプルにするのに都合がよかったのでしょうね。上から、4段ずつみていくと、キーボードと対応しています。SHIFT + A で クローバーが表示されますし、カナモードにしてAキーを押すと「チ」が表示されます。そしてカナ文字の部分は海外バージョンでは、小文字や面白い記号が割り当てられています。キーを押したときにCGROMから読み出すのが簡単だったのでしょうね。またそれをディスプレイに展開するのも単純になったのだと思います。

下は、手持ちのMZ-80K2のメイン基板です。右中央で水色のコンデンサの左上にあるのが CPU (Z80) で、Z80の左に少し行くと、大きなIC がありますが、これが CG-ROM です。このROMを差し替えると、表示される文字が変わります。

あれ、CG-ROMの右側の掃除ができていなかった。

プロジェクトソース全体

program hellopi;

uses
  RaspberryPi3, // ← ここが機種名
  GlobalConst, GlobalTypes,
  Platform, Console, SysUtils,
  Framebuffer,   // HDMI出力のある場合
  BCM2837,       // SoC定義（Zero2Wならこちら）
  Classes,       // TFileStreamやTStringList用
  FileSystem,    // コアファイルシステム
  FATFS,         // FATファイルシステム
  MMC,           // SDカードアクセスの中核
  BCM2710,       // Raspberry Pi向けMMC実装
  BCMSDHOST;     // SD Hostドライバ


var
  Console1: TWindowHandle;
  FontRom: array [0..2047] of Byte;       // キャラクタフォントデータ

procedure InitFramebuffer320x200;
var
  FB: PFramebufferDevice;
  Props: TFramebufferProperties;
begin
  FB := FramebufferDeviceGetDefault;

  FillChar(Props, SizeOf(Props), 0);
  Props.PhysicalWidth := 320;
  Props.PhysicalHeight := 200;
  Props.VirtualWidth := 320;
  Props.VirtualHeight := 200;
  Props.Depth := 32;  // 32bit（ARGB）

  FramebufferDeviceSetProperties(FB, @Props);
end;

procedure LoadFontRom;
var
  FS: TFileStream;
begin
  ConsoleWindowWriteLn(Console1, 'Waiting for C:\ drive...');
  while not DirectoryExists('C:\') do Sleep(100);
  ConsoleWindowWriteLn(Console1, 'C:\ is ready.');

  if FileExists('C:\cg_rom') then
  begin
    ConsoleWindowWriteLn(Console1, 'Loading font file...');
    FS := TFileStream.Create('C:\cg_rom', fmOpenRead);
    FS.Read(FontRom, SizeOf(FontRom));
    FS.Free;
    ConsoleWindowWriteLn(Console1, 'Font loaded successfully!');
  end
  else
  begin
    ConsoleWindowWriteLn(Console1, 'Font file not found.');
  end;
end;

procedure DrawFontGridFromProperties;
var
  FB: PFramebufferDevice;
  Props: TFramebufferProperties;
  BaseAddr: PtrUInt;
  ch, cx, cy, x, y, bit: Integer;
  PixelAddr: PLongWord;
begin
  FB := FramebufferDeviceGetDefault;
  FramebufferDeviceGetProperties(FB, @Props);

  // 画面クリア（黒）
  for y := 0 to Props.VirtualHeight - 1 do
    for x := 0 to Props.VirtualWidth - 1 do
    begin
      PixelAddr := PLongWord(Props.Address + y * Props.Pitch + x * 4);
      PixelAddr^ := COLOR_BLACK;
    end;

  // フォント描画（8x8）
  for ch := 0 to 255 do
  begin
    cx := ch mod 16;
    cy := ch div 16;

    for y := 0 to 7 do
      for bit := 0 to 7 do
        if (FontRom[ch * 8 + y] and (128 shr bit)) <> 0 then
        begin
          x := cx * 8 + bit;
          PixelAddr := PLongWord(Props.Address + (cy * 8 + y) * Props.Pitch + x * 4);
          PixelAddr^ := COLOR_WHITE;
        end;
  end;
end;

begin
  Console1 := ConsoleWindowCreate(ConsoleDeviceGetDefault, 0, True);

  if Console1 <> -1 then
  begin
    ConsoleWindowWriteLn(Console1, 'Hello from Ultibo on Pi Zero 2 W!');
  end;

  InitFramebuffer320x200;
  LoadFontRom;
  DrawFontGridFromProperties;
  while True do Sleep(1000);
end.

プロジェクトファイル一式

まとめ

FrameBuffer への直接書き込みとファイルの読み込みテストができましたので、これで一気に目処が立ちましたね。

私は、新たな環境で開発を行う際に、まず文字の入出力、画面描画、キー入力、文字列の処理、データベースの読み書きなどのあたりを付けます。これらがうまく行けば、手足と羽がついたようなもので、あとは気兼ねなくプログラミングということになります。

プログラムの基本は、代入、条件分岐、繰り返し。これしかないんです。

Ultibo Core のダウンロード

Lazarus IDE と統合された Ultibo は下記よりダウンロードします。

/https://ultibo.org/download/

2025/6/6 時点では、Ultibo-Core-2.6.049-Beetroot.exe が最新ですので、これをダウンロード。

もしくは、GitHub からもダウンロードできます。必要に応じて古いバージョンのダウンロードもできます。

こちらだと、少しサイズの大きい Ultibo-Core-2.6.049-Beetroot-Main.exe というのもあります。

私は、何か不足してもいやなので、こちらからダウンロードしました。

インストール

ダウンロードしたファイルを実行するとインストールが始まります。インストールディレクトリの指定などもできますが、とりあえずデフォルトのまま次へ次へと進みインストール。数分でインストールが完了します。

インストールが完了すると、C:\Ultibo\Core というフォルダができています。

C:\Ultibo\Core の下にこんなフォルダとファイルができていればとりあえずインストール成功かと思います。

Lazarus (Ultibo Edition) を起動

Lazarus IDE (Ultibo Edition) を起動します。

初回の起動はFPC (free pascal ) のパスなどを設定する画面が表示されますが、デフォルトで設定されているので、開発環境のWindow のモードを選択するだけで良いでしょう。Windowモードは、Classic だと 昔風にそれぞれのウィンドが独立している形になっていて、今風だと、最近のDelphi風に1つのWindowにメニュー、プロジェクトインスペクタ、ソースエディタ、コードエクスプローラなどがドッキングされた感じになります。特に深い思い入れがなければ、今風のほうが良いでしょう。

これは今風の場合。

プロジェクトの作成

メニューの[ファイル]→[新規] で下の画面が開きます。

今回は、Raspi Zero 2W をターゲットにしますので、これを選んで[OK] ボタンでプロジェクトが作成されます。

プロジェクトオプションの設定

[プロジェクト] → [プロジェクトオプション] で下の画面が開きます。

[コンパイラオプション] → [設定と対象] で、対称プラットフォームは、上記画面のように設定してください。

ARMV7A 、RPIZERO2W がポイントです。設定したら[OK]ボタンで画面を閉じます。

Hello world サンプルプログラムの作成

program HelloPi;

uses
  RaspberryPi3, // ← ここが機種名
  GlobalConst, GlobalTypes,
  Platform, Console, SysUtils;

var
  Console1: TWindowHandle;

begin
  Console1 := ConsoleWindowCreate(ConsoleDeviceGetDefault, 0, True);

  if Console1 <> -1 then
  begin
    ConsoleWindowWriteLn(Console1, 'Hello from Ultibo on Pi Zero 2 W!');
  end;

  while True do Sleep(1000);
end.

最初は何も考えずに、初期表示されているソースを消して、上記コードをペタッと貼り付けましょう!

プロジェクトの保存

まず最初にソースを保存してみましょうか。

Pascal は、ソースの先頭に書いた名前とファイル名が一致しないといけないので、 program hellopi; としたので、ファイルに名前を付けて保存で、 hellopi.lpr として保存してください。

とりあえず今は、このファイルしかないので、メニューの [プロジェクト] → [名前を付けてプロジェクト保存] で保存しても同じ結果かなと思います。

Pascal はこの他 unit というファイルもありまして、この後開発していく中で unit に分けて、uses で宣言して使うことになると思います。

構築 (コンパイル + img出力)

さていよいよ、コンパイルです。

[構築] でコンパイルと Raspi 用の img ファイルができあがります。

こんな風に表示されたら、コンパイルは成功です。

出力先のフォルダ内をみてみましょう。

このように出力されていれば成功かと思います。

SDカードに書き込む

先ほど生成された kernel7.img がこのプログラムの本体です。まずはこれをSDカードにコピーしましょう。

次に、 C:\Ultibo\Core\firmware\RPi3 のフォルダにある下の3つのファイルをSDカードにコピーします。

結果、SDカードの中身は、下のようになります。

Raspi Zero に差して実行!

micro SD-CARD を Raspi に差して、HDMIケーブルとモニタを繋いで、電源コードを差し込めば、すぐに起動します。

さすがに、OS無しは起動が速い!

とりあえず、起動までできたので、次からはさっそくDelphi で書いた MZ-80K2 のエミュを移植したいと思います。

うん? まてよ。まだUSBキーボードのテストをしていなかった。こちらが先かな。

ということで、今回はここまで。