mieki256's diary

_NVIDIA ドライバの更新方法 - エムエスアイコンピュータージャパン

ノートPC用の情報で、2019/03/22 に書かれたページだけど。標準版をインストールできない時はDCH版を試してみてくれ、と書いてあった。

自分が使っているビデオカードは、MSI製なので、MSIのこの情報に該当する製品なのだろう…。

_New (RTX) NVIDIA "Standard" or DCH" (Declarative, Componentized, Hardware Support Apps) - EVGA Forums

DCH = Declarative, Componentized, Hardware Support Apps、らしい。何が何だかわからないけど、そういう略なのだな。

初期不良が怖いので、一応チェックをした。親父さん用PCにUSB3.0で接続して、 _EaseUS Partition Master Free 版 を使ってサーフェイステストを行った。20:00頃から始めて、03:00頃に終わった。

自分は結果画面を見ていないけれど、親父さんが確認したところ、グラフは全部青だか緑だかで、不良セクタは0だった、とのこと。

コメント欄で、「ソフト名にリンクを張ってほしい」と連絡があったのでリンクを追加しておきました。

Windows10 x64 上に MinGW をインストールしてある環境なので、gcc を使って各サンプルをコンパイルして動作確認。

gcc hello.c -o hello

これで hello.exe が出来上がった。

python pymztinfo.py MZT_FILE

or

pymztinfo.exe MZT_FILE

> pymztinfo.exe S-BASIC_1Z007B.MZT
Input file : S-BASIC_1Z007B.MZT
0x00     : File mode = 0x01 (Binary)
0x01-0x11: Filename  =  S-BASIC
0x12-0x13: File size    = 0x6C80 (27776)
0x14-0x15: Load Address = 0x1200
0x16-0x17: Exec Address = 0x7E0F
0x18-0x3F: 11 30 11 CD 09 00 CD 15
           00 00 00 00 00 00 00 00
           00 00 00 00 00 00 00 00
           00 00 00 00 00 00 00 00
           00 00 00 00 00 00 00 00
0x40-0x43: Patch Enable
Adrs=0x1221 , Size=0x0C (12) , Data (Hex)=ED F4 03 ED F4 04 ED F4 01 ED F4 02
body length: 0x6C80 (27776)

あちこちのページを眺めて把握した範囲で、一応、MZTファイルのフォーマット仕様をメモ。

• 0x00 - 0x7F : ヘッダ部分。
• 0x80 - : 実データ

ヘッダ部分の内容は以下。

0x00	ファイルの種類。アトリビュート。
0x01 - 0x11	ファイル名。0x0Dが終端文字。残りは0x20 でパディングされる。
0x12 - 0x13	実データのサイズ
0x14 - 0x15	ロード・格納アドレス
0x16 - 0x17	実行開始アドレス
0x18 - 0x3F	謎データ。FD使用時に絡んだデータが入ってるらしい？
0x40 - 0x43	ファイルにパッチを当てる場合、'PAT:' が入ってる。
0x44 - 0x7F	パッチデータ
0x80 -	実データ

ファイルの種類については、どうやら以下が決まってるように見えた。

0x01	バイナリ
0x02	BASICのプログラム。SP-5030 / Hu-BASIC等
0x05	BASICのプログラム。MZ-700 S-BASIC
0xC8	CMU-800用のデータ

パッチデータ1つ分のフォーマットは以下。

2 byte	パッチを当てるアドレス値。0xFFFFが入ってたらパッチデータは終了。
1 byet	パッチのサイズ
N byte	サイズ分、パッチデータが並ぶ。

パッチの個数分、このデータ列が並ぶ。アドレス値に 0xFFFF が入っていたら、そこでパッチは終了。

_MZ のテープを活用しよう - アルゴの記憶 (Internet Archive)
_MZ700WIN FAQ (Internet Archive)
_ReadMe.TXT - MZF-Studio

0x18 - 0x3F に入ってるデータの意味が分からない。.mztファイルを作成するツールに、各BASIC用のヘッダファイルが同梱されていたりするのだけれど、中を覗くと、該当部分には、たしかに何かが入ってる。しかし、どういう意味のデータが入っているのか、記述したページが見つからず。

ファイルの種類(アトリビュート)に入ってる、0x02 と 0x05 の使い分けが、ちょっと自信がない。手元の .mzt をいくつか確認した感じでは、SP-5030 / Hu-BASIC用のプログラムには 0x02 が、MZ-700用S-BASIC用のプログラムには 0x05 が入っていたけれど、本当にその分類でいいのだろうか…？

テープのイメージファイルとしては、.mzt 以外にも .mzf というファイルが存在するのだけれど。.mzf は、先頭に 'mz20' の文字列が入ってるという情報を見かけたものの、Web上で公開されていた各種 .mzf を入手して中を覗いてみたところ、そういう文字列が入ってるファイルは見当たらなかった。拡張子が .mzf でも、フォーマットが異なるものが存在している、ということだろうか…。

公式サイトのリンクを辿って、sourceforge から、z88dk-win32-1.99C.zip を入手。

_z88dk
_Z88 Development Kit - Browse Files at SourceForge.net
_Nightly CVS snapshots and win32 builds of z88dk

一般的には Nightly builds 版、z88dk-win32-latest.zip を入手して使う場合が多いらしいけど…。今回は、バージョンがついてる版を選択してみた。

解凍して、任意のフォルダに置く。

環境変数を設定。

