CD image を可逆圧縮して保存する

この手の開発をしていると CD image を HDD に大量に保存する必要がありまして、結構容量を食います. 圧縮するにも可逆圧縮でないとデバッグが不完全になってしまいます.

これらは全てコマンドラインシェルスクリプト経由で運用する流れです.

chdman で固める

chdman は MAME に付属するディスクイメージを固めるソフトだと思います. CD image の場合、DATA は deflate (たぶんzlib), Audio は flac で固めますので可逆圧縮です.
MAME なら固めた chd ファイルからも起動できます. (しかし,家庭用ゲームを遊びたい人が MAME を選択するのはないでしょうね... PCE のエミュレーション精度も理由があってあんまよくないですし)

前回の cdmanipulator で作ったファイルも固められます. .cue と .img が必要です.

 chdman createcd -i hoehoe.cue -o hoehoe.chd

7za で固める

.img はこの段階で削除可能なので、.chd .sub .cdm を 7za.exe で固めます.

 7za a hoehoe.7z hoehoe.cue hoehoe.cdm hoehoe.sub -mx=7
 7za a hoehoe.7z hoehoe.chd -mx=0

.sub と .cdm は圧縮率が高いデータになりますので -mx=7 で固めます. .chd はすでに圧縮したファイルですので圧縮しない -mx=0 で 7z ファイルに入れ込みます.

この行程で元のファイルからの中身にもよりますがファイルサイズが 50% 程度になります.
ys1&2 の img ファイル(766,702,608 byte)を zip,7z,chdへ圧縮した場合の処理時間と圧縮率比較です.値は共に少ない方が優秀です.

 zip 37sec 91%
 7z  53sec 86%
 chd 93sec 62%

圧縮ファイルから戻す

 7za x hoehoe.7z
 chdman extractcd -i hoehoge.chd -o hoehoe.chd.cue -ob hoehoe.img

chdman の -o オプションで .cue の文字列を含める必要があります. これをしないと audio の byteorder が圧縮前と逆になります. これはドキュメントには書いてなくてソースコードから確認しました.
-ob は付けないと拡張子が .bin になりますので全く同じにしたいなら .img にしたほうがいいでしょう.
cue 自体は別途ありますので .chd.cue にしてます. おそらく一緒の中身がでてくると思いますが詳しくは知りません.

補足:Audio の byteorder

.img のフォーマットは CDRWIN 発祥でそこで Audio の byteorder は little endian と決められたようです. イメージを作るソフトも多分それにならって little endian に統一されています.
実際の CDDA では bigendian で書き込まれているようです. CD の多バイトデータは bigendian で構成されているのがほとんどで CDDA だけ little endian にするのはちょっと考えられないです.
そこらへんがあって少し混乱があったようです.

Super System Card 内蔵本体レジスタの予測

DUO シリーズと PI-CD1 の仕様の考察です. Games Express CD Card の対応をしていて気になった記述がありました.

games express cd card (blue)
00F8C6: 
	cli
	lda	$18C1 <- レジスタの読み込み
	cmp	#$AA
	bne	$F8EB
	lda	$18C2 <- レジスタの読み込み
	cmp	#$55
	bne	$F8EB
;レジスタがあったので初期化
	lda	#$AA
	sta	$18C0 <- レジスタへの書込み
	lda	#$55
	sta	$18C0 <- レジスタへの書込み
	lda	#$68
	sta	$2204
	lda	#$20
	sta	$2205
	bra	$F8F5
00F8EB: ;レジスタがないので旧システムと判断
	lda	#$80
	sta	$2204
	lda	#$08
	sta	$2205
00F8F5: 
	lda	#$01
	tam	#$40

CPU address $18cx は絶対 address 0x1ff8cx のことです.
read のレジスタは HuCard の Super System Card にも存在し、 BIOS でも参照してます. ここに無効な値をデータバスに出すと起動画面で SUPER の文字がでなくなって旧システムと判断するようです.

HuCard の Super System Card 内部には下記の IO があります. 全て mirror を含んだ絶対アドレスでの記述です.
絶対アドレス

0x000000-0x07ffff ROM
0x080000-0x0fffff RAM 
0x1ff8c0-0x1ff8cf register

