Hatena::ブログ(Diary)

naruko の開発メモ

2018年09月29日

自分で作った潜在的なバグ

最近他人が作った潜在的なバグに言及しておりますが、upergrafx のソースコードにも本来ならすぐに起きるはずのバグが起きずに放置、その後の謎の現象となり、調査したら稚拙なバグが2件も見つかってお恥ずかしい限りです.

  • write strobe の正負の論理を間違える
  • address decoder で read 用 databus 入力で read strobe をデコードしてない

address decoder のほうはなんでいままで正常に意図通りに動いていたのが不思議なぐらいのバグでした. そういう変なバグがあると開発が停滞しますが、そこを抜けたので今回の回収も落ち着くといいのですが...

2018年09月14日

CD-ROM2 の読み込み時間の厳密な再現の必要性 / その2

CD-ROM の 1 sector のロード時間を規格通り 1/75 秒に設定したところ、ロード時間が早いために問題になっていたソフトが結構直りました. 一方直らなかったソフトの傾向を見ると下記のようでした.

ロード時間の前後の処理時間を要求するもの

1 sector のロード時間を設定しても、その前後の準備時間や後処理の時間はわからないままです. 準備時間はシーク時間で別に書くとして、後処理のレジスタの変化の微妙なタイミング要求するソフトまでありました.

このような高い精度を要求するソフトは...正直に申しまして...プログラムが汚く読めたものではありません. 初期化やタイミング同期を省略しているので本物のハードのタイミングでのみ奇跡的に動いているものが多いです. これはプレイヤーが遊んで名作かというのは関係なくプログラマの性格やそのソースコードを使い回す職場が原因で困りものです.

シーク時間の再現を要求するもの

CDDA の音ズレの原因がロードではなくシークの時間の再現がいるようです. シーク時間は CD のレンズが物理的に動く時間で実機からの計測がいります. これもシークしてから再生すればいいだけなんですがとってないみたいです.

当ユニットのユーザーさんの間では人気のスーパーダライアスでは最初のクレジット音とゲームの開始も同期を取らずにシーク時間決め打ちで動いているようです. mednafen でもシーク時間を再現してないみたいで、ゲームを遊ぶ側にとってはダメな演出になっています.

ADPCM 用 RAM のメモリアクセス待ちの再現を要求するもの

風の伝説ザナドゥで港のシーンにいく前に CDDA 再生したまま, ADPCM 用の RAM (本物は DRAM) から VRAM に転送しているようでして. メモリアクセス待ちを設定しないのかずれてしまいます.

これは実機からの計測で待ち時間の法則性を得て再現性をあげる必要があります. 元のプログラムで CDDA を PAUSE するか時刻指定で再生し直すだけで同期はとれたと思うのですが...

実機計測かパッチ

(次回に続く)

2018年09月09日

CD-ROM2 の読み込み時間の厳密な再現の必要性 / その1

現在の不具合報告に登録してあるソフトの不具合の原因が読み込み時間が実機と違うのでちゃんと動かないというのがある程度わかっています.

別件で mednafen の document を読んでいたら pce_fast module で CD-ROM の読み込み時間を設定で変えられることをしりました. それが再現するかみてみたら大半は再現しました. mednafen で pce と pce_fast と2つ emulation engine が存在するのはこの理由でしょう. 他のエミュレータがこの乖離をその場しのぎのパッチで補正するよりかは、わたしとしては*1 mednafen はいい選択と思います.

PCE の CD-ROM2 の場合、読み込み速度がかわっていても同期を取る仕組みはあります. 問題にならないソフトはちゃんと同期をとっているんですが、問題になっているソフトの大半は同期を取っていないとか初期化を省略しているとかの潜在的なバグが表にでてきてしまっています. 潜在的なバグを直すことはよいのですが、意図的に同期を取らないソフトもわずかに存在します.