• PATH に、z88dkインストールフォルダ\bin、を追加。
• 環境変数 Z80_OZFILES を新規作成して、z88dkインストールフォルダ\lib、を指定。
• 環境変数 ZCCCFG を新規作成して、z88dkインストールフォルダ\lib\Config、を指定。

以下の解説ページが参考になった。ありがたや。

_MSX用クロス開発のすすめ（z88dk） - 仮想と現実

C言語のソースを書いて、コンパイル。例えば、hello.c をコンパイルして、MZ-80K/700用のバイナリを作るなら、以下の指定になる。

zcc +mz -lm -o hello -create-app hello.c

• +mz : MZ-80K/700用をターゲットにする。
• -lm : 謎。
• -o xxxxx : 出力ファイル名
• -create-app : アプリ作成

この指定で、いきなり .mzt が出力される。

_Platform Sharp MZ - z88dk/z88dk Wiki
_platform:sharpmz [z88dk]

しかし、-lm の意味が分からない…。zcc --help をしてみたけど…。-l -m を指定してるということなのかな…。

※ 2019/05/08追記。-lm オプションは、「Link in the generic Z80 maths library」だそうで。数学ライブラリをリンクしてくれるのだろう。たぶん。

_Tool zcc - z88dk/z88dk Wiki

Hello World はコンパイルできたし、動いてくれた。

#include <stdio.h>

int main(void) {
  printf("\n-- HELLO WORLD --\n");
}

しかし、 _先日 SDCC で試したソース は、コンパイルはできたけど動かない。画面が真っ暗なまま。ただ、何故か、unsigned char のポインタを char のポインタにすると動く。

#include <stdio.h>

#define DISPADRS 0xd000
#define ATTRADRS 0xd800

int main(void)
{
  for (int c = 0; c <= 255; c++)
  {
    char d = c;
    for (int y = 0; y < 25; y++)
    {
      int x = 30;
      char *p;
      char *q;
      p = (void *)(DISPADRS + y * 40 + x);
      q = (void *)(ATTRADRS + y * 40 + x);
      while (x < 40)
      {
        *p++ = d;    // display code
        *q++ = 0x40; // attrib
        x++;
      }
      d++;
    }
  }
  return 0;
}

/*
int init(void)
{
  return 0;
}
*/

Nightly builds版の z88dk-win32-latest.zip を入手して使ってみたところ、unsigned char のポインタを記述しても動くようになった。1.99c 版はそのあたりにバグがあった、ということだろうか…。

#include <stdio.h>

#define DISPADRS 0xd000
#define ATTRADRS 0xd800

int main(void)
{
  for (int c = 0; c <= 255; c++)
  {
    unsigned char d = c;
    for (int y = 0; y < 25; y++)
    {
      int x = 30;
      unsigned char *p;
      unsigned char *q;
      p = (unsigned char *)(DISPADRS + y * 40 + x);
      q = (unsigned char *)(ATTRADRS + y * 40 + x);
      while (x < 40)
      {
        *p++ = d;    // display code
        *q++ = 0x40; // attrib
        x++;
      }
      d++;
    }
  }
  return 0;
}

/*
int init(void)
{
  return 0;
}
*/

_MSX用クロス開発のすすめ(z88dk) - 仮想と現実
_z88dkによるクロスビルド - GitBook
_Z80 Development Tools
_MSX(Z80)のセルフコンパイラ
_MSX(Z80)のC言語コンパイラ

ググったところ、以下の CP/Mエミュレータを見かけた。

_CP/M Player for Win32 謎WIPページ
_CP/M program EXEcutor for Win32の詳細情報 : Vector

どちらも、解凍すると cpm.exe という実行ファイルが入っている。以下のように打つと、CP/M用のプログラムを動かせる模様。

cpm.exe CP/M_APPLI_FILE

とりあえず、今回は…。

• CP/M Player for Win32 は、Windows 2000/XP/Vista/7 Console版を使用。
• CP/M program EXEcutor for Win32 は、cpm32_04.zip、2012.04.30版を使用。
• 動作確認には、CP/M用の Microsoft BASIC を使用。

Microsoft BASIC の動かし方については、以下が参考になった。ありがたや。

_CP/Mに夢中♪

Microsoft BASIC は、以下から入手。Mbasic.com というのがソレらしい。

_CP/M Programming Languages and Tools

動かしてみる。

cpm Mbasic.com

CP/M Player、CP/M program EXEcutor、どちらでも同じように動作した。

Microsoft BASIC を終了するときは、system と打てばいいらしい。

YAZE-AG という CP/Mエミュレータも試したり。今現在の最新版は、2.40.5、なのかな。たぶん。

_YAZE-AG - Yet Another Z80 Emulator by AG (V 2.40.5 / V 2.30.3)
_YAZE-AG - Yet Another Z80 Emulator by AG V 2.40.5 / V 2.30.3 (Windows binaries)
_ソフトウェアー基礎コース (Tiny BASIC Lesson 1:Z80 エミュレーター YAZE)
_ソフトウェアー基礎コース (Tiny BASIC Lesson 2: CP/M によるコンパイル・アセンブル)
_CP/M - tanamの日記

Windowsの場合、各環境に合わせてヨサゲな版を入手すればいいらしい。自分のPCは、CPU が Core i5-2500 なので、今回は以下を入手。

yaze-ag-2.40.5_windowsbinaries_with_keytranslation_x86_64Bit_intel_core2duo_i3_i5.exe

昔は Cygwin のインストールが必要だったらしいけど、今現在の版は cygwin1.dll その他が同梱されているので、上記のファイルだけDLしてインストールすれば動く模様。

