キーボードの実装に当たっては、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 のメモリに対して読み書きがあったら、上記処理をすれば良い。

気晴らしに、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 の エミュレータを開発環境に絡めてやるしかないんだろうな。。また開発環境の設定を触るしかないね。

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キーボードのテストをしていなかった。こちらが先かな。

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

当時は、Delphi 10.4.1 で開発したのですが、今は Delphi 12.3 ( 2025/5/31現在 ) になっているので、少し手直し。

そういえば Delphi 12.3 は Skia4Delphi が標準で組み込まれたという話だったねということで、少し調べて画面描画部分を全体的に Skia に対応させて、描画速度の向上を図りました。

少し躓いたのは、少し前のバージョンでは Skia4Delphi のプラグインをインストールしたのですが、Delphi 12.3 では標準で組み込まれているというところ。uses に追加するライブラリ名が違うので、ややこしい。

上記が正しい宣言ですが、前のバージョンでは、 SKia.FMX だったりしますし、ライブラリの構成も結構違うということで、少し迷子になりつつ、なんとか Skia 対応しました。

画面右の レジスタ内容の LED表示も Skia で高速描画する方法にしました。以前は大量に TImage を配置して visible を true / false して切り替えていました。visible の切り替えで簡単だろうと安易に考えていたのですが、内部的には画面の重ね合わせ処理などの書き換えが大量に発生していたんですね。メモリの処理もお任せで大丈夫だろうと思っていたのですが、何時間も放っておくとメモリリークが大量に発生した結果エラーになるという感じでした。昔のマイコンが熱暴走しているみたいでリアルだねとか、呑気に考えていたのですが、それじゃダメだねと思い直して、Skia で直接描画に切り替えた次第です。

ついでに、VRAM のメモリに変化があった部分だけ描画を書き換えるというプログラムに書き直しまして、少し高速化を図りました。実際どのくらい高速化したかは不明ですが、性能が悪いPCでテストすればかなり違うでしょう。

まずはPC8001のエミュレータを準備

PC-8001 は人気機種だけあって、エミュレータは多数存在します。それぞれ好みはあると思いますが、私は XM8 というエミュレータを利用しています。これはPC-8801MAのエミュレータなのですが、Nモードもありますので大丈夫です。

下記よりダウンロードできます。

http://retropc.net/pi/xm8/index.html

専用エディタの準備 (BASIC打ちこみ用)

いわゆるテキストエディタなのですが、当時のマイコンのASCIIコードは各社独自で、キャラ文字も独自に設定されていますので、これに対応しないといけません。

下記より N-FONT をダウンロード (OUT of STANDARD さんのページ )させていただいて、

http://upd780c1.g1.xrea.com/pc-8001/index.html

エディタは、DumpListEditor 一択でしょう。エディタだけでなく、エミュ用のファイル出力なども統合されています。
正直これがないと、どうにもなりません。2025年現在もアップデートされ続けています。
https://bugfire2009.ojaru.jp/download.html#dleditor

使い方はこっちのページで。

/DumpListEditor の使い方 (PC-8001編)

アセンブラ用エディタ

これは何でもよいのですが、私は秀丸でやってます。色の設定などは 内藤氏の設定をまねてます。

この設定については、内藤氏が下記ページで説明されています。
https://codeknowledge.livedoor.blog/archives/14714379.html

それで、最後に、『えーい面倒だ、これを食らえ!』となっていまして、私はこれをくらって設定しました。(笑)

Z80コンパイラ

選択肢は数個ありますが、伝説のプログラマ 内藤氏 (ハイドライドなど開発された方) のおすすめが、AILZ80ASM ということで、それに倣って私も利用しています。

https://github.com/AILight/AILZ80ASM

画面デザインツール

上述の内藤氏作の 『IORI for PC-8001』をぜひ使っていただきたい。昔風に紙に書いてもいいのですが、PC-8001だとカラー画面を想定すると、カラー表示における制限事項がありますので、その辺のチェックもしてくれるこのツールはとても良いです。
これもダウンロードは、上記の DumpListEditor のダウンロードと同じ場所からお願いします。

下のスクリーンショットは、私が今回開発した OBSIDIAN のプレイ画面のデザインをしながら、1行の色数制限に引っ掛からないようにチェックした様子です。

ちなみにですが私が独自にEXCELで作成して、開発時に使っているファイルもアップしておきます。

マシン語でプログラムする際にVRAMのアドレスを直接指定したいケースが多々あります。またカラーモードにするとBASICですと画面左の1列が書き込みできなくなり、WIDTH 40,25 としても実際は 39×25 になってしまいます。理由は不明。仕様です (笑)。ですがマシン語ではVRAMに直接書き込めます。ますます理由が不明。

環境設定の次は実際のアセンブルから実行まで

環境がなんとか整いましたら、次はコードを書いて、アセンブラでアセンブルして読込可能なファイルを書き出して、エミュで実行となります。ここはかなりキモになります。これがスムーズにできないとデバッグで気持ちが折れちゃいますので。。

今回は、環境整備編 ということでここまで。あまり親切に書いていないので、もしご要望があれば連絡ください。追記します。