意図的に同期を取らないソフトは HuVideo を使うものとブランディッシュぐらいです*2.

というわけで厳密な読み込み時間の再現を実装してみますが、意図的なものを動くことを目標にしまして、潜在的なバグは回避策がなければパッチをあてるほうが無難なのかもしれません.

*1:ゲームを遊ぶことだけを優先せずに現状動作がおかしくても再現度をあげるとかデバッグ情報が豊富という視点

*2:手元にイメージがないんですがネクスザール(通常版)もそうな気がします

2018年09月03日

PC-9821 のハードディスク相当を復旧する / その2

手元にある Compact Flash は昔デジカメで使っていた RCF-X 64MB です. これは website に http://buffalo.jp/php/lqa.php?id=BUF9612 [コンパクトフラッシュを起動ディスクとして ご利用いただくことはできません。]とありましたので別のメディアも買いました.

Trancend TS16GCF133 と No brand EXTREME CF アダプター UDMA TYPE II SD です. TS16GCF133 はデータシートに True-IDE mode のことが明記, EXTREME CF... のほうは .com のほうの amazon に True-IDE mode support と書いてありました.

機材があらかた到着して,PC-9821V16 につけて動作させてみたところ TS16GCF133 は容量制限で memory check 以降の動作(OS 起動)になりませんでした. 容量制限,つまりこの機種の IDE port の固定ディスクは 4.x GB までです. そんなことは購入当時から知ってて PCI bus に挿して IDE コネクタが付いてる SCSI カードを持っていたので容量制限は関係ないと思っておりました. でもその SCSI カードがどうも動いてないみたいでした...

RCF-X 64MB も使えますし、EXTREME CF アダプターも使う SDCard が 2GB なら固定ディスクとして OS が起動できました.

9821 のハードディスク相当を復旧する / その4 (終)

Filesystem 関連

前回細かく書いていたのは LBA=0 を PC-98 用, AT 用に調整すれば現行のパソコンから普通にファイルシステムにアクセスできるだろうという考えでした.

結論からいいまして下記でした.

  • NEC 5.0 の FAT header のフォーマットが謎で RCF-X 64MB で発生して 2GB の SD カードでは NEC 6.2 だけだった
  • NEC 6.2 だけのほうは AT 用の MBR として LBA #88 からにすれば普通に mount できた
  • FAT header の offet 0x1fe に data 0x55, 0xaa が規格上いるはずが NEC は書いてないし, 今の Windows でも文句をいわない
  • RCF-X 64MB は LBA #88 から FAT として Windows からフォーマットした場合は PC-98 の MS-DOS からも使える
  • どちらの場合も 1 cylinder = 8 Heads , 17 Sectors; 8 * 17 * 0x200 -> 0x11000 となる.

当然ながら MBR だけ書き換えて mount するという考えは別の方がちゃんとしたツールを作っていましたので NEC 5.0 の謎フォーマットだけが問題でした.

TCP/IP

LGY-98 を持っていましたので下記の文書のままでそのまま使えました.

http://www.qsl.net/ja0rug/teene.html

TEEN 用の ftp client やWindows共有フォルダアクセスツールも普通に使えました. Windows のほうはセキュリティ甘めが必要でした, パスワード有りはやってみたけどだめでした.

つまりオンラインのファイルの受け渡しも問題なくできます.

ゲーム

ちゃんと動きました. でもゲームやるだけならエミュレータのほうが楽かなと思いました. 何より 2018 年の常識では PC-9821 の寸法は大きすぎで邪魔です. 2010年あたりからコンピュータ用の機器がどんどん小さく高性能になっていくのはなんとなく気付いていましたが、 1997 年の常識とは全然違う物でした.

おわり

SCSI カードが動かなくなっていたので、 16GB や 8GB の flash media が使えません. FreeBSD (98) の導入はやらずにここで終わりにします. LGY-98 や MS-DOS 起動ディスクの所持がハードルでしたが、それ以外は機材も簡単に揃いますし、ソフトの操作も経験があれば難しいことはありませんでした.