デスクトップに YAZE-AG-2.40.5 というショートカットファイルができるのでクリック。ウインドウ (mintty) が開いて起動する。デフォルトでは、起動直後に色々メッセージを表示するので、何かのキーを叩いて先に進んでいくとそのうち入力待ちになる。

とりあえず、ここでも Microsoft BASIC を動かしてみる。インストールフォルダ\bin\disksort\ が、CP/M上のCドライブ扱いになってるらしいので…。Windows上で Mbasic.com を該当フォルダにコピー。カレントドライブを C: にしてから、Mbasic.com を実行。

C:
Mbasic

動いてくれた。

Microsoft BASIC の終了は、system と入力。YAZE-AG の終了は、sys と打ってから quit。

標準では CP/M 3.1 が動くらしいけど、各種開発をしたい場合は、CP/M 2.2 を使ったほうがいいらしいので…。YAZA-AG のショートカットファイルをコピーして、プロパティを開いて、リンク先を以下のような記述にすれば CP/M 2.2 が動くようになる。のかな。たぶん。

インストールフォルダ\bin\mintty.exe --config .\.minttyrc --exec .\yaze_bin.exe -l -1 -b yaze.boot

要は、yaze_bin.exe の後ろに、「-l -1 -b yaze.boot」を追加するのだと思う。おそらく。たぶん。

以下から、altairz80.zip と cpm2.zip を入手。

_Altair Introduction

解凍して、任意のディレクトリに両方を移動。

• altairz80.zip : Altair 8800 のエミュレータ
• cpm2.zip : CP/M 2.2 のバイナリが入ったディスクイメージ群

1. 先ほど作成したディレクトリをカレントディレクトリにしてDOS窓を起動。
2. altairz80.exe を実行。sim> が表示されてコマンド待ちになる。
3. do cpm2 と打つと、CP/M 2.2 が起動する。

もしくは、altairz80.exe cpm2 で、いきなり CP/M を起動できるらしい。

do cpm2 で起動した直後は、以下のようなドライブ構成になっている。

• A: cpm2.dsk (FD)
• B: app.dsk (FD)
• I: i.dsk (HDD)
• J: appleiicpm.dsk (HDD)

A - H が FDD、I と J が HDDらしい。

• dir で、ファイル一覧を表示。
• CP/M起動中に Ctrl + E で中断。シミュレータのコマンド待ちに移行。
• go で中断状態から再開。
• halt で、CP/Mを終了。シミュレータのコマンド待ちに戻る。
• quit で、シミュレータを終了。

ということで、起動することが確認できた。

Aドライブに、Microsoft BASIC も入ってた。CP/M上で、mbasic と打てば起動する。

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo reboot
sudo do-release-upgrade

他のPCからsshでログインした際、Ubuntu 14.04 LTS が云々、というメッセージが表示されて首を捻った。何か古い設定ファイルが残ってそうだな…。

Ubuntu 18.04 LTS x64 をクリーンインストールした他の環境と比較してみたところ、今回アップグレードした環境には /etc/motd というファイルが存在していて、そのファイルの中に Ubuntu 14.04 LTS 云々を表示する内容が書いてあった。

クリーンインストールした環境には該当ファイルが無かったので、試しに sudo rm /etc/motd でファイルを削除してみたところ、ログインメッセージが正常(?)な内容になってくれた。

他にも、/etc/update-motd.d/ 以下に、/run/motd.dynamic を生成するための設定ファイルが複数あるので、余分なファイルは削除しておいた。

せっかくアップグレードしたのだから、何かを動かして動作確認しようと思ったものの。

• love2d は、インストールして実行してもウインドウすら出てこない。
• Python3 + pyxel は、glfw がインポートエラーを出してコケる。

まあ、どちらも 64bit環境、もしくは今時のハードウェアスペックを想定しているのだろうなと…。

一応それぞれのインストール方法をメモ。

love2d は、公式サイトの、「Ubuntu PPA」というリンクをクリックすればインストール方法が書いてある。

_LoVE - Free 2D Game Engine
_love-stable : Bart van Strien

sudo add-apt-repository ppa:bartbes/love-stable
sudo apt-get update

sudo apt install love

これでインストール自体はできた。動かないけど。

Python3 + pyxel も、公式サイトの記述通りに作業すれば、インストール自体はできる。

_pyxel/README.ja.md at master - kitao/pyxel

sudo apt install python3 python3-pip libglfw3 libportaudio2

sudo pip3 install pyxel
  or
sudo pip3 install --no-cache-dir --ignore-installed pyxel

しかし、サンプルがインストールできない。

mkdir hoge
cd hoge
install_pyxel_examples

$ install_pyxel_examples
Traceback (most recent call last):
  File "/usr/local/bin/install_pyxel_examples", line 7, in <module>
    from pyxel.examples import install
  File "/usr/local/lib/python3.6/dist-packages/pyxel/__init__.py", line 4, in <module>
    from . import constants  # type: ignore
  File "/usr/local/lib/python3.6/dist-packages/pyxel/constants.py", line 1, in <module>
    import glfw
  File "/usr/local/lib/python3.6/dist-packages/glfw/__init__.py", line 34, in <module>
    raise ImportError("Failed to load GLFW3 shared library.")
ImportError: Failed to load GLFW3 shared library.

python3 を起動して import glfw と打っただけでもエラーが出るので、pyglfw (glfw?) 自体に問題があるようだなと。