内蔵機種の場合 HuCard (相当品も含む)挿入でこれら全てが無効になると思いこんでたのですが, ROM と RAM を無効にして register は無条件で有効のようです. *1
この BIOS の書込みをから想像するに 0x1ff8c0 に上記の値を書き込むと HuCard が挿入されていても内蔵 RAM が使えるようになるみたいです. なぜなら Super System Card の BIOS ではこのレジスタ領域は読むだけで書くことはありませんでした. さらに HuCard の Super System Card では RAM は必ず有効になるべきなので, 本体内蔵機種でのみ意味があるレジスタになります. *2

UperGrafx では標準状態で address 0x1ff8cx の read レジスタは HuCard のほうを使うようにしています. Games Express 専用モードでは read レジスタも UperGrafx から出力することと 0x0d0000-0x0fffff の RAMを使えるようにして CD 麻雀美少女中心派が起動できることを確認しました.

*1:これを非公式メーカーが何故知っていたのかが疑問です

*2:HuCard の Super System Card でも Card 挿入端子をみて有効無効を決められますが... 合理化すると中身全く一緒のほうがいいのかも?

cdimage 作成の手順と注意

UperGrafx 内蔵の CD-ROM2 互換機能ではメモリーカードに cdimage を転送した状態で運用します.

手順

  • cdimage の作成は PC から CD-ROM が読める drive を接続して行ないます.
  • cdimage の作成ソフトは CDManipulator を利用します.
  • 作成したイメージファイル (拡張子 .cdm, .img, .sub) を専用ソフト(後日提供予定)から専用パーティションへ無圧縮で転送します.
    • エクスプローラからファイルをコピーする手順ではありません.
    • CDManipulator 作成のデータ限定での対応です. 他ソフトが作成した cdimage を転送するプログラムを書いてくれる人がいらっしゃるなら転送ソフトのソースコード提供をしようと思います.

CDManipulator の設定

画像のようなオプションにしてください.

  • マルチセッションモード (これはシングルでもいいと思う)
  • 高度な設定を選択
  • プリギャップ解析を「しない」
  • 正しいTOCとギャップ情報の取得を「しない」
  • エラーの無視を「する」
  • 残り2つはわたしにはよくわかりませんので好きにしてください.

正しいTOCとギャップ情報の取得をしない理由

このオプションは Compact Disc の規格違反だった場合は厳格な情報に補正する機能です. おそらくこの目的は CD-R ドライブ一般普及時の CD コピー対策で意図的にエラーを混ぜた disc への対処だと思われます.

HE システムの CD-ROM の場合は規格策定がされたであろう1988年頃の設計で運用されており意図的なコピー対策ではありません (CD-R どころかファイルシステムさえ存在していない時代です).

この問題の原因は audio track の次に data track がある場合のギャップ領域の管理データとTOCの相違です.
例としてうる星やつらでは TRACK 2 にはギャップ領域である index 00 とデータ領域である index 01 の2つが存在します. TOC には index 01 の開始時刻は 00:47:71 と書かれていますが、実セクタの管理データでは index 01 は 00:47:70 から始まっています.
subchannel の該当データ. index01 は 00:47:70 から始まっている(管理データの時刻はBCD表記で実データから2秒加算した値で運用する). 色をつけたデータ順番に 02->track, 01->index, 00->時刻(M), 49->時刻(S), 70->時刻(frame)


mainchannel 00:47:70 のデータ. 管理データに補正するとここを参照し意味がないデータが出てくる.


mainchannel 00:47:71 のデータ. ヘッダがありこちらを読み込めば起動する.

この相違があった場合には HE システムの CD-ROM としては TOC を優先しますが、image作成のオプションでは管理データを優先して補正します. この相違はおそらく 1988年頃の Compact Disc の規格としては許容されるエラーと私は考えています.

大半の CD-ROM2 disc では TRACK 2 の TOC が HE システムのCD-ROMとして正しい値を得られれば正常に起動します. disc の末尾に予備として data track がありますがここにもTOCと管理データの相違がある可能性があります. ただしTRACK 2 が正常に読めれば利用されないので問題になりません.


1 つの disc に 3 つ以上の data track が存在する場合はこの相違が data track の数だけ疑いがあるので必ず補正されていない TOC を優先する必要があります.
例えば迷宮のエルフィーネは data track が 22 個もあり, このオプションを有効にすると補正が大量にかかりますが、 TRACK 2 は問題ないので起動はするものの絵がおかしくなります.
(左がTOC準拠、右が補正されたもので違いが大量にある. これは data track のみを抜粋した比較であり, audio track を含めると相違点が大量にある. audio は2/75秒程度ずれていても人が違和感を感じないはずで動作には影響が少ない)


エラーの無視をする理由