一応この機材を残していた理由が PC-9821 実機ででないとできないことのためで、それが PC-98 向けではないフロッピーディスクの解析でした. 5 インチディスクとかファイルシステムがない特殊用途とか、そういう依頼がたまにあったので残していました. それも死んでいた期間に依頼があったわけではなかったし、私だけがそれをやれるという分野でもないように感じました.

2018年09月02日

PC-9821 のハードディスク相当を復旧する / その3

(その2はあとでかく) ひとまず Compact Flash で MS-DOS が BOOT できるようになりましたので現行のパソコンから dd で dump してみました. 筆者は開発環境として msys2 を常用していますので dd なり /dev/sdx というデバイスは普段から利用できます.

実データ

LBA=0, IPL らしい.

f:id:na6ko:20180902063355p:image


LBA=1, パーティションテーブル.

f:id:na6ko:20180902063356p:image

説明はここにちょっとある. https://hp.vector.co.jp/authors/VA013937/editdisk/tech.html

LBA=2, OS 選択起動画面の文字列.

f:id:na6ko:20180902063357p:image


パーティションテーブルの開始シリンダから MS-DOS 6.2 の領域(つまり FAT) が始まる. これは FORMAT.EXE の固定ディスクの領域確保 (つまりいまでいう fdisk) らしい.

ここまでやって1シリンダが何バイトなのか不明だったのと、利用した古い 64MB の Compact Flash で MBR なしのフォーマットと PC-98 の固定ディスクフォーマットと PC/AT の固定ディスクフォーマットがまざりまくって、 FAT の先頭が3つありどれかわからなくなったのでやり直します.

 dd if=/dev/zero of=/dev/sdx bs=1M count=2

FAT filesystem の先頭

先頭 2Mbyte を data 0 で埋めた Compact Flash を接続し再度PC-98から固定ディスクの初期化とシステム転送をしてきました.

LBA=0x88, NEC 5.0 (?) の filesystem header

f:id:na6ko:20180902065820p:image

LBA=0x89, NEC 6.2 (?) の filesystem header

f:id:na6ko:20180902065821p:image

LBA=0x8a, FAT16 の cluster chain table

f:id:na6ko:20180902065822p:image

固定ディスク領域マップによるとこの領域はシリンダ 00001-00915, サイズ 00061 とのことです. 1シリンダが 0x11000 byte なのか 0x11200 byte なのか謎ですが filesystem header をみることにします.

JmpBoot 0xeb 0x45 0x90
OEMName "NEC  5.0"
BytesPerSector 1024
SectorPerCluster 2
ReservedSectorCount 1
NumFats 2
RootEntryCount 3072
TotalSector16 60390
Media 0xf8
FATSz16 59
SectorPerTrack 17
NumHeads 8
HideSector 136
TotSec32 0
DriveNumber 128
Reserved1 0x00
BootSignature 0x29
VolumeID 0x29 0xfe 0x07 0x10
VolumeLabel "NO NAME    "
FilesystemType "FAT16   "
BootSign 0x00 0x00
JmpBoot 0xeb 0x45 0x90
OEMName "NEC  6.2"
BytesPerSector 1024
SectorPerCluster 2
ReservedSectorCount 1
NumFats 2
RootEntryCount 3072
TotalSector16 60390
Media 0xf8
FATSz16 59
SectorPerTrack 17
NumHeads 8
HideSector 136
TotSec32 0
DriveNumber 128
Reserved1 0x00
BootSignature 0x29
VolumeID 0x29 0xc0 0x07 0x16
VolumeLabel "NO NAME    "
FilesystemType "FAT16   "
BootSign 0x00 0x00

NEC 5.0 と NEC 6.2 の内容は大きな違いはないのですがその次に cluster chain がある NEC 6.2 を使うことにします.