少し調べてみたけれど、どうやら pyglfw は Linux 64bit版のみを想定して作ってる気配も…。libglfw.so は、それぞれ以下に置いてあるのだけど。

• Ubuntu 64bit : /usr/lib/x86_64-linux-gnu/libglfw.so
• Ubuntu 32bit : /usr/lib/i386-linux-gnu/libglfw.so

pyglfw の library.py 内、search_paths = [ ... ] の部分でライブラリを検索するパスが列挙されているものの、64bit版のパスしか書いてない。

_pyGLFW/library.py at master - FlorianRhiem/pyGLFW

試しに、library.py を編集。

sudo vi /usr/local/lib/python3.6/dist-packages/glfw/library.py

'/usr/lib/i386-linux-gnu/', を追加してみたところ、少なくとも import glfw でエラーは出なくなった。

しかし、pyxel のサンプルを動かそうとすると、これまた違うエラーが出て何も表示されない。

そもそも pyglfw が動くのかどうか、そこからして怪しいよな…。Intel Atom N270 + Intel 945GSE Express という、古くて非力なスペックだし…。

一応、簡易ベンチマークその他は動いているけど、あくまで簡易だろうし…。

• OpenGLの簡易ベンチマーク、globs は、一部を除いて動いた。
• ギアを表示する例のアレ、glxgears は動いた。
• OpenGL のサポート状況を一覧表示する glxinfo も、それらしい表示。

SP-5030用の処理はそれらしい結果が出てくるところまで書けたけど。ついでに、MZ-700版 S-BASIC (1Z-007B) にも対応させようとしたところで悩んだり。

MZ-700版 S-BASIC の記録フォーマットは、以下のページが参考になりそう。英語版の S-BASIC が対象ではあるけれど、中間コードの一覧も、記録内容も、細かく解説してある。英語だからよくわからんところもあるけど…。

_S-BASIC 1Z-013B internals
_Overview of S-BASIC commands
_MZ-700 / MZ-800 Basic Instructions Overview

例えば、以下のソースは…。


以下のような形で記録されてる。


フォーマットは、SP-5030 とかなり似ているけれど、若干違う部分もあるようで。

同じ点は以下。

• 1行分は、「行の長さ(2byte), 行番号(2byte), 内容、終了コード(1byte)」の順で並ぶ。
• ソースコードの最終2byteが、終了コード = 0x0000 になっている。要は、行の長さが 0x0000 なら、そこでプログラムは終了、という扱いにできる。

異なる点は以下。

SP-5030 は…。

• 行の終了コードが 0x0d。
• コマンドの中間コードは、1byteのみ。0x80 - 0xff の範囲を取る。
• ソース中の数値は、ASCIIコードでそのまま記述される。

S-BASIC は…。

• 行の終了コードが 0x00。
• コマンドの中間コードは、1byte、または 2byte。1byte分は 0x80 - 0xfd、2byte分は 0xfexx - 0xffxx の範囲を取る。
• ソース中の数値は、数値種類コード 1byte + 数 byte のバイナリで記述される。最初からバイナリになった状態で記録されるから、実行時に ASCII から数値に変換しないで済む ―― 実行速度が稼げるらしい。

ちなみに、mztファイルを読み込んで、S-BASIC、Hu-BASIC のソースをテキスト出力してくれる、bas2txt というツールが既にあって…。

_We Love MZ-700

C言語で書かれたソースも同梱されているので、とても参考になる。ありがたや。

というか、変換結果だけ欲しければ、bas2txt を使わせてもらったほうが早いのだけど。今回は、記録フォーマットについて把握しておきたいので、自分も処理を書きつつ仕様を確認、みたいな。

MZ-700 S-BASIC は、ソース内の数値をバイナリとして記録してあるらしいのだけど。それぞれ、以下のような状態で記録されてるらしい。

• 0x15 + 5byte : 浮動小数点数 (単精度実数)。5byte のうち、最初の 1byte が 指数部、残り4byteが仮数部。らしい。
• 0x11 + 2byte : 16進数。ソース内で $xxxx と記述した際に使われる。0x0000 - 0xffff まで記述できる。
• 0x0b + 2byte : 行番号。0 - 65535 まで記述できる。

16進数と行番号は、種類を示す数値の後ろから 2byte 読み込むだけで済むけれど。浮動小数点数が…よく分からない…。以下で説明はされているけれど…。

_S-BASIC 1Z-013B internals

プログラム中に含まれている数値に関しては、色々な種類がある模様。

最初の1バイトを見ると、数値の種類が分かる。

• 0x01 - 0x0A : 0 - 9 の数値を表す。
• 0x0B, 0xXX, 0xXX : 行番号。2byte で示す。(GOTO xxxx, GOSUB xxxx)
• 0x0D, 0xXX, 0xXX : 8進数。2byte で示す。(&Oxxxx)
• 0x0E, 0xXX, 0xXX : 2進数。2byte で示す。(&Bxxxxxxxx)
• 0x0F, 0xXX, 0xXX : 16進数。2byte で示す。(&Hxxxx)
• 0x12, 0xXX, 0xXX : 整数。2byte で示す。 (xxxx)
• 0x15, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX : 単精度小数点数。5byte で示す。(xxxx.xxx)
• 0x18, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX : 倍精度小数点数。8byte で示す。

ちなみに、文字列は、ASCIIコードがそのまま並んでいるっぽい。