ディスクが物理的に損傷していない場合、いままででたエラーを見るとギャップやloadout領域の規格違反ばかりでした. CD-ROM2 システムではギャップやleadout領域のデータを見ることはありませんので無視して構いません.
エラーも含めて精度の高い完全なイメージを作りたいという話だとCD-ROM2互換機能開発の目的からそれていきますので光学ディスクの専門家を探して相談してください.

upergrafx cd 互換機能ソフト個別リスト

https://docs.google.com/spreadsheets/d/1wsMjm5DMLgWVzfab49cX-TYCAgx0fXAiLJ6UL7AwNAM/edit#gid=1608184984
致命度は低い物の(つまりなぜかとまらない)重要な問題をいくつか直しました.

command 0xdd, 0xde

databus を hardware handshake にしてから安定していませんでした.
この2つはゲーム起動後には安定しなくても動いていたのが謎でしたが、 0xde のほうは起動時のみ, 0xdd は CD player ぐらいでしかつかわないのでゲーム起動中はあまり関係がないということでした.

hardware handshake の不安定の原因は6280バスの監視の設計が根本的におかしかったことが判明しましたので直しました.

adpcm status (その1)

通常 ADPCM は再生完了の割り込みを受けてレジスタを再度更新するはずなのですが、割り込みを受けないソフトの対応をしました.

0x1ff80b.w = 1


6280 からみてwrite 側の対応よりかは read 側の対応も必要でした.
これにより HCD5080 (銀河婦警伝説) と HCD4067 (がろすぺ) がまともに遊べるようになりました. HECD6026 (てきぱき)はいままでまともに起動しませんでしたが、オープニングが動いてゲーム本編でいきなり停まるところまでです.
がろすぺとてきぱきは問題のBIOS外でのレジスタ操作の部分のソースがまったく同じでソースを流用した可能性があります. *1

0x1ff80b.r 側の対応をしたためなのか charawrong がいくつか改善しています. NAPR-1018 (download2) は全く直ってないので別の原因かもしれません. これは毎回起きるわけではなかったのでしばらく様子見です.

fadeout

fadeout 完了後に音量が0%の場合にもう1度 fadeout とすると音量が100%に戻ってfadeoutをし直すという問題の対応をしましたがこれが不十分で、銀河婦警伝説はそこがおかしくなりました. ゲーム本編はまったく問題ありません.

adpcm status (その2)

途中で adpcm が再生できなくなっておかしくなっていました.
原因は state machine の state で fifo の empty での条件更新が同じ複数レジスタが一部矛盾していました(まれに発生). empty flag を 1 度 latch してから条件にいれたら安定しました. これは warning で文句いうのか伝搬遅延で高い値がでるはずなんですが、見落としてたのかもしれません.
ただ empty flag の使い方は複雑な条件を混ぜてるわけではなく, dual clock fifo の write 側の empty を見ているので勝手が違うのかもしれません. (通常は empty を見るのは read 側が大半)

*1:意外なことに餓狼2とがろすぺのソース流用はないらしい

upergrafx cd 互換機能ソフト個別リスト

確認数が増えたため csv で管理することにしました. 内容は公開いたします.
https://docs.google.com/spreadsheets/d/1XPKLQS6xKoB1jTkHLnzNVm1AlEISMRddpeVPh7q6Ey4/edit#gid=398211885

  • 型番及び名称は mame に付属している hash/pcecd.xml から抽出し、一部手直しをしています.
  • マイナーバージョンの違いは区別しません.
  • ADPCMの音割れは影響範囲が多いため個別ではなく全体の問題とし、個別リストには記載しません

A列:型番

B列:upergrafxでの動作状態

  • (空欄): 未確認
  • ok: 5分ぐらい動作して問題なし
  • bad: 不具合があるが、動作は停まらないなど軽微なもの
  • freeze: 停まる
  • toc ng: disc dump 時で toc が自動補正されるのか,起動しない.
    • ->: toc を手動補正したあと起動確認後の状態
    • これはおそらく Compact Disc での規格上、厳格な判断では不正な状態になっているもので disc dump 時に自動で補正がかかり toc がずれてしまうと考えています. 正式な対処をするのであれば本物の disc を本物の CD-ROM2 から取得する toc を得てそれを image に記載すれば直ると思われます. つまりそのための PCE 向けのソフトを作る必要があります.

