Hatena::ブログ(Diary)

naruko の開発メモ

2017年01月14日

ゴルフっ子オープンのイベントを出した

小夜ちゃんの出し方がわかったみたいですのでその命令周辺を調べました.

データの構造が専用のスクリプトデータになっているため命令をみながら詳細な条件を得ることは難しそうです. スクリプトデータの解析はどなたかやってくださいませんでしょうか...

イベントは無理矢理出すことが出来ましたのでパッチを作りました.

download → https://www.axfc.net/u/3764567

  • 打数がイベント番号になって、1打打つとイベントが強制に発生します.
  • イベント番号5,6,24番はゴルフが終わってしまいます.
  • 無理矢理出してる都合か画面表示の打数と内部の打数の値はずれますのでご注意ください.
  • 本来の条件でイベントが発生した場合はそちらが優先されます. (でないでしょうけど)

ソースは下記でプログラムがわかる方は参考にしてください.

	org	$f7ea
	jmp	new_f7ea

	org	$ff9b
new_f7ea:
	jsr	$f803
	bcs	force_event
	jmp	$f7ef
force_event:
	lda	$0615 ;shot count
	cmp	#5
	bne	n0
	lda	#7
	sta	$0615
n0:
	jmp	$f7f1

以下イベント番号の概要をお知らせします. 設定を無視して別の COM の相手とキャディが出てくる場合はイベントの発生条件になっているものと思われます.

絵は雑にキャプチャしましたので他の方に補完をお願いします.

0: プロにおこられる

f:id:na6ko:20170114021248p:image

1: ひとみにおこられる

f:id:na6ko:20170114021249p:image

2: じいさんがいじける

3: じいさんがつりをする

4: ちょーさんがくらぶを賭ける

f:id:na6ko:20170114021250p:image

5,6: 4の結果

ゴルフが強制的に終わるのででないようにしてます

7: ようかいスライスがでる→あしゅらが登場

f:id:na6ko:20170114021251p:image f:id:na6ko:20170114021252p:image f:id:na6ko:20170114021253p:image

8:うさぎがでる

f:id:na6ko:20170114021254p:image

9,10,11: ホールインワン

12: はしりタイがでる→小夜が登場

f:id:na6ko:20170114021255p:image f:id:na6ko:20170114021256p:image

13: ちえみが水着姿になる

14: 小夜が水着姿になる

f:id:na6ko:20170114021257p:image

15: おじさんにプロテストを薦められる

f:id:na6ko:20170114021258p:image

16: プロにおこられる

17,18: ひとみになすをもらう

f:id:na6ko:20170114021259p:image

19: 池から宝船が出る

f:id:na6ko:20170114021300p:image

20: 怖い人にクラブを取られる

21: 怖い人からクラブを取り返す

22: ホールインワンもどき

23以降: 別のイベント?

小夜かあしゅらを出した後に再ゲーム

f:id:na6ko:20170114043547p:image

パスワードを入れるかゲームを終了しやり直すと対戦相手として追加キャラが選べます.

upergrafx開発近況

ソースの書き直しと入念なテストは終わりました. 現在実機で動かすための準備をしております.

あまりにも書き直し期間が長くてつらくなっておりましたが、なんとかなりそうです.

2016年12月31日

開発近況

frame buffer の空き時間を作る

Video 機能の作り直しですが、大枠はできましてある程度シミュレーションが通っております. 一番の目的である frame buffer の占有時間を凝縮させて空いた時間は MCU に使わせる目的は達成できそうです.

frame buffer の video 側の占有率は 720p での 1frame あたりで下記となっております.

dotclock = master clock / div
div 占有率
2   47%
3   32%
4   27%

この値はシミュレーション上での結果で細かい条件は占有率が多めになるものを選んでおります. div = 2 の条件は使うソフトが限られているので切り替えをいれると MCU に割り当てられる時間は 1frame あたり大体 6 割強だと思って良さそうです.

今回の作り直しによって、現状の製品版では潜伏していたバグが見つかり、それらはきれいに対処できました.

両端に好きな画像を入れる

これも作ってある程度動いてるのですが、専用データを作る価値がなさそうではと思っております.

内部RAMの使用率を下げるために作成したら構造が異様に複雑になってデバッグにも苦労しましたし、そもそもこれは本当に必要な機能でもないです. 無駄に1週間ぐらい時間を浪費してしまいました...

上記の占有時間の計算はこの機能を停めての値ですからこの機能を有効にしたら占有率は上がります.

当面の予定

大枠ができましたので細かいシミュレーションでちゃんと絵を出せれば、実機で映像機能の確認となります.

去年と違いまして試行錯誤はないし、テストに使える計測データも多いのでじっくりテスト環境を作って進めて参ります.

映像機能の実装が終わってから、 MCU に frame buffer を割り当てるための設計とデバッグがあって、ソフトの構造を組み直して、そこから CD driver の開発再開となりまして... 先は長そうです...

日本電気の半導体データブックを買ってみた