中間コードは、0x80 - 0xFD で示される群と、0xFE81 - 0xFEFF, 0xFF80 - 0xFFFF で示される群がある。一応、書籍「ADVANCED MZ-700」に書かれていた情報を、若干 _メモ してみたので、書かれている一覧表を眺めれば、ある程度は分かる…はず…。 *1

REM文は、ちょっと扱いが面倒な感じ。通常の「REM」は、「PRINT」等の中間コードと同様の扱いで読んでいけばいいけれど、REM の省略形として「'」という文字があって。この「'」が使われると、プログラム内では、自動で、マルチステートメントの区切り文字である「:」が直前に挿入される模様。

ただ、この場合の「:」は、LIST を打った際には表示されないので…。読み取っていく際に「:」が出てきたら、その直後が「'」であるかどうかを調べてみて、「'」があったら、その場合の「:」は表示しない、といった処理が必要になる模様。

ちなみに「ELSE」も「'」と同様で、直前に「:」が入るらしい。これも、読み取り中に「:」が出現、かつ、直後に「ELSE」の中間コードがあるなら、その場合の「:」も表示しない、といった処理が必要になる。

各 .mzt を、バイナリエディタで開いて確認してみたソレも、一応アップロード。

• .mzt は、最初の 0x80 byte がヘッダー情報。データ本体は、0x0080 以降に入っている。

以下のプログラムは…。
このように記録されている。

• 水色 : 行の長さ
• 緑色 : 行番号
• 黄色 : 数値が入っている部分。上記の例では、整数(2byte)、及び、単精度小数点数(5byte)が記録されていることが分かる。
• 紫 : 行の終端コード
• 橙 : プログラム全体の終端コード

以下のプログラムは…。
このように記録されている。

• 赤 : 行の終端コード

各数値は、最初に以下が書かれていることが分かる。

• 行番号を示す数値は 0x0B
• 16進数を示す数値は 0x0F
• 2進数を示す数値は 0x0E
• 8進数を示す数値は 0x0D

以下のプログラムは…。
このように記録されている。

• 整数の 0 が 0x01、9 が 0x0A で記録されている。
• 整数の 10 は、0x12, 0x000A になっている。
• 最後のあたり、REMの省略形「'」(0x27)の前に、「:」(0x3A)が挿入されていることが分かる。LIST上では「:」なんて表示されてないけど、内部では「:」が挿入されているということ。

MZ-700のBASIC上で、小文字やひらがなを入力すると、BASICソース内では、ニコちゃんマークが前後に入る模様。当時は使っていたはずだけど、完全に仕様を忘れていました。


ベタ塗りニコちゃんが、「ここから小文字・ひらがなが始まるよ」の印で、線のみニコちゃんが「ここから大文字・カタカナに切り替わるよ」という印なのかな。たぶん。

そもそも、この文字、ニコちゃんマークという呼び方でいいのだろうか…。ひょっとして、 _スマイリーフェイス と呼んだほうがいいのかな。

使い方は以下。

--target xxxx で、対象のBASIC種類を指定する。sp5030, sbasic, hubasic が指定できる。

python pymztbas2txt.py --target sp5030 MZT_FILE
python pymztbas2txt.py --target sbasic MZT_FILE
python pymztbas2txt.py --target hubasic MZT_FILE

--jp をつけると、shift-jis (全角カタカナ)を交えた出力になる。指定無しなら、全てASCIIコードで出力する。

python pymztbas2txt.py --target hubasic --jp MZT_FILE

通常は標準出力に出力するので、ファイル保存したいときはリダイレクトを使う。

python pymztbas2txt.py --target hubasic --jp MZT_FILE > temp.txt

ヘルプ表示も可能。

python pymztinfo.py --help

ちなみに、ASCIIコード以外は、「{80}」「{FF}」といった感じで出力することにした。カーソル移動を示す文字は、「{↓}」「{←}」といった感じで、また、大文字・カタカナ、小文字・ひらがなを切り替える文字は、「{lower}」「{upper}」といった感じで出力。とにかく、「{」と「}」が出てきたら、その文字は MZ-80K/1200/700特有の、今時のフォントでは表示できない文字、ということで。

ちなみに、MZ-700 S-BASIC、Hu-BASIC 用プログラムをテキストに変換するツールとしては、C言語で書かれた bas2txt というツールが既に存在しているので、そちらを使ったほうが確実だし早いわけで。

_We Love MZ-700

ソースが大変参考になりました。ありがたや。

さておき、今回書いたツールの特徴としては…。

• SP-5030 にも対応したつもり。
• Python で書いてあるから改変が容易。

といったところかなと…。まあ、本来はもっと違うことをしてみたくて、その下準備として試しに書いてみた感じなのですが。

今時の環境で、MZシリーズ特有の文字を表示できないものか…。専用フォントを作成してどうにか、というのは無理かな…。

3D Vision に対して、個人的には…。まずは「立体視」という市場を確立することを最優先にせず、最初から「NVIDIA製GPUを経由して立体視をしたいならライセンス料を払え」と言い出しちゃったのが失敗だったのではないかと思っていたり。

今後使えるのか使えないのかも分からない段階からそういうことをしていたから、ディスプレイメーカも、「ライセンス料なんか払ってられるかよ」とNVIDIAと契約しなかったりもして。

その結果、立体視可能なスペックを持ってるディスプレイをせっかく買っても、PC利用時は立体視ができなかったし。せいぜい、TV放送されていた、左右に画面を並べた解像度の低い映像しか立体視できなくて、「立体視と言ってもこんなもんか」「ショボいですね」とユーザに思わせちゃったりして。