C列:不具合の概要

  • 未調査: 未調査.
  • charawrong: 映像で一部キャラクタが化ける. 化け方は毎回異なり起きないこともあるし激しく起きる場合もある.
  • videononsync: ロード時間が早すぎるのかロード経過表示がとても粗くなる
  • cddadelay: 映像とCDDA音声がずれる
  • nonbios: BIOS 外でのレジスタ操作, これがある場合対処によって動いたり動かなくなります
  • 0x1ff80b.w=1: 通常 2 を write するものの, bios 外から 1 を write する. 1 の現状動作の対処ができていない.
  • adpcmstatus: adpcm での再生の前後で何かしらの不備で停止

D列:名称

upergrafx CD-ROM2 互換機能ソフト別動作確認状況

データ転送方式の根本的改善と致命的な実装不備を2件直しましたので安定度が上がりました. BIOS 外でのレジスタ操作が原因での不具合は信頼性のある対処に時間がかかりますので、一般提供後に内部更新機能を利用して段階的に対応していくつもりです.

7月8日更新: 確認ソフト数を45本から59本に更新しました.

45/59 問題のないもの

起動後5分程度の操作で不具合がないものです.

cjcd4005_sotsugyoushasin_miki
dwcd1001_rayxanber2
glcd4001_advancedvariablegeo
hacd0003_superdarius
hacd9002_sidearms
hcd0015_ys3
hcd2024_starparodia
hcd2025_gateofthunder
hcd3043_cotton
hcd3046_tengaimakyou_kabukiden
hcd4063_worldheroes2
hcd4064_tengaimakyo_dendennoden
hcd5075_gingayuna2
hcd9009_ys_1_2 (補正後)
hecd3003_moonlightlady
hecd4009_madstalker
hecd4010_3x3eyes
hecd5024_deadofthebrain
iccd1001_rtypecompletecd
kmcd2002_snatcher_cdromantic
kmcd2003_gradiusii
kmcd3005_akumajoudraculax
kmcd4007_tokimekimemorial
mccd4005_fraycd
napr-1036_sotsugyou_graduation
napr-1038_puyopuyocd
napr-1049_asuka120
napr1041_striderhiryu
nscd0004_ranma1_2
nscd0005_ldis
nscd1006_ranma1_2
nscd2009_ranma1_2_datou
nscd2013_choaniki
nxcd1004_sereisenshispriggan
nxcd2008_sprigganmark2
nxcd2010_doubledragon2
nxcd3022_motteketamago
nxcd3027_srmp4custom
pvcd-2005_minesweeper
rscd-3002_fiendhunter
thcd3001_sylphia
ticd-4002_hatsukoimonogatari
tjcd0010_legion
tjcd2024_babel
tjcd9004_redalert

3/59 一部問題のあるもの

一部声が割れます.

hcd2031_gingaojosamadensetsu_yuna

読み込みを早くしているためにデータ読み込み画面の更新がよくないです. ゲーム内容は問題ありません.

hcd4061_ryukonoken

システムカードversion2以下での起動画面が高確率で不正なものになりますが、軽い調査では原因不明でした. 進行に問題はなさそうなので保留にします.

hcd3051_ys4

5/59 停まる, BIOS 外のレジスタ操作

6280 address 0x1ff80b.write への書込み処理を簡略化して動いているものが多い傾向です. 0x1ff80d.write への処理も自前でやっている物もあります.似たような不具合を総合的に見て無難な形にする予定ですが、最終的には実物での動作を分析して互換性を上げたいところです.

hcd4067_garoudensetsuspecial
hcd5080_gingafukeidensetsu_sapphire
hecd6026_tekipakiwarkinglove
jccd9001_kagaminokuninoledgend
napr-1034_calii

5/59 停まる, 詳細未調査

hcd5078_yunahv
nxcd2016_srmspecial
nxcd3028_mahjonglemonangel
tjcd2022_mirashounenkonan
tjcd2023_mugensenshivalis

2/59 イメージの作成に問題

TOC の値が規格と少しずれているらしく、イメージ作成ソフトが誤って補正しているのかなどイメージ作成の過程で調査が必要です.

hcd9009_ys_1_2
tjcd0008_meikyuunoelfeene

upergrafx CD-ROM2 互換機能ソフト別動作確認状況

システムカードは本物を使ってますのでそれが原因で動かないということはないです.

ある程度やってみて問題なし

