2020年11月24日発売の「日経ソフトウエア2021年1月号」で「ファミコンで動くゲームを作ろう」という特集記事を書かせて頂きました。
今回が第2回目です。ファミコンのライブラリが完成して、十字ボタンの入力ができたというところで終わっています。
次回、第3回目では実際にゲームを作ります。
突然ですが、PCエンジン用のプログラムを自作してみたいと思います。関連する知識が全くない状態からのスタートです。
まず最初にCC65が開発に使えるのでは、と思っていたのですが、CC65のドキュメントを読んでも使い方が良くわかりません、、、。付属のドキュメントには「Some useful resources on PCE coding:」というリンクを貼られていたのですが、その中の一つがこちら。
↓
「HuC」というPCエンジン用のCコンパイラがありました。これを使ってみます。CC65とは無関係ですね。開発は2005年で終わっています。バージョンが一杯ありますが、「huc-3.21-win.zip」をダウンロードしてみました。windows版ですが、DOS版との違いがわかりません。
ZIPファイルを展開して、「huc-3.21-win」フォルダをCドライブの最上位ディレクトリに置いてみました。これでインストールは完了です。
binフォルダ内のEXEファイルは実行しようとすると「WindowsによってPCが保護されました」と出てしまうので、事前に解除しないといけません。
どうプログラムしたらいいのか、よくわからないので、docフォルダのドキュメントを読むと、「PONGが参考になる」という感じの一文を発見。そこで検索すると、次のページがヒットしました。
↓
こっちのHuC(huc_dos_142.zip)はタイムスタンプが2000年で、バージョンが5年ほど古いです。DEMOSフォルダにサンプルプログラムとして「PONG」と「SCROLL」が付属しています。これらのソースだけ頂くことにします。ソースの中に拡張子が「PCX」というファイルありますが、これはBG&スプライト用の画像ファイルです。
ビルド用のバッチファイルを作ります。「PCE_INCLUDE」はHuCに指定するヘッダファイルのパスです。
「SRCFILE」はコンパイルしたいソースのファイル名。出力するROMイメージのファイル名と兼用です。
「huc」はCコンパイラ。「pceas」はアセンブラです。hucはCをアセンブラに変換するだけなので、pceasを使ってアセンブルを行います。
、、、と思ったのですが、hucからpceasを呼び出すのが正しかったようなので、上記のように修正しました。pceasを実行する記述を無くして、binまでのパスを設定しています。この場合、pceasの実行中にpauseのメッセージが表示されてしまうので、nulでメッセージを消しています。もしエラーが出ないならpauseは不要です。
バッチファイルを実行すると、PONGをリビルドします。そのままだとファイルが見つからないというエラーが出るので、ソースをちょっと直します。
#include "../huc.h"
↓
#include "huc.h"
こんな感じです。
あと、PCXファイルが見つからないというエラーが2件出るので、ファイル名を直します。
「RACKETLE.PCX」→「RACKETLEFT.PCX」
「RACKETRI.PCX」→「RACKETRIGHT.PCX」
こんな感じです。逆にソースのファイル名を直してもいいです。
うまくビルドできたら、ROMイメージの「PONG.PCE」が生成されます。
PONG.PCEをPCエンジンのエミュレータで実行した様子。
なぜかスコア表示がおかしくなってしまいました。原因は不明です。そのうち直したいと思います。
先ほどのバッチファイルを修正して、「SCROLL」もリビルドして、実行してみました。こっちは問題なく動きました。
現時点ではエミュレータで動かしていますが、そのうちPCエンジンの実機でも動かしてみたいです。
(追記2020/11/29)
PONGのスコア表示がおかしくなる問題ですが、「load_sprites」を使わないで「load_vram」に変更すると直りました。
こんな感じに修正します。
load_vramの書式は(VRAMアドレス ,int型配列変数 ,転送ワード数)です。
#incsprの変換後のソースを見ると、画像データの合間になぜか「dw.0」が追加されていて、これがデータの頭出しの誤差を作ってしまってました。load_spritesを使うと誤差を含んだままVRAMに転送してしまうのですが、load_vramなら誤差を取り除いて転送することができます。
あと、#incspr関連の記述はソースの最後に配置されていますが、これだとコンパイル時に変数の未定義エラーが出てしまいます。いままでエラーが出なかったのが不思議ですが、、、。#incspr関連はmain関数より上に配置しましょう。
正常にスコアが表示している様子です。
続き
前回の続きです。
ここから歩いていける距離に駿河屋があるので、ちょっと覗いてみたのですが、PCエンジン系のソフトは高いですね。ボンバーマンが600円というのが最低価格でした。ブックオフは950円均一でしたが、数が少ないです。市販のPCエンジンのゲームはPS3やWiiUのアーカイブで遊ぶのが正解な気がします。
今度はPCエンジンのカードを自作してみたいと思います。
目コピーで基板を作ります。さすがに肉眼で見るには辛いサイズなので、スキャナを使ってみました。上の写真はスキャナの画像です。
ピンの端から端までの距離は47mmくらい。全38ピンなので、37で割ると、、、
47/37 = 1.27027027027027。
たぶん、1.27mmピッチだと思います。間違ってたらすみません。
CADに入力中の様子。
カード自体のサイズは54×85mmとしました。厚さは2.5mmくらいですね。1.5mmで作ってから、1mmのプラ板を足したらいいのかなと思っています。
結線を調節中。まだ未完成です。
フラッシュメモリの容量は4Mビットです。「R-TYPE」の容量の2倍ですが、少ないかもしれません。開発環境はHuCというのを使ったらC言語で作れるみたいです。
資料不足です。ピン配置が間違っている可能性があるので、もう少し調べないといけません。
CD(Card Detect)はカード検出用の端子ですね。GNDに接続するのではないかと予想しています。これから直します。
HSM(High Speed Mode)は処理速度を伝える端子ですが、信号の向きはどっちでしょうか。検索した感じだと、論理はHigh=ハイスピードらしいです。
CS(Chip Select)に相当する端子が無かったので、A19をCEに接続してみました。
D0~7は海外仕様とでビットの並びが逆だそうです。これは書き込み時に反転すれば、対応できるということですね。
あと、書き込み装置も作らないといけないのですが、コネクタの入手が難しいです。
(11/19追記)D7~D0の並びが逆だったような気がするので、反転してみました。エッジ経由で書き込んだらデータに変換はないので、反転する意味はないのですが、気分の問題です。
PCエンジンを中古で買ってみました。
PCエンジンは今まで縁がなかったので、大竹まことさんの番組を観てたあたりで知識が止まってました。どれを買ったらいいのかよくわからなかったのですが、検索したら、
「初代(本体が白い)はRF出力でテレビに映す」
「AVブースターという周辺機器を付けたらビデオ出力できる」
「コアグラフィックス(本体が黒っぽい)はビデオ出力できる」
という情報は得ることができました。
検索の途中、拡張端子のピンアサインを載せてる方を見かけたので、もしかしてどうにかなるのでは? と思ったので、白いPCエンジンを買ってみました。
初めて本体に触りました。小さい。かっこいい。あと、どういうわけか裏面のシリアルナンバーが削り取られてました。
上記のサイトを参考にして、拡張端子の最下段の右から2番目からコンポジットビデオ信号を取り出して、テレビのビデオ入力(RCA端子)に接続しました。右から3番目はGNDです。ジャンパーワイヤーを挿し込んでます。
自分の場合は3.5mmステレオミニプラグ→RCA端子のケーブルを使ってテレビに接続していますので、秋月の「ステレオミニジャックDIP化キット」を使っています。
あと、ACアダプタは秋月の9Vのもの(700円)をプラス/マイナスを反転させて使っています。PCエンジンはメガドライブやファミコンやスーパーファミコンと同じくセンターマイナスです(秋月のACアダプタはセンタープラスなので注意)。これらのゲーム機は電圧が大体同じです。Amazonを見ると、PCエンジン用のACアダプタが2400円くらいで売ってますが、高すぎな気がします。
結果、問題なく動きました。AVブースターを買わなくても、ビデオ入力でテレビに映すことができます。
写真は「モトローダー2」を立ち上げた画面です。自分はコントローラを持っていないので、ここから先に進めません。どうにかしてコントローラを入手しなくては。
(追記2020/12/10)
映像だけでなくサウンド出力もできるようにしました。
こんな感じです。RCAコネクタを付けました。
拡張コネクタを正面から見た様子です。音の信号は直流をカットするために、電解コンデンサを通しています。 音量が小さいので、本来だと増幅したほうがいいみたいです。
(2021年6月30日追記)
コネクタの強度に問題があったので、基板取り付けタイプのコネクタに変更してみました。
DIY GB CARTRIDGE(GAMEBOY用カートリッジの自作)
趣味でゲームボーイ用カートリッジ基板を作る試みです。とりあえず基板のCADデータを公開してみました。
前回はDIPのフラッシュメモリを普通に取り付ける基板を考えてみましたが、それだと基板に厚みがありすぎてガワに入りません。そこで次のように工夫してみました。
カートリッジは2種類考えてみました。一つはPLCCを基板に直接ハンダ付けするというタイプ。もう一つはDIPの足を90度曲げて、四角い穴に入れてハンダ付けするタイプです。この四角く基板をくり抜くというのは独自のアイデアです。
PLCCの方はハンダ付けがもの凄く難しいです。やってみて気が付きました。端子が奥に丸まっているのでパッドにハンダが流れてくれません。ブリッジしまくりです。これは作らないで、棚上げにします。
フラッシュメモリライターの基板です。ゲームボーイ用のエッジコネクタは面実装なのですが、ここのハンダ付けが細かすぎて一番難しかったです。3回くらいハンダ不良でやり直しました。
ライターで書き込み中の様子。32KB(バンク切り替えなし)のみ対応しています。
ファミコンの時はNESファイルの先頭16バイトを削ってロムに書き込みましたが、ゲームボーイの場合はGBファイルをそのまま書き込みます。
書き込んだロムをゲームボーイに挿し込んだら残念ながら動きませんでした。
エッジのCS端子-フラッシュのCE端子
に接続するのを止めて、
エッジのA15端子-フラッシュのCE端子
に接続したらうまく動きました。基板の設計ミスです。CS信号はロムのアクセス時だけLowになるのかと思っていたのですが、どうやら勘違いだったみたいです。
そこで、パターンカットとジャンパ線で対応しました。
動作中の様子です。ゲームボーイの液晶が見づらいです。これは電圧が低いせいなのか、偏光フィルターが劣化してるのか、、、。
300円で買ったスーパーゲームボーイは綺麗にテレビに映せるので便利ですね。
(11/19 追記)なんとか、PLCCのハンダ付けができました。ブリッジ上等でハンダを持ってから取り除くのを繰り返して、どうにかハンダ付けしています。性能はDIP版と同じです。