こんな状態で市場が確立・存続できるわけがないよなと。

つまり、NVIDIAは、金の卵を産むガチョウを早々に潰して肉にして売っていた、そんな印象があるわけで。まずはある程度市場そのものを育てないと…。まあ、TVだの、ディスプレイだのが既にあったから、全然違う市場を作るのではなく、既存の商品ジャンルの延長線上で楽に商売ができるかも、と考えていたところもあるのだろうかと邪推したりもするのですが。

もっとも、仕組みからして立体視が普及せずに終わるのは必然、と言われそうでもあるなと。

• アクティブシャッター方式は、解像度はともかく光量が落ちるし、ディスプレイ側もメガネ側もコストがかかるし。
• 偏光フィルタ方式は、コストは安く済むけれど、縦解像度が半分になるし、やっぱり光量は落ちるし。メガネのデザインが悪くて、左右画面の分離がちゃんとできなくて、おかしな映像に見えたりもするし。

光量が落ちて色がショボくなるとか、チラつくとか、映像機器としては結構致命的だよな…。

更に、TV放送された立体視映像は、左右の画面を横方向に並べているから、偏光フィルタ方式では結果的に1/4の解像度になっちゃうのが厳しかった。フルHDの表示デバイスを使っていてもSD画質+αになるのだから、そりゃ「こんなもんか」と思われちゃうよな…。

それに、HMDの類 ―― 左右の映像が、チラつきもなく、光量も落ちず、解像度も保証された別々の映像として提示される表示デバイス ―― で立体視を体験してしまうと、アクティブシャッター方式も偏光フィルタ方式も見れたもんじゃない、と感じてしまうあたりも…。

そもそもメガネの類をかけないとTVやPC画面を見れないという時点で、一般ユーザにとっては面倒臭いわな…。まあ、その面倒臭さすら我慢できるレベルの何かしらを提示できなかったのがアレだけど。

今後はVRの機材に期待するしか…。と言ってもググってみたら、これまた厳しい。独立型を謳いながらも初期設定にスマホが必須・PCの利用不可と妙な制限を無意味につけてみたり。そもそも既存の立体視環境より数倍のコストがかかるし。また普及せずに終わりそうな気配。

ところで。偏光フィルタ方式のデメリットは解像度が落ちてしまうこと、だったけど。当時から、「4Kディスプレイなら解像度の問題は解決する」「しかし4K対応液晶は高いので商品化は現実的ではない」と言われてたわけで。しかし、今現在は、どうなのか。4Kは今でも非現実的なのか。そうではないよなと。

せっかく偏光フィルタ形式のデメリットを解決できそうな状態になってきたのに、どこのメーカも立体視から手を引いてしまったのは、どうなんだろうなと。いよいよあの方式の本領発揮、ここから挽回、と言えそうな時期に、業界の空気にまんまと支配されて、機会損失(?)になっていたりしないか。あの当時、「もっと解像度の高い液晶を低コストで入手できれば」とボヤいてたことを、皆、もう忘れたのだろうか。それとも、そんな議論すらしてなくて、「他社が出してるからウチも」的に、単なる空気で安易な製品企画を立ててたメーカが大半なのだろうか。

というか、昔は無理だったけど今ならイケそうな仕組みって他にもありそうな気も。

sudo apt install bdfresize

bdfresize -f 2 src.bdf

bdfresize -f 2 src.bdf > dst.bdf

BDFフォントの見た目がどうなるか確認する際は、gbdfed が使える。

_Ubuntu Manpage: gbdfed - GTK-based BDF font editor

試しに、非整数倍でも拡大してみた。

bdfresize -f 3/2 src.bdf > dst.bdf
bdfresize -f 5/2 src.bdf > dst.bdf
bdfresize -f 7/2 src.bdf > dst.bdf

それぞれ、1.5、2.5、3.5倍になるはず。

出力結果を gbdfed で開いて眺めてみたけど…。一応、読める文字の形に見えるな…。読めれば、まあ、問題無いのでは…。

以下のページで、potrace使用時のオプション指定が書かれてたので引用メモ。

_How to convert a bitmap font (.FON) into a truetype font (.TTF)? - Stack Overflow

--turdsize 0 --opttolerance 0 --unit 1 --longcurve --gamma 0 --blacklevel 0 --cleartext

FontForge 上では、ファイル → 環境設定 → アプリケーション、の設定で、potrace 利用時の設定ができるので、そこに上記のオプション文字列を貼り付けて「potraceを使用」をオンに、すればいいのかな。たぶん。

potrace のオプションについては以下が参考に、なるのだろうか。英文だからちょっとよくわからん…。

_Peter Selinger: Potrace

以下は、メモ帳で、自作のMZ-700風互換フォント、Pet2015bdfを指定した場合。フォントサイズは12ptを指定。


以下は、MZ-700フォントに見える感じの画像を変換した、Mz700bdf を指定した場合。


以下は、メイリオフォントを指定した場合。前述のフォントを指定しながら、 _特定の全角文字 を打てば、MZ-700風の図形文字を表示できることが分かるかなと。


注意点。フォント選択時、フォント名が出てこないのは仕様。


昨今のフォント選択ウインドウは、そのフォントを使ってフォント名も表示するのだけど。今回作った .ttf は一部のフォントサイズ(6, 12, 18, 24, 30pt)しか有効ではないので、フォント選択ウインドウ上で使ってるフォントサイズを指定されても、そんなフォントサイズは持ってないから、フォント名も表示されない状態になるわけで。