cjcd4005_sotsugyoushasin_miki
hacd9002_sidearms
hcd2025_gateofthunder
hcd3046_tengaimakyou_kabukiden
hcd4064_tengaimakyo_dendennoden
hecd4010_3x3eyes
hecd5024_deadofthebrain
kmcd2002_snatcher_cdromantic
kmcd2003_gradiusii
kmcd3005_akumajoudraculax
mccd4005_fraycd
nscd0004_ranma1_2
nscd2013_choaniki
nxcd2008_sprigganmark2
nxcd2010_doubledragon2
nxcd3022_motteketamago
nxcd3027_srmp4
rscd-3002_fiendhunter
thcd3001_sylphia
ticd-4002_hatsukoimonogatari
_crazyhospital

停まらないがちょっと変

hcd2024_starparodia
hcd2031_gingaojosamadensetsu_yuna
napr-1049_asuka120

ADPCM の再生が一部ダメ.

  • hcd2024 は雑音がすごい(詳細未調査).
  • hcd2031 は割れる. 追記のつなぎ合わせが悪いだろうか?)
  • napr-1049 はおそらく 6280 から ADPCM 用 RAM への追記をしていてそれの対応ができてない.
hcd9009_ys_1_2
hecd3003_moonlightlady
jccd9001_kagaminokuninoledgend

絵が一部変になる. キャラデータの転送がまれに変. ADPCM RAM から 6280 へデータを読んでるんだろうけど対応ができてないと思われる(詳細未調査).

停まる

hcd4061_ryukonoken
hcd5078_yunahv
hcd5080_gingafukeidensetsu_sapphire
hecd6026_tekipakiwarkinglove
nxcd1004_sereisenshispriggan

全部起動はするけど途中で止まってしまう...

  • hcd4061, hcd5078 は未調査.
  • hcd5080 はちょっと見た感じ無駄なコマンド発行があるのでプログラムが汚そう.
  • hecd6026 は BIOS 外でのレジスタ操作.
  • nxcd1004 と mccd4005 は 6280 address 0x1ff802.r から CD-ROM data を読んでいたのでそれの対応をやって mccd4005 は問題なしに昇格. nxcd1004 のほうは fifo にいれたデータを全部読み切ってないらしい.

例外的な対応

hcd9009 は CD-ROM track index 01 の TOC が 1 frame ずれていて, discimage の作成に問題があるのか本当にこれで動いているのかの判断が必要. とはいえこのご時世に問題があるデータを作ってくるとは思えないので、この状態で起動することも考えている.
一応 subchannel Q も確認したが TOC の通りで mainchannel の sector が後ろにずれている... この時に本物の CD drive が mainchannel の管理データをみて1つ後ろの sector に補正している仕組みがあるなら考え物.

PCE CD-ROM2 内部 ADPCM 用 RAM 制御機能に対する考察

情報の精度

この文書はインターネット上で得られる情報を元に実装したものであり、実機からの分析情報ではありません. 情報の精度はよくありません. 詳しい仕様をご存じの方は是非教えてください.

はじめに

CD-ROM2 システムで一番複雑なのは ADPCM 用 RAM 制御であると思われる. CD-ROM2 に入っている ADPCM decoder は MSM5205 であるが、 MSM5205 には RAM 制御機能は一切なく, CD-ROM2 側で RAM を制御管理する.

制御内容はおおまかに下記である.

  • 6280 (CPU) からのデータ読み書き
  • CD-ROM コントローラからのデータ書込み
  • MSM5205 へのデータ送信

6280 からのレジスタ

制御レジスタは絶対アドレス 0x1ff800 から 0x1ff80f にあり、当機能に該当するもののみ記載する. レジスタのアドレスは一部 bit を decode していないので mirror がある. decode していない bit はおそらく bit9:4 だと思われる.
レジスタには read / write で別の意味を持つもの, write cycle が発生しただけで意味を持つものもあるので RAM と同じ感覚で考えてはいけない.

レジスタは address.rw.bit と表記し 0x1ff80d.w3:0 とある場合は絶対アドレス 0x1ff80d, write, bit0から3の4bitを意味する.

address 0x1ff800, 省略

address 0x1ff801, 省略

address 0x1ff802, 割り込み発生許可
w6   CD (seek?) ready interrupt mask (0:disable, 1:enable)
w5   CD (transfer?) done interrupt mask (dataの意味は同上)
w3   ADPCM play done interrupt mask (dataの意味は同上)
w2   ADPCM length register msb interrupt mask (dataの意味は同上)
read や他の bit は省略
bit4 は CD-G に使う割り込みらしいが現段階では省略

