今回珍しくハードウェア設計が出来る方がいらっしゃったので基板の設計について話をさせていただきました(実際の所聞いてもらっただけかも知れませんが...).
UperGrafx の基板を最初に作ってからもう1年半経過しておりまして、久しぶりにそういう話ができて開発のやる気が戻った気がします.
upergrafx開発近況
CD-ROM2 の基本機能は大まかに下記がありまして大体実装しました. 回路規模は EP2C5 の9割でぎりぎりでした.
- CD ドライブ制御 (仮想対応も含む)
- ADPCM
- RAM 制御
- 音声更新頻度制御
- 音声再生機能
- fadeout
ADPCM はソースを書いて実機動作 1 回目で音声がでたので油断しておりましたが結構難しいです. 音声再生は MSM5205 がやっていてこれのデコードはそんなに難しくありません. 問題はこの IC はメモリ制御機能がないため、各自の周辺回路に依存いたします.RAM 制御機能はCD-ROM2 独自の機能であり重要度が高いです. しかし動作は複雑で資料があまりありません. いくつかあるPCEのエミュレータのソースコードは源流は1つだけのようでコアの部分はみんな同じでよくわかりません....
fadeout と更新頻度制御は時間管理,クロック分周などの回路で構造は難しくありませんが、クロック近似のために精度を出すと桁数が増えるので回路規模が大きくなりがちです. fadeout は乗算器もあります.
ボイス機能はある程度実装したのでボイス再生完了待ちで停まるような部分はなくなり、わりと遊べるソフトも増えてきました. その一方で途中で止まってしまうソフトも結構多く、どう対応していくか悩んでおります.
upergrafx開発近況
下書きとしてここに書いてましたが清書しました → http://www.upergrafx.com/cdrom2_ja
CD-ROM2 向けの開発以外にやること - discimage 管理
これは PC 向けのソフト開発が必要で協力していただける方がいれば手伝って欲しいです.
- 実 CD の image 作成のソフト開発
- 実メモリカードの制御で効率よく転送する方法
両方とも有用な資料の提供など相談や質問に乗っていただける方がいれば作業時間を縮めることが出来ると思っています.
CD image に関しては dump (subchannel Q とか Audio Data のバイトオーダーとか TOC の取得方法), メモリーカードに関しては filesystem なしで書き込む方法です.
メモリーカードの filesystem は書込みはイメージが完全に連続した状態を保証することが必須で, fat16/fat32 互換で読み込みもできたら便利かなと考えています. 現状では msys2 から /dev/sd* を fopen() して書いているのですが明らかに書込みが遅かったり fflush() をいれないと書込みミスするけどどれくらいの頻度でいれていいのかわからないし、そもそも /dev/sd* がない OS なんだけど... とかそういうことになっております...
再生産の準備が終わりましたら UperGrafx 内部の CD-ROM2 互換機能以外にもこれらのPC用ソフトの準備も必要です. 新機能の提供の作業は全体的に見ますと終わりは全く見えていない状態です.
upergrafx開発近況
ソースの書き直しと入念なテストは終わりました. 現在実機で動かすための準備をしております.
あまりにも書き直し期間が長くてつらくなっておりましたが、なんとかなりそうです.
ゴルフっ子オープンのイベントを出した
小夜ちゃんの出し方がわかったみたいですのでその命令周辺を調べました.
データの構造が専用のスクリプトデータになっているため命令をみながら詳細な条件を得ることは難しそうです. スクリプトデータの解析はどなたかやってくださいませんでしょうか...
イベントは無理矢理出すことが出来ましたのでパッチを作りました.
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: プロにおこられる
1: ひとみにおこられる
2: じいさんがいじける
3: じいさんがつりをする
4: ちょーさんがくらぶを賭ける
5,6: 4の結果
ゴルフが強制的に終わるのででないようにしてます
7: ようかいスライスがでる→あしゅらが登場
8:うさぎがでる
9,10,11: ホールインワン
12: はしりタイがでる→小夜が登場
13: ちえみが水着姿になる
14: 小夜が水着姿になる
15: おじさんにプロテストを薦められる
16: プロにおこられる
17,18: ひとみになすをもらう
19: 池から宝船が出る
20: 怖い人にクラブを取られる
21: 怖い人からクラブを取り返す
22: ホールインワンもどき
23以降: 別のイベント?
小夜かあしゅらを出した後に再ゲーム
パスワードを入れるかゲームを終了しやり直すと対戦相手として追加キャラが選べます.
開発近況
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週間ぐらい時間を浪費してしまいました...
上記の占有時間の計算はこの機能を停めての値ですからこの機能を有効にしたら占有率は上がります.
改修方針
性能の限界 (内部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がうごく設計でエミュレータで動かすと簡単です,ただしエミュレータ特有の欠点がでます)
ご注意
本日の記事は作業方針の確認の目的に書いてますのでその内消えます.
unagi flashmemory cartridge hikiを暫定的に復旧しました
http://unagi.osdn.jp/cgi-bin/hiki/hiki.cgi
運営情報とお願いをご覧ください.
自分としてはたまに見ると資料がまとまっていて便利なのですが、文体がバラバラだったりわかりづらい記述がそのままのため、移行作業をするよりかは新しく書き直した方がいいなとは思っています. しかし個人的都合で作業をすることが出来ません.