• Python + Pillow(PIL)で、1文字8x8ドット、16x32個が並んだフォント一覧画像を読み込んで、BDF形式でテキスト出力してみたり。
• BDFフォントを拡大して別のBDFを生成できる、bdfresize を使ってみたり。
• 複数のBDFからビットマップフォント埋め込みTTFを作成できる、bdf2ttf を使ってみたり。

• BDFからアウトラインフォントを作りつつ、そこにビットマップフォントを埋め込む作業の手順が把握できてない。

FontForge を利用して、アウトラインフォントに変換する作業は、昨日の作業で少し分かりかけてきたのだけれど。そこに、ビットマップフォントを埋め込めるのかどうか、まだ把握できてない状態。

Pet2015bdfフォントの、英数字、カタカナ、ひらがら部分は、自分がドット打ちした部分なので、自由に使えるはずです。図形文字は、まだ一部、MZ-700のソレが残ってるけど…。

MZ-700フォント画像は、配布しちゃってもいいのか悪いのか分からんけど、とりあえず一緒に置いときました。まあ、気になる人は互換フォントだけ使えば済む話かと。

レトロPC、特にMZシリーズのフォントのライセンスは、何がアウトで何がセーフか、よくわからんのですよね…。詳しくは以下を。

_mieki256's diary - レトロPCのフォントの著作権って一体どうなっているんでしょうね

大昔のアーケードゲームって、レバーとボタンで必ず入力させる仕様ではなかったというか、ゲームのタイトル毎に入力機器の仕様が違っていたのが当たり前だったよなと…。パドル入力とか、レバー2本とか、色々あったような。そもそも、格ゲーの代表事例であるストリートファイターシリーズも、最初のヤツはボタンを叩く強さでアクションが変わる仕様だった気もする。 *1

本来、ゲームを快適に遊んでもらうためには、ゲーム内容に即した入力機器が提供されるべきで。だから昔のゲームは、タイトル毎に入力機器の仕様が違っているのもアリだったのだろうなと。ゲーム内容が違うのだもの、コントローラだって違って当然っしょ。みたいな。

だけど、商品が変わるごとに入力機器の仕様が変わる、筐体が必ず変わるとなると、店側は導入費用が高くついちゃうし、ゲームメーカも毎回入力機器の設計をし直す羽目になるからコストがかかるしで。使い回しができる筐体のほうが商売上は助かるよね、せめて基板の入出力コネクタぐらいは共通規格にしませんか、ということになって、業界で _規格 が作られて、てな歴史があったりもするわけで。

しかし、規格や筐体が決まり、入力機器もレバーとボタンで固まってきて、開発現場はコレを前提にしてどうにかせい、と強制されると、今度はゲームを作る側がちょっと困ってしまって。「このコントローラ仕様ではプレイヤーキャラに色んなアクションさせられないなあ。ボタンが足りない。どうしよう」「そうだ。レバーとボタンの組み合わせでコマンドを入力できるようにしてみたらどうだろう」と閃いて…。そうやって、いわゆる格ゲーというジャンルのフォーマットが固定するわけだけど。

汎用性を重視した入力機器仕様を強制されてしまったから、苦肉の策としてコマンド入力という仕様が盛り込まれた、と言えなくもないよなと。「お客さんに楽しくゲームを遊んでもらおう」と思ってそういう仕様にしたというより、「商売の都合でこうなってしまいました」てな側面のほうが大きい、そんな気もしてきたり。 *2 つまり、格ゲーとは縛りプレイである、とも言えそうな。

てなことを考えていくと、レバーとボタンだけで戦え、という方針は、これははたして格ゲーというジャンルの今後の発展を考えた場合に正しいのかどうか、ちょっと悩むなと。格ゲーは本当にそれでいいのか。実はもっと楽しく遊べる・盛り上がれる入力仕様があったりするのではないか。などと不安になってきちゃったりもして。

でもまあ、元々が縛りプレイだったジャンルだし、今更かも…。

いわゆるeスポーツって、要は見ているお客さんが盛り上がればジャンルとして成立するのだろうと自分は想像しているのだけど。野球やサッカーもそうだし。であれば、観客を盛り上げるために各種ルールが設定されていくのが妥当であろうと。

となると、レバーとボタンだけで戦え、というルールは、見ているお客さんがより盛り上がることに繋がっていくのかどうか、という疑問も。どうなんだろう。

てなあたりからバカ妄想。格ゲーが元々縛りプレイであることを意識できたら、それを加速する方向に進むことだってできるかも。ジャンプ禁止とか、必殺技封印とか、片手操作とか、足で操作とか。そういうルール・部門だって作れなくもないよなと。そのほうが盛り上がるなら、という前提付きの話だけど。

逆の方向もアリかもしれず。何を使っても構わないからとにかく勝て、派手に戦え、みたいな。各人が色んなコントローラを使う中、レバーとボタンで攻略しちゃう達人が出てきて更に盛り上がったり。とか。

大昔にTV放映されていた鳥人間コンテスト等でも、ひたすら記録を伸ばすことに注力し続ける参加チームと、一発ネタで観客を笑わせるチームに二分していた記憶があるけれど。eスポーツも、そういうカテゴリ分けができたりしないか。ひたすら勝つことに注力する試合とは別に、絶対勝てるわけがないんだけど操作してる人の悪戦苦闘を眺めてるだけで観客大爆笑、みたいな何かというか…。