address 0x1ff803, CD,ADPCM 状態
r6   CD (seek?) ready status
r5   CD (transfer?) done status
r3   ADPCM play done status
r2   ADPCM length register msb == 0
address 0x1ff802 と同じ bit の並びになっている. 割り込み許可時に
この値が 0->1 になると 6280 へ IRQ2 を送信する.
bit4 は address 0x1ff802 と同じ

address 0x1ff804, 省略

address 0x1ff805, 省略

address 0x1ff806, 省略

address 0x1ff807, 省略

address 0x1ff808, ADPCM argument register (1/2)
w7:0  ADPCM argument bit7:0

address 0x1ff809, ADPCM argument register (2/2)
w7:0  ADPCM argument bit15:8

address 0x1ff80a, ADPCM RAM data port
r7:0  ADPCM RAM read data
w7:0  ADPCM RAM write data
アクセスするごとに RAM address は increment される.

address 0x1ff80b, CD-ROM data desitination register
w1    CD-ROM data desitination (0: 6280 data port, 1:ADPCM RAM)
w0    不明
詳細の考察は後述する.

address 0x1ff80c, ADPCM RAM controller status
r7    reading status (0:idle, 1:reading)
r6:4  不明
r3    playing status (0:idle, 1:playing)
r2    writing status (0:idle, 1:writing)
r1    不明
r0    playing status の反転値らしい
詳細の考察は後述する.

address 0x1ff80d, ADPCM RAM controller operation
w7    reset (0:idle, 1:reset)
w6    play (0:stop, 1:play)
w5    play endless?
w4    latch to length register
w3    latch to read or play address register
w2    6280 から read に関する address 制御らしい
w1    latch to write address register
w0    6280 から write に関する address 制御らしい
詳細の考察は後述する.

address 0x1ff80e, 省略

address 0x1ff80f, 省略

6280 から ADPCM 用の RAM へのアクセス

  • argument register を書込み, 目的別の address register へ latch する.
  • 0x1ff80c.r0 は address latching と書かれている文書もある.
  • 0x1ff80c.r7 と r2 はこの RAM が実際には DRAM であるため、DRAM への address の設定や refresh の都合で時間が一定ではないため存在すると思われる.
  • 0x1ff80d.w2 は 6280 から読み込むときに 1 に set する. これを設定した後 0x1ff80a.r を 2 度読み込んだ後(=空読み)、指定した address の data が読み取れるが何故そうなるのかが不明.
  • 0x1ff80d.w0 ではやはり書き込むときに 1 にset する, read と違い 1 度の書込みのあと、指定した address へ data を書き込めるがやはり理由は不明.

6280 からの ADPCM 用 RAM の読み込みはかなり重要. RAM が少ない SUPER ではない CD-ROM2 ソフトで ADPCM の再生の目的ではなく RAM 容量を増やすために使われる. SUPER CD-ROM2 ソフトでもビジュアルシーンで通常の RAM を使い切った場合に CD-DA を停めずにデータをよんでいるなど、テクニックが多い.

CD-ROM 読み込みから ADPCM 用 RAM への書込み

通常は下記の手順で行なわれる.

  • READ(6) コマンド発行
  • COMMAND REQ -> COMMAND ACK -> DATA IN REQ
  • DATA IN REQ 受付後 0x1ff80b.w1 = 1 にする
  • ADPCM RAM controller から ADPCM RAM へ書込み
  • DATA IN REQ -> STATUS REQ

0x1ff80b.w1 = 1 のタイミングは BIOS では上記になっているが、BIOS を使わない場合は READ(6) 発行時点で 1 になっている場合もありそれでも ADPCM 用 RAM へ書き込まれる. このタイミングに設定している理由は不明.

ADPCM 再生中にも書込みが可能. ソフトでは再生と書込みの address 範囲が一致しないようにしている. 一致した場合の動作は現時点では不明.

ADPCM 用 RAM の address はおそらく 0x1ff80b.w1 = 1 の時点で argument register から latch すると思われる. このため 0x1ff80d.w1 = 1 は設定しなくても良い. また 0x1ff80b.w1:0, 0x1ff80d.w1:0 はこのために bit の並びを揃えているようなので, 詳細不明の w0 も同じ意味を持つと予想される.

ADPCM の再生 (追記の必要のない短い時間)

  • ADPCM 用 RAM に MSM5205 へ渡すデータを書き込む
  • length register と read or play address register を設定する
  • ADPCM play done interrupt を許可する
  • address 0x1ff80d.w = 0x60 を書き込んで再生開始
  • 再生終了後 IRQ2 が発生するので、発生原因が ADPCM play done の場合は address 0x1ff80d.w = 0 を書き込んで停止