1979年に発表されたNECのPC-8001。当時はまだパソコンという言葉がなく、マイコンと呼んでいました。

最近では、マイコンと言えば、RaspberryPi や Arduino、ESP32 などの SBC (Single Board Computer)を意味しますね。

懐古主義? と思われがちですが。。

私の場合は、個人的な思い入れが非常に強いということもありますが、IoTシステムを構築する上で、コンピュータの根本を知るといことが重要になってきます。組み込み開発の分野では当たり前のことですが、一般的な業務システム開発、Webシステム開発の技術者が工場IoTとリンクするときにコンピュータとは何かというところを理解していないと問題が生じてしまいます。

ということで今更ながらPC-8001用のゲームを作ってウォーミングアップ

まだ発表するには時期尚早ですが、途中のものの一部をアップします。

タイトル画面。PC-8001 では、2×4ドット毎に1色しか指定することができません。160×100ドットという低解像度ですが、うまく作成すれば、なんとなく味のあるデザインになます!

当時、よくあったストーリーを表示する画面。Ultima II をイメージして作成してみました。

キャラクターの初期パラメータを乱数で設定。キーを押してストップさせてそれぞれの値を決めていきます。昔の光栄の初期の「信長の野望」「三国志」がこんな感じのキャラ設定でした。多分。当時プログラムがBASICで書かれていたので、ここを最大値になるように改造してチートしてました。。

フルグラフィックにしようかと思いましたが、ちょっとマシン語で書く時間もないので、BASICでもある程度スピードがでるようにキャラ文字オンリーでマップ表示。

N-BASIC 小ネタ

N-BASIC でゲームプログラムをする際のちょっとしたテクニックについて、おさらいします。(いまさらだれが必要としているのか不明ですが。。)

ファンクションキーを設定する

よく利用するコマンドをファンクションキーに割り当てることで、プログラム作成時の時間の節約になります。

KEY1,"WIDTH 80,25"+CHR$(13)
KEY2,CHR$(12)
KEY3,"CONSOLE 0,25,1,1"+CHR$(13)

リアルタイムなキー入力は INP(n) を利用する

キー入力には INKEY$ という命令もありますが、これはキークリックされたかどうか評価するものです。上記画面のパラメータを設定するような場合や、質問にY/N でこたえるような UI の場合は良いですが、ゲームのキャラクタを動かすときなどは、キーを押しっぱなしたときは連続してキャラクタが動いてほしい場面が多いかと思います。
その際は、INP(n) で対象のキーの状態 (押下しているかどうか)を取得することができます。

()はテンキー側のキーボードを示しています。
何も押されていないときは255となります。
一般的な利用方法 (Zキーが押されていることを確認するとき)

IF INP(5)=251 THEN ....

ゲームの時はコード量を減らす技として、論理演算を利用することが多いです。
例えば [4]で左、[6]で右にキャラクタを移動させるときに、移動量を論理式を使ってシンプルに記述することができます。

I=INP(0):X=X+(I=191)-(I=239)

それと、実は同じボードで同時に押されているキーも検出できます。上記の例では、 251や191などと書いていますがポートの1byte の8つのビットが0か1になっているだけです。
何も押されていなければ、11111111B で255となっているだけです。例えば ポート0 で、テンキーの1が押されていたら11111110B、2が押されていたら 11111101B、同時に押されていたら、 11111100B となるだけのことです。これを10進数表記して条件に入れているだけです。

INSTR で何種類かの入力を受け付けるようにする

例えば、ゲームなどで Y,y,ﾝ,SPACE,RETURN で入力を待つようなときに、キーのモード (大文字、小文字、カナ)を気にしないで対応させる小ネタです。
すなおに記述すると

K$=INPUT$(1):PRINT K$;
IF K$="Y" OR K$="y" OR K$="ﾝ" OR K$=" " OR K$=CHR$(13) THEN.....

となりますが、INSTR$ をうまく使うとすっきり書けます。

K$=INPUT$(1):PRINT K$;
IF INSTR("Yyﾝ "+CHR$(13),K$) <> 0 THEN ....

タイトル画像の作成について

160×100 の低解像度画像とは言っても、手作業だとかなりだるいので、これは現代の力を借りました。

最初に 160 x 100 の画像を PhotoShop で作成。これをコントラストを上げて、さらに減色。これである程度の画像ができあがります。
2×4 ドット毎に1色しか色付けができないこと、1行では20回までしか色を変化されることができないという点を考慮してデザインすることも重要です。PNGで保存。
このあとは、Delphi で作成したツールで画像を読み込んで、16進数に変換して、CSVで書き出しました。
さすが文明の利器! らくちんでした。

まだまだ制作途中です

まだコーディング半ばなので、発表するまでに至りませんが、夜や週末にぼちぼち進めていきます。

MZ-80のエミュレーターも同時に作っているので、中々進まないです。。

何がしたいのか?

何がしたくて、過去のテクノロジーのおさらいをしているのかと申しますと、RaspberyPi などで、LinuxなどのOSなしで直接動かす、いわゆる Bare Metal で超高速なIoT機器を作りたいのです。 Arm系のマシン語をやったことがないので、Z80, 6809, 6502, 8086 でウォーミングアップして助走をつけているのです。。(笑)