どこかのユーチューバーが、そういうことをしたりしないかな。eスポーツには絶対出れないぐらいに低レベルだけど、その人のプレイを見てるだけで皆が元気になれる、みたいな。「レバーとボタンしか使っちゃダメ」とeスポーツが固いことを言ってるのを尻目に、「今日はこんなトンデモ機器でプレイしてみました！」的動画をアップしてお客さんに喜んでもらうゲームプレイヤー。って既に居そうな気もする…。色んな人が居るもんな。絶対居るよな。

何にせよ、大昔のゲームの入力機器がバラバラだったように、ゲームのプレイの仕方も色々あったほうが楽しいんじゃないか、などと素朴なことを思ってしまったりもして。もちろん、その「色々」には、「あえてレバーとボタンだけ」や、「レバーとボタンにこだわらず」等々、何でも含まれていて…。

楽しくなるなら、どんなルートもアリだよな、と。

個人的には、eスポーツってどうなの、成立するのかね、と疑問視しているところもあって。

一般的なスポーツの場合、人間の肉体はちょこっと弄ればスペックが急激に変わるものではないので、じっくりと鍛えていかないと成果が出ないし、故に記録を伸ばすこと、残すことにも価値が生じるわけだけど。

しかし、ゲームって、開発スタッフがプログラム上の数値をちょっと弄るだけで、プレイヤーキャラのスペックが急激に変わったりするので ―― 競い合うための土台が、作り手という「神」の振る舞い次第で急変してしまうから、何かを競い合うという状況が成立しにくい気もするわけで。プレイヤーがどんなに訓練して技を磨いても、プログラマーが数値をちょっと弄ったら全部水の泡、では…。こんな不安定なネタで、記録云々という方向で競技らしく見せるのは、ちょっと無理があるんじゃないのと思っていたり。 *3 *4

だけど、観客を楽しませたほうが勝ち(みたいなもん)、と捉えれば、それならフツーに成立しそうだなと。もっとも、それはもはや競技ではないのかもしれない。プロレスのショーみたいなものになってしまうのだろうか。

こういうのって、「客を楽しませてなんぼ」で発展させるのか、「記録を残してなんぼ」で発展させるのか、どちらに進むかで定着するかどうかが違ってきたりするのかな、などと思ったりもして。どちらが残りやすいのかは分からんけれど。

てな感じのことをぼんやり思ってしまったのでメモ。只の思考メモです。オチはないです。

eスポーツの会場で、コントローラの入力状態に合わせて複数のライトがビカビカ光ったらどうなるだろう。素早い入力をすると、ライトがパパパパッパッパパッと光る、みたいな。そういう舞台装置が既に設置されてるイベントがありそうな気もするけれど。

必殺技が出ると、会場に風が吹いたりして。技の種類によって風の吹き方や強さも変わったり。しかし、そんなに都合よく、風って出したり出さなかったりできるのかな。常時、風を出していて、向きだけを細かく調整する仕組みならどうか。どういう装置になるのやら。

キャラが床に叩きつけられると、会場全体が揺れる仕組みになってる、とか。観客が、試合展開との強い一体感を得られるだろうな。でも、そんな装置は実現可能なのだろうか。大掛かりな仕組みになるよな…。

画面内で爆発すると、会場内でもリアル爆発が起きる、とか。某爆弾男を使ってイベントを開いたら、会場のあっちこっちでドッカンドッカン。あかんわ。色々とヤバイ。

まあ、そういうことをするためには、ゲーム本体に手を入れないといかんだろうけど…。とりあえず、トリガーと種類コードだけは出力しておくから、その先で何をどう動かすかはイベントを開催する方々に任せますよ、みたいな感じになるのかな。

ゲーム本体に手を入れなくても、人力・手動でやることだってできるかも。画面をずっと凝視して、この技が出たらこのボタンを押す、みたいなことをする担当の人が居て…。いや待て。ソレって、出場者並みの動体視力と反射神経を要求されるのでは…。

コントローラの入力で、会場に設置された複数のライトが光るとなると、そこにはリズムが発生するだろうな…。そうなると、まるで音楽を演奏してるかのようなプレイスタイル、なんてものも生み出せるのかも。それはもはや、VJ に近い気もする。

コントローラの操作でライトを光らせて、VJ紛いのことをできるなら…。ゲーム画面をそのまま使ってVJっぽいことはできないものだろうか。音楽のリズムに合わせて対戦していく、みたいな感じで…。ドラムに合わせて小・小・小・大キック、音楽が盛り上がってきたところでタイミングを合わせて必殺技。いやまあ、それって音ゲーじゃないのですか、という気もしてくるけれど。

それはもう、競技じゃないのだろうな。おそらく、ライブっぽい扱いになるのだろう…。

アクションゲームにおいて、プレイヤーキャラのアクションの一つ一つには、風切り音や打撃音等のSEが割り振られているものだけど。コード、バスドラ、オケヒ、「Hey!」「Come on!」等々、それっぽい音が鳴るように切り替わるモードを盛り込んだら、別のジャンルが出てきたり。するのかな。どうかな。どうなんだろう。ちょっと脳裏に「播磨体操第一」が。

親父さんから乾電池を買ってきてほしいと頼まれたので、ケーズデンキで MITSUBISHIブランドの単3乾電池 x 20本、maxellブランドの単4電池 x 10本を購入。値段が安いからすぐに切れるだろうけど、一応日本メーカのブランドで売ってるから液漏れ等はしないんじゃないかと期待。