再生開始は w6=1, w5=1, w2=0 となる. w5 は length register == 0 でも再生を停めないのか address register 0xffff -> 0x0000 を許可するという意味を持つと思われるが基本的に 1 に設定するらしい. w2 は空読みがいらない理由の根拠らしい.

ADPCM の再生 (追記が必要な長い時間)

  • ADPCM 用 RAM に MSM5205 へ渡すデータを書き込む
  • length register と read or play address register と write address register を設定する
  • ADPCM play done interrupt と ADPCM length register msb interrupt mask を許可する
  • address 0x1ff80d.w = 0x60 を書き込んで再生開始
  • 再生途中に IRQ2 が発生するので, ADPCM length register msb interrupt の場合は READ(6) を発行する
    • READ(6) 発行後, SCSI status を DATA_IN_ACK にした時点で 0x1ff803.r6 の割り込みを発生させること,この割り込みの後に 0x1ff80b.w1 = 1 となり、追記の初期化が完了する.
    • ADPCM 用 RAM への書込みが終わった時点で 0x1ff803.r5 の割り込みを発生すると,追記の処理の終了となり、次の追記の処理を受け付ける.
  • これ以上の追記を望まない場合は ADPCM play done interrupt のみ許可する
  • 再生終了後 IRQ2 が発生するので、発生原因が ADPCM play done の場合は address 0x1ff80d.w = 0 を書き込んで停止

追記処理は前述の処理をすべて応用するので、実装できていなかった.

ADPCM 用 RAM controller について重要なレジスタ(変数)は下記の動作をすると思われる.

  • length register
    • 16bit のレジスタ
    • read cycle の場合 -= 1
    • write cycle の場合 += 1
    • bit15:0 == 0x0000, bit15 == 0 で各 status, interrupt に反映
  • write address register
    • 16bit のレジスタ
    • 6280 からの write の場合は 0x1ff80d.w1 を利用し latch する
    • CD-ROM から直接 write する場合は 0x1ff80b.w1 を利用し latch する、再生中は latch しないらしい(?)
  • read or play address register
    • 16bit のレジスタ
    • read cycle に使用 (6280 からの read, MSM5205 の再生で更新)

追記処理中は address 0x1ff80d は停止以外の目的で書込みをしないのでこう解釈している. length register は overflow (0xffff->0x0000), underflow (0x0000->0xffff) が起きないらしいが、 address register は overflow が起きるため追記に利用できる.

難易度の高い銀行口座を開設する

今年は2件作りたくて、両方とも成功したのでお伝えします.

2件とも資金洗浄防止や振り込め詐欺防止のため難易度が高いこと、最終的な判断は現地の係員が決めるため、運が必要です. これと同じ事ができるかは運です.

UFJ 銀行で2つ目の個人口座を作る

詳細は省きますが、引っ越しのため公共料金と家賃の支払いを新しい口座で管理する必要がありました. 同じ銀行にした方が振替の手数料を無料にできるため2つ目の口座を作りたくなりました.

そこで近所のUFJ銀行で上記の理由を詳細を含めて可能か聞いてみました. するとしばらくお待ちくださいと言われて奥で数名と話し込みが始まり約5分... 必要性が高いので作成可能と回答を得ました.

この時はお役所関連で別の珍しい支払いがあったことで先に奥で数名と話込みをさせていたのと、銀行で自分以外待ってる人が誰も居なくて銀行員がヒマだったことも合わせてお伝えします.

このあと2つ目の銀行口座を作ったのですが、1つ目と同じ支店の口座で作りますと言われました. 1つ目の口座は高校生の時に地元の東海銀行で作ったもので、窓口のUFJ銀行とはとても離れているのですがその地元の口座になりました. 印鑑も同じ物を要求されてじっくり確認されました. (応対した銀行員がその地名の漢字が読めなかったけど作れた.)
あとは普通の口座開設と同じ流れになりますが、通帳とカードのデザインを地味なやつかミッキー(東海銀行だったらバグスバニーだったんだけど)か選べます. 1つ目の口座と見分けるために別にしました.

台湾の銀行で外国人が個人口座を作る


台湾は外貨の送金に制限が多くて安い手数料で日本から台湾の人に送金する方法はないです. そこで昨年調べたところ、銀行口座は簡単に作れるので現地に行ったときに預金してそのあと日本からネットバンクで送金することはできるのです.