PCE とは関係なくオークションで結構いい金額を出して買ってみました.

内容は当時の家電(VHS とか電話機とか)や自動販売機に入ってそうな部品の説明がかなり多いです.

英語版で手に入る pdf がなければ電子化したいところですがどうしましょう? と思ってます. 私が欲しい分野外でも需要はあり困ってる人には提供したいと思いますが、高級オーディオの目的だったらどうしましょう...

分野についての所感は後日に行うつもりです. ただオプトエレクトニクス(LED とかフォトカプラ)とロジックIC40xx,45xxシリーズは現在新規設計や保守をするには当時の日本電気の部品である必要はないでしょう.

2016年12月20日

ご注意

本日の記事は作業方針の確認の目的に書いてますのでその内消えます.

改修方針

性能の限界 (内部RAM不足)

最近の機能追加は CDDA で、そのためには大まかに Compact Disc の仕様調査とディスクイメージの仕様検討と外部音声機能のハードとしての追加が重要となります.

その過程で FPGA 内部の CPU(MCU) のソフトウェア量がどんどん増えていき、ユーザーの利便性より(あとで改善できるのでいまは重要ではないと判断した)も構造の簡素化を選んでそれを抑えておりました.

システムカード内蔵の CD Player と連携して動くところまできて、次はデータ転送かと思いきや、ソフトウェアの RAM 消費量を落ち着いて見たら限界に達していたというのが主な原因です. Cyclone II はあまり高性能ではないため内部RAMも対して大きいわけではありません.内部RAMは専用のデータをハードウェアで使う小回りが効く部品として使うべきであり、ソフトウェアが使うには容量がいまのパソコンのRAMに比べると笑っちゃうほど少ないのです.

ここでいう MCU は HuCard のみの対応では UperGrafx の周辺ICの初期化(I2C)や通信(USB-serial)という単純な役割だけでした. MCU は PCE にはできるだけ本来の動作に影響なく動作させることが目的のため、 PCE の CPU (6280) に MCU の役割をさせられませんし、 PCE が使う RAM を使うこと(6280を一時停止させる以外に)はできません.

frame buffer を MCU 兼用とする

RAM の代替先の選定は候補があまりないので、部品交換か基板作り直しが案になっておりました. ユーザーや販売の立場からはこれは受け入れられませんでした.

その中出てきたのが frame buffer です. これは現状 Video の目的だけで使っております. 容量はほぼ半分(0x40000byteぐらい)空いており、暇な時間も多いのはわかっておりました.

この暇な時間を MCU に割り当てると 0x1000 byte の容量で難儀している分野で 0x40000 byte も自由に使えるのは性能の限界をなくすことができます.

また Video のソースコードは試行錯誤の段階から徐々に直していったこともあり内部構造があまりきれいではありません. この部分の最初からの作り直しは優先度の低い作業でしたが、 MCU 兼用としながら作り直すというのはとても意義があることになりました.

両端の余白の作り直し

この部分は展示のみ文字列をだしておりましたが、内部RAMを使っていたのですが使えなくなりました. MCU が利用する分を抜いても frame buffer の空きがあるので好きな絵を載せることができるように検討しました.

ここの領域は 88x720 pixel が 2 つあり、色の深度は RGB 各5bit が利用できます(PCEは RGB 各3bitなので余っている部分は有効に使えてない). そうすると縦幅は狭いですけど写真も載せられそうと思ってました.

実際にソースを組み始めたところ転送時間の計算を忘れておりました... 720p での 3 scanline の表示時間の frame bufffer 占有率を概算すると下記になっておりました.

  • VCE data read (write も大体同じとする)
    • 15.5% 分周値4
    • 20.7% 分周値3
    • 31.0% 分周値2
  • 余白部 pixel data = 輝度値
    • 2.7% 1bit (モノクロ)
    • 8.0% 3bit (RGB各1Bit)
    • 16.0% 6bit (RGB各2Bit)
    • 24.0% 9bit (RGB各3Bit)
    • 32.0% 12bit(RGB各4Bit)
    • 40.0% 15bit(RGB各5Bit)
  • 余白部 pixel data = index
    • 3.0% 1bit (パレット2色)
    • 6.0% 2bit (パレット4色)
    • 9.3% 3bit (パレット8色)
    • 13.3% 4bit (パレット16色)
    • 18.5% 5bit (パレット32色)
MCUの利用時間占有率 = 100% - VCE data read+write 転送占有率 + 余白部占有率

上記は余裕を持った概算値ですがこの時点でRGB各5bitで1pixel単位描画は無理でした... RAM 容量の空きはきっちり計算した分がっかりしました...

パレット経由方式で8色や16色でそれなりに絵がでるかも確認したのですが、RGB各5bitとはいえ同時発色数が少ないので無理がありました. 占有率もできるだけ小さい方がいいと考えると index 2bit が現実的な値なようです. 結局用途は広告欄にしかならないようでした.

