<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>パピコニアンの倉庫 - 整頓中 &#187; ゲーム基板</title>
	<atom:link href="http://www.retropc.net/mm/archives/category/%e3%82%b2%e3%83%bc%e3%83%a0%e5%9f%ba%e6%9d%bf/feed" rel="self" type="application/rss+xml" />
	<link>http://www.retropc.net/mm</link>
	<description>コメントスパムがひどいのでコメント欄を閉じています。ご用の方はTWITTER(@morian)へ</description>
	<lastBuildDate>Mon, 30 Mar 2026 14:28:56 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>脱衣ゲーム基板でイースIIの曲を流してみた</title>
		<link>http://www.retropc.net/mm/archives/1414</link>
		<comments>http://www.retropc.net/mm/archives/1414#comments</comments>
		<pubDate>Fri, 29 Nov 2013 11:14:13 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[アーケードゲーム]]></category>
		<category><![CDATA[ゲーム基板]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=1414</guid>
		<description><![CDATA[動画のタイトルとサムネがネタの全てという出オチ以前の動画ですが、ここでは技術的な補足をしてみたいと思います。 今回使った華弥生というゲーム基板は、CPUにZ80、音源チップにYM2203Cを搭載していて、この2点について見れば、NEC PC-8801mkIISR(以下、8801)と互換があると言え・・・なくもないです。実際には色々違いますが。 華弥生はダイナックスから1986年頃に発売されたゲームです。アーケードゲーム市場ではジャンク品扱いに近く、数百円程度で取引されているようです。だからといって音源チップ目当てで買いあさると絶滅しちゃうかもしれません。 YM2203CのDAにはY3014が使われていて、華弥生のおしゃべり機能はOKI msm5205でADPCM再生されます。 音楽再生のプログラムには8801版イースIIを流用しています。あっと、もちろん、オリジナルのディスクを所有していますヨ。 そういえば、これを使ってペーパークラフトを作ったっけ。 そんなわけで、著作権上の理由によりEPROMに書き込んだプログラムおよび曲データの配布は出来ません。また、元のプログラムをあれこれと書き換えていてパッチ当てが面倒なので、差分の配布も出来ませんが、こんなのを欲しがる人はいないと思います。 8801とゲーム基板が同じCPUを使ってるといっても、そのままではプログラムを実行できません。 フロッピーディスクからプログラムを読み込んで実行するパソコンのプログラムと違って、ゲーム基板は、あらかじめ書き換え不可能なROMにプログラムが焼き込まれていて、そのままプログラムを実行します。ファミコンのカセットゲームと同じですね。 8801はフロッピーディスクから本体内のRAM領域にプログラムを読みこんで実行するので、プログラム自体がRAM領域にあるということになります。これをうまく利用してプログラムの実行中にプログラム自体を自分で書き換えるというプログラミングテクニックがあるのですが、ゲーム基板の場合、プログラムはROMにあるので書き換えができません。 イースIIでも、このプログラム自体を書き換えるというプログラミングテクニックが使われているので、8801で動いているイースIIのプログラムをそのままゲーム基板のROMに書き込んでも正しく動作しないのです。 ゲーム基板にもRAMがあるので、ROMのプログラムを一旦RAMにコピーして実行すればいいのではないかと思うのですが、ゲーム基板のRAMはとてもとても小さいのです。 また、メモリの構成が違います。8801ではZ80メモリ空間を全てRAMにしたり、メモリ空間の一部をVRAMに切り換えたりすることが出来て、イースIIのプログラムもそれに合わせて作られていますが、この華弥生の基板ではメモリ領域のほぼ全てがROMで、2KByteだけRAMになっています。 もちろん、I/Oポートのアドレスも違いますし、割り込み発生源も発生方法も違います。 そんなわけで色々とプログラムの修正が必要になるのですね。 移植手順としてはベタなやり方ですが&#8230; PC-8801mkIISR版のイースIIのオープニング部分のプログラムを取り出します 逆アセンブラを使ってソースコードを生成します。イースIIではデータ領域を上位バイトと下位バイトに分離していて参照している箇所があって、これが8801固有のメモリアドレスになってしまうので、なんとかして探して書き換えます 自己書き換えしているプログラムを修正します。これも書き換え箇所の特定が面倒なのですが、Z80エミュレータとかシミュレータで書き換えを検出するとかします プログラムとワークエリアが混在している箇所を綺麗に分離します。プログラムはROMに書き込み、ワークエリアはRAMを参照するようにするためです ちなみに8801版イースのプログラム切り出しはhootを参考にさせて頂きました。ありがとうございます。未だに8801の事はよくわかってませんがCPUが同じならなんとなく。 で、ここまでは簡単だったんですけどねー… この状態でエミュレータ上でプログラムを実行してみたところ、最初の方は曲が流れたのですが、徐々に変な曲になってしまうのです。 曲がおかしくなったところでプログラムを停止してメモリ内を確認してみて気がついたのですが、曲データの中身を、曲の再生中に書き換えている事に気がつきました。曲データもROM領域に置いてあり、曲自体の書き換えができずに正しく再生されなくなってしまったのですね。曲データは4KByteほどなのですが、それでも華弥生基板のRAM領域には収まりませんから、曲データだけをRAMに置くこともできません。 曲データの構造を調べてみたところ、曲のリピート部分でリピート回数を曲内部に書き込んでいるようでしたから、その処理を書き換えることにしましたが、まーこれが調べるのも書き換えるのも面倒でした。曲の再生プログラムだけでなく、曲データ自体にも手を加えることに。 また、リピート回数のチェックだけでなく、リピートの最後にリピートの途中で抜け出す処理にも手を加えてあります。要するに、MDXのMMLでいうところの&#8230; [～]# &#8216;[]&#8216;で囲まれた間を指定回数だけ繰り返します。範囲2～255。 / &#8216;[]&#8216;の中を演奏中、最後の繰り返しで&#8217;/'以降のデータを無視します。 この処理を行うのに、曲データ内に直接リピート回数を書き込んでいるという仕組みなのですね、合理的。 さらに曲データ自体がZ80メモリ空間の固定アドレスに配置されるようになっていたので、その箇所も書き換えています。 最初の動作確認とデバッグは、ハードウェア構成が似ていて使い慣れているPC-6001mkIISRエミュレータ上で行いました。つまり、PC-6001mkIISR/6601SRでもイースIIの曲が再生できていることになるのですが、これについては、bookwormさんがインタフェース付きのすばらしいプログラムを作られています。 8801と華弥生基板ではハードウェアレベルでの大きな違いが2つほどあります。 その一つは、Z80割込み方法です。8801ではYM2203Cから割り込みがかかるのに対して、華弥生基板ではYM2203Cからの割り込みが取れません。また、華弥生基板では8KHzタイマー割り込みと垂直同期割り込み(約1/60秒間隔)の2つの割込みの2種類しかなく、イースIIで使われているYM2203CのTimer-B割込みとは間隔が異なるのです。これはYM2203Cのステータスを常時監視する方法で対処しました（ポーリング）。これが原因で、曲の再生中は曲の再生以外の事がほとんどできないゲーム基板ということになります。もちろん、曲の再生プログラムを8MHzタイマーを使ったものに書き換えれば、本来の基板の性能を発揮できますから、この辺は手抜きです。 もう一つは、YM2203Cに供給されるマスタークロックの違いです。マスタークロックはタイマー割り込みの間隔や音の音程に影響を与えます。8801のYM2203Cには4MHzのクロックが供給されていますが、華弥生基板では1.25MHzとなっています。この違いも曲の再生プログラムで吸収すればいいのですが、YM2203のTimerや周波数の設定値の資料が見当たらなかったので（みんなどうしてるのかな？）、基板のYM2203を外して子亀基板を乗っけて供給クロックを切り換えるように改造しました。オマケにYM2203だけを取り外して別の事にも流用できますし。 ちなみに華弥生はMAMEでも動いているのですが、ソースをみると、Z80への供給クロックが5MHz、YM2203Cへは2.5MHzになっていますけど、これはそれぞれ2.5MHzと1.25MHzが正しいようです。基板にオシロつないで調べましたし、初めて基板上で曲を流した時に、ものすごく重くて遅い曲になったのでこれは何かが違うなーと。Z80を5MHzで動かすにはZ80BかZ80Hが必要なのですが、基板上のZ80はノーマルタイプっぽいので変だとは思ったんですよね。 MAMEのソースについていえば、DIPスイッチ周りが実装されていなかったり、この基板のRAMはバッテリーバックアップされていてハードリセットも可能ですが、これも実装されていないようです。 とはいっても、今回のデバッグではMAMEのデバッガを何度も利用させてもらいましたから、先駆者の方々には本当に頭が上がりません。せっかくなので華弥生基板のDIP表をUpっておきます。 さて、動画でもわかるように、曲を流すだけでは寂しかったので、8801版のオープニングデモ画像を流用して表示してみました。このゲーム基板の描画機能がなかなか面白くも面倒でもあったのでまとめておきます。 VRAMはbitmap構造なのですが、CPUであるZ80側から描画IC側にある画像データ(VRAM)に直接アクセスする事ができません。CPU側からは描画ICに対して、「この位置(ソースアドレス)からの画像データをこの座標に表示セヨ」というコマンドを送る事しかできません。Z80と描画ICはI/Oポートで薄くつながっている感じです。表示できる画像は矩形データで、ソースアドレスというのは描画ICに直結されたグラフィックデータROMのアドレスです。 この仕様では、CPU側から画像データを送ったり、グラフィックROM内の画像データを書き換えるということが出来ないので、あらかじめ決められた画像データしか表示できません。ゲーム基板では、画像データを書き換えられないのは珍しいことではないのですが（大抵のゲーム基板はスプライトデータを動的に書き換えられないのと一緒）、せっかくのbitmap構造なのに任意の位置に任意のデータを書き込めないのがもったいないというかなんというか。 それに加えて、ICに繋がれた画像データはBitmap構造ではなく、圧縮された画像形式になっています。圧縮形式はランレングス圧縮です。同じ色が横に何個並んでいるかを記録するという方式で、例えば色が2色で、それぞれを0と1で表すとしたら、11110000という8ドットの画像は、1404みたいな感じで、色番号＋個数＋色番号＋個数というデータになります。 同じ色が並んでいた方が圧縮効率がよくなる反面、ドット毎に色が違うとデータ量が増えるという欠点もあります。 この基板では16色が使えるので色情報が4bitです。長さの情報は11ドットまでは4bitを使っていいので、長さ11ドットまでの横線は1バイトで表せます。つまり、横方向に同じ色が並んでいれば、1ドットも11ドットも1バイトで表せます。 12ドット以上の場合には、別の方法で表現することもできて、色コード4bit+0x0Cという1バイトと続く1バイトの合計2バイトで最長255ドットまで表現することもできます。つまり、0から0x0b(10進数で11)までで表す方法と、0x0C(10進数で12)を使う方法があるのですね。この0x0Cというのがコマンドのようなもので、他にも0x0D, 0x0E, 0x0Fといったコマンドがあり、指定位置から横線を描く、描画ページを変更する、改行する、といった機能があります。 指定位置から横線を描くという機能を使うと、すでに描いてあるドットを飛び越える事ができるので、透明色のように使えます。 同じ色が横に並んでいるほど圧縮効率がよくなる、ということは、1ドット毎に色が違うと圧縮効率は最悪になります。1ドットを1バイトで表すとなると、320×240ドットの画像は150KByte・・・かな。これはZ80メモリ空間に収まらないどころか、1Dのフロッピーディスク1枚をほぼ使い切っちゃいますね。 1ドット毎に色が違うと最悪、ということは・・・8801のタイルペイントとの相性が最悪だー！ということに。 ただ、このゲーム基板は面白い仕様になっていて、2枚の画像レイヤーを1ドットずらして表示することができるみたいなのです。どうやら、2ドットを一度に描くか、左のレイヤーにだけ描くか、右のレイヤーにだけ描くかみたいな指定ができるっぽいです。どういうことかというと、左レイヤーだけに描くように指定してから、圧縮された画像を展開すると、1ドットおきに絵が描かれます。続けて同じラインに、右レイヤーだけに描くように指定して画像を展開すると、先に描いた左レイヤーには影響せずに、1ドットおきに絵が描かれることになって、1ドットずれた2つのレイヤーが表示されて、これで1ライン分の画像ができます。つまり、2色が交互に現れるタイルペイントとの相性は最高に良いのですね。 この基板仕様は3ドットタイルペイントの相性が最悪ですし、ドットをバラバラとちりばめて打ってあるようなイースIIのタイトル画面はどうにもなりません。 [...]]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/1414/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>映像信号を測る / ギャプラス基板</title>
		<link>http://www.retropc.net/mm/archives/666</link>
		<comments>http://www.retropc.net/mm/archives/666#comments</comments>
		<pubDate>Tue, 10 Apr 2012 14:10:47 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[ゲーム基板]]></category>
		<category><![CDATA[同期信号]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=666</guid>
		<description><![CDATA[JAMMA規格がない頃の基板ですね。 1フレーム分の同期信号がこちら。 ミスタードリラー2基板との大きな違いは、垂直同期信号が出力されている間は水平同期信号が出ていないということでしょうか。それから同期信号のレベルが基板出力の段階でTTLでHiが+5Vになっています。 垂直同期期間は16.499us～16.5000usでした。周波数にすると60.6060&#8230;Hzです。この時期のナムコ基板はこの映像周波数のゲームが多かったようです。 さて、ここまで色々な同期信号をみてきましたが、他に気になる基板は垂直走査周波数が55HzのIREM系でしょうか。表示領域の走査線本数が256本で一般的な240本よりも多めです。ただ、測定するまでもなく、イメージファイトの取扱説明書には映像信号のタイミングが細かく記載されています。 あとは、残念ながら所有していないのですが、映像コンバータを使うと画像がゆがむ事で有名(?)なグラディウスIIの映像信号もいつかはみてみたいですね。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/666/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>映像信号を測る / ミスタードリラー2基板</title>
		<link>http://www.retropc.net/mm/archives/644</link>
		<comments>http://www.retropc.net/mm/archives/644#comments</comments>
		<pubDate>Tue, 10 Apr 2012 11:15:07 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[ゲーム基板]]></category>
		<category><![CDATA[同期信号]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=644</guid>
		<description><![CDATA[ミスタードリラー2基板の映像信号をオシロで眺めてみました。古いゲーム基板は、最近の液晶モニタだと映らないとか各種コンバータを通すと映像がおかしくなるとか録画できないとか言われるように、基板によって映像信号が異なります。電圧レベルだけでなく同期期間もバラバラなのですが、一昔前のブラウン管モニタ側も厳密ではない映像信号をそれなりに表示してくれましたし、モニタ側で表示状態を調整することができたので、それほどには問題になりませんでした。 ミスタードリラー2は2000年7月に発売された基板です。JAMMA VIDEO規格 第三版[PDF]の改訂発行日よりも後に発売ということになりますから、映像信号はJAMMA VIDEO規格から大きく外れてないんじゃないかなと思うのですが、さてどうでしょう。 今回はミスタードリラー2のテストモードを表示したままでの測定です（一応、ゲーム中でも同期信号に変化が無いことは確認しました）。 ミスタードリラー2の映像同期信号は複合同期です。垂直同期信号と水平同期信号が1つの信号線から出ています。水平同期信号が規則的に並んでいる中に垂直同期信号が垂直走査周波数の間隔で入ってくるような波形になります。垂直同期信号部分を拡大したものがこちらの画像です。 水平同期信号（水平同期パルス）の間隔1つ分が水平映像信号1本分の時間になります。垂直同期信号は走査線3本分の幅があり、その前後に垂直同期信号と同じ幅の等価パルスがあります（画像では左側の前等価パルスが見切れてしまっています）。同期信号だけみるとNTSCやコンポジット映像信号と同じです。 JAMMA VIDEO規格では映像信号の出力レベルはTTLレベルでHiレベル電圧は2.4Vから5.0Vの間となっています。画像をみると、ミスタードリラー2基板では、2.2Vくらいなので足りていないのですが、測定時につないでいる機器の影響を受けたのかもしれません。 普段、基板で遊ぶ時は自宅にあるSHARPのCZ-600DEというブラウン管モニタを使っています。これはアナログRGB対応モニタなのですが、垂直同期・水平同期が分離している信号しか扱えないので、アーケード基板のような複合同期信号の映像を映すことができません。そのため、複合同期信号を垂直同期信号と水平同期信号に分離しています。信号の分離には、LM1881NというICを使っています。秋月電気通商の通販ページにLM1881NのデータシートPDFがあり、これをみるとどのように映像信号が分離されるのかわかります。LM1881Nは複合同期信号を垂直同期信号と水平同期信号に分離するICと説明されていますし、私もそう思っていましたが、PDFをみると、コンポジット映像信号からコンポジット同期信号（複合同期信号）と垂直同期信号を取り出すICのようですね。 せっかくなので、LM1881Nで分離された2つの同期信号もみてみました。 赤い線が垂直同期信号、青い線が水平同期信号です。2つの信号レベル同じで重なってしまうので、垂直同期信号側のレンジを倍にしてあります。垂直同期信号を拡大したものがこちらです。 よくみると、赤い線の垂直同期信号の開始タイミング（立ち下がり）と、元の複合同期信号に含まれる垂直同期信号の開始タイミングにズレがあるのがわかります。LM1881Nは複合同期信号内の垂直同期信号を検出してから、垂直同期信号を分離出力し始めるので、その検出時間分だけのズレがおきるのですね。この時間は水平映像信号の長さの半分になるので、LM1881Nを使うと走査線0.5本分の時間だけ垂直同期タイミングがズレることになりますが、ものすごく短い時間ですし、水平同期信号は変わらないのでモニタに出力される内容に変化はないはずです。 ちなみに、垂直同期信号の幅はLM1881Nのデータシートに記載されていて約230usとなっていますから、元の垂直同期信号の幅とは関係なく固定のようです。 同期信号と一緒にRedの映像信号もみてみました。本来、RGB映像信号はAC結合なのですが受け側に使う手元にコンデンサが無かったので波形をざっと眺める程度ということで。 ミスタードリラー2は、テストモードからゲームの設定を変更できますが、設定の中に表示モードの変更というものがあり、インタレースとノンインタレースの切り替えが出来るようになっています。これまでの波形は全てノンインタレースのものでしたが、インタレース表示に切り替えると波形がどうなるのかみてみました。 NTSCと同じように、フィールド毎に水平映像0.5本分だけタイミングがずれるのがわかります。ただ、垂直同期毎にトリガーをかけて連続してデータを取り込んでみると、このズレた信号が交互に出てこないことが頻繁に起きています。オシロのトリガーにひっかからない場合があるのかな、よくわかりません。 ノンインタレース時の水平同期期間は約63.553usでした。15.734KHzくらいです。水平同期期間を測るには手持ちのオシロの帯域幅の限界もあって、残念ながら細かいところまでは測定できません。 垂直同期期間はノンインタレース時が約16.715msでした。59.82Hzくらいでしょうか。インタレース表示に切り替えると垂直同期期間が変化して約16.682ms、約59.94Hzでした。 この59.82HzをGoogle検索してみると、PlayStation2エミュレータとして有名なPcsx2のソースコードがひっかかります。、これによると、PlayStation2のノンインタレース表示は59.82Hzとコメントされています。また、PlayStation2のインタレース表示時は59.94Hzになるようで、先ほどの測定結果と同じです。ミスタードリラー2基板はPlayStation互換のシステム基板でGPUには後期のPlayStation(9000)と同じCXD8561CQが使われているようですから、フレームレートからもハードの関係性がちょっとだけ見えてきますね。]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/644/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>XAV-2s</title>
		<link>http://www.retropc.net/mm/archives/192</link>
		<comments>http://www.retropc.net/mm/archives/192#comments</comments>
		<pubDate>Mon, 01 Jun 2009 08:17:53 +0000</pubDate>
		<dc:creator>moriyan</dc:creator>
				<category><![CDATA[ゲーム基板]]></category>

		<guid isPermaLink="false">http://www.retropc.net/mm/?p=192</guid>
		<description><![CDATA[マイコンソフトから発売されているXAV-2sが手元にあるのですが、購入時から開封もしていない状態でした。それでつい最近、ゲーム基板のプレイ映像をハードディスクレコーダで録画してみようと思い、基板の15KHｚ RGB出力をXAV-2sに接続してみたのですが、その際にXAV-2sの取扱説明書を見たところ、これがまぁ、非常にマニアックな内容なのですよ。 ゲーム基板のRGB出力は、様々な仕様があり、きっちり規格のビデオ/S端子出力とは相性がよくないものがあるのです。それらに対応するため、XAV-2sでは、このゲーム基板ではこうしなさい的な設定表が記載されているのです。普通のダウンスキャンコンバータでは「規格外の信号には対応していません」で済ませてしまうところを、あえて書く、マイコンソフトのそういうところが好きです。そのマニアックっぽい取扱説明書の対応表から引用すると、XAV-2sでは次のゲーム基板について動作確認されているようです。 メーカー 名称 シャープ X68000 富士通 FM TOWNS 各社 MSX ナムコ システム86 ナムコ システム1 ナムコ システム2 ナムコ グロブダー ナムコ バラデューク カプコン CPシステム カプコン CPシステムII カプコン サイドアームズ コナミ 極上パロディウス コナミ ゼクセクス コナミ ガイアポリス コナミ 出たなツインビー コナミ エイリアンズ コナミ 究極戦隊ダダンダーン タイトー F-2システム(大) タイトー F-2システム(小) セガ システム18 セガ システム16A セガ システム16B セガ システム32 セガ ギャラクシーフォース 東亜プラン [...]]]></description>
		<wfw:commentRss>http://www.retropc.net/mm/archives/192/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