今回量産のための打ち合わせのあと銀行口座を作りたいと通訳さんに依頼したところ、昨年までは口座開設が簡単にできたといわれました. ほかの日本人が書いた口座開設報告の日付には注意してください. 大半は制限が出来る前の情報です. 台湾の空港にでもでっかく書いてあるんですけど、そういうことです.

わたしはあまり期待できなかったのですが台湾に来たし通訳さんは呼んだのでやってみることにしました. まず移民局に行って統一証号を得ます. これは古い情報と変わりありませんし、外国人が集まる役所なので簡単な英語ができれば終わります.

移民局の次は本番の銀行です. 銀行員は統一証号だけではダメで短期滞在者が持ってる訳のない在留証や台湾の健康保険証がいるといわれました. ここで通訳の人が移民局に電話し始めてこれはだめかなーと思ったら、豪雨で天気が悪く客が少なく銀行がヒマだったのか奥で話し込み始めて5分後、パスポートがあれば身分証明はokだから作れるよ. ということになりました!

印鑑に関してはフルネームのもの(名字だけは不可)かサインが必要です. サインはパスポートと同じ文字を書くことを要求されました. わたしは漢字を書くのが面倒なのでサインはひらがなにしてます. パスポートの有効期限を迎えるなどパスポートを作り直した後にもサインの文字の種類を替えるのは銀行窓口で手間が増えますのでやめましょう.

ここからは書類を書いて、何の目的に使うのか聞かれました。ここでさっき打ち合わせした人に仕事の支払いをしたいと答えると、その人は誰?って聞かれて名刺を渡したところこの人知ってますよって回答がきました. そして処理が進み制限がどんどん解除されていきました.
打ち合わせのときに町工場の人に近所にxx銀行があるよって教えられたのですが町工場のひともそこの銀行を使っているのでうまくいきました. この紹介がなかったらネットバンクにかなりの制限を加えられたはずです.

通訳さんも奇跡ですよっていってました.

2つの経験から得られた成功のポイント

  • 近所の銀行に行く (小さな支店がよかったかも)
  • 客が少なくて銀行員がヒマ
  • 口座が必要な明確な理由を持つ、地元の人に紹介してもらう

あとは銀行員の個別の裁量という運です.

frame buffer 部の回路

先週部品選定してて確認していたのでここに書きます.

概要

  • frame buffer は 0x40000 word, 16bit databus の高速 SRAM を使用する
  • 本回路はピン数削減のため, databus 16bit と制御線5本で構成される
  • 制御線のうち2本で汎用ロジックICを制御し,databus 16bit から frame buffer の address bus を生成する

address bus 生成

  • address bus は下位12bitを 74161 x3, 残りを 74574 で制御する
  • 74161 は load で 12bit を任意に設定可かつ, counter を利用しシーケンシャルアクセスが可能
  • 74574 の CLK と 74161 の LOAD を同じ線にしているので全部のaddressを load する場合は 74161 -> 74574 の順番に行なう
  • address bus の配線は SRAM のピン配置に無関係で配線しやすい線に接続する

data bus 制御

  • bytemask pin は GND 固定にして 16bit access 専用
  • increment による address 更新から data が出てくる時間は 74LV161A の伝搬遅延と CY7C1041DV33 の read cycle の max 加算で 13.6 + 10.0 -> 23.6 ns

反省点

  • 74574 ではなく 74821 にすると 74161 を1つ減らせて基板の必要な表面積を減らせる. 74821 には LCX があるが定番ではないのでやや高い.
  • 設計当時は SRAM は frame buffer としてのみの利用を想定していたため, instruction RAM 兼用とした場合の都合に配慮できなかった.
  • 74161 は現在の新規設計としては定番の汎用ロジックでないため、最速がシリーズが LV...A で停まっている. カウンタである都合や LCX などに比べると伝搬遅延が多い.
    • 定番で早いシリーズが用意されているのは NOT, NAND, AND, OR, XOR の単純なゲートやバスバッファ(244,541)やバストランシーバ(245)とDラッチ(374,574)などに絞られる
    • カウンタ(161)やシフトレジスタ(164)などはそんなに早くないのでピン数を減らしてもスピードや表面積のトレードオフになる
  • 利用頻度が高い address の更新は 74161 を利用することになるので、 read / write cycle は 23.6 ns より早くすることはできない.
  • つまり 74574 は 74LV161A の伝搬遅延より遅くない 74VHC574 でも構わない.