余白の実装はユーザーにとっては重要ではない機能なのでこれぐらいにいたします. (こういう場面は内部がソフトとしての性能が高いLinuxがうごく設計でエミュレータで動かすと簡単です,ただしエミュレータ特有の欠点がでます)

2016年10月17日

unagi flashmemory cartridge hikiを暫定的に復旧しました

http://unagi.osdn.jp/cgi-bin/hiki/hiki.cgi

運営情報とお願いをご覧ください.

自分としてはたまに見ると資料がまとまっていて便利なのですが、文体がバラバラだったりわかりづらい記述がそのままのため、移行作業をするよりかは新しく書き直した方がいいなとは思っています. しかし個人的都合で作業をすることが出来ません.

2016年09月03日

HuCard の memory mapping

hardware address (21bit) と software address (16bit)

CPU は 16bit address として動きますが、内蔵された memory controller によって 21bit address に変換されます.

仕様を説明した文書によっては CPU address でのみ記述されていることもありますが、どちらのアドレスが書いてあるのか判断できない場合があり混乱の原因となります.

software 16bit address 空間は 0x2000 byte 単位で区切られた 8 つの banked area を持ちます. この文書では CPU がアクセスする banked area を CPU bank, 各 banked area で切り替えられる値を CPU page と呼びます (これも文書によって定義がバラバラで混乱する, よくあるのは区別せずに両方とも bank になってる).

softaddress name
-------------------
$0000-$1fff bank #0
$2000-$3fff bank #1
$4000-$5fff bank #2
$6000-$7fff bank #3
$8000-$9fff bank #4
$a000-$bfff bank #5
$c000-$dfff bank #6
$e000-$ffff bank #7

hardware 21bit address 空間は software address と各 bank の page の値を合成した値になります. このaddressによってCPUがどのデバイスにつながっているかわかります.

page hardaddress 
----------------------
0x00 0x000000-0x001fff
...
0x7f 0x0fe000-0x0fffff
...
0xff 0x1fe000-0x1fffff

PCE 回路としては page 0xf8 から 0xff に RAM や VDC/VCE の内部デバイスがつがっていて、 page 0x00 から 0xf7 は外部デバイスが自由に定義できます.

HuCard の hardware address 定義

実際に使われた HuCard は page 0x00 から 0x7f を使っています. この領域を大きく 2 つに分けています.

page      hardaddress       device
-------------------------------------
0x00-0x3f 0x000000-0x07ffff memory #0
0x40-0x7f 0x080000-0x0fffff memory #1

注意したいのが HuCard のコネクタには CPU address bus は全て配線されているので全領域に device を配置することができます. 市販品はこれ以外も実装できるのにその必要がないのでやってないだけです.

Hucard 種別その1: ROM #0 だけ

2Mbit (0x40000 byte) 以下と 4Mbit(0x80000 byte) の容量での設定です.

ROM memory #0 の領域に満たせない場合は mirror となります.

page      hardaddress       device
-------------------------------------
0x00-0x3f 0x000000-0x07ffff ROM #0 (readonly)
0x40-0x7f 0x080000-0x0fffff ROM #0 (mirror, readonly)

Hucard 種別その2: ROM #0 と ROM #1

3Mbit (0x40000+0x20000byte), 6Mbit(0x80000+0x40000byte), 8Mbit(0x80000+0x80000byte) の容量での設定です. 各領域の容量を満たさない場合は ROM #0, ROM #1 ともに個別に mirror があります.

page      hardaddress       device
-------------------------------------
0x00-0x3f 0x000000-0x07ffff ROM #0 (readonly)
0x40-0x7f 0x080000-0x0fffff ROM #1 (readonly)

Hucard 種別その3: ROM と RAM

Super System Card, Populus にあります. mirror の部分も同じ. 天の声バンクとアーケードカードは調べてないので違うかも.

page      hardaddress       device
-------------------------------------
0x00-0x3f 0x000000-0x07ffff ROM (readonly)
0x40-0x7f 0x080000-0x0fffff RAM (read and write)

Hucard 種別その4: Street Fighter II' Champion Edition

page      hardaddress       device
-------------------------------------
0x00      0x001ff0-0x001ff3 ROM #1 bank register (writeonly)
0x00-0x3f 0x000000-0x07ffff ROM #0 (readonly, fixed)
0x40-0x7f 0x080000-0x0fffff ROM #1 (readonly, banked)

ROM #1 容量が hardware address 空間を越えてますので, CPU とは別の bank 切り替えが発生します. ROM #1 は 4 page を持ちます.

hardaddress assignments
-----------------------------
0x001ff0    ROM #1 set page 0
0x001ff1    ROM #1 set page 1
0x001ff2    ROM #1 set page 2
0x001ff3    ROM #1 set page 3

ROM #1 の bank register は絶対 address です *1. 各 register に書く data は無関係で, address によって同じbank の page を選択するという珍しい実装になっています.

*1:$1ff0-$1ff3 と書いていた文書に腹が立ってこれを書いた