![Retro Computer People [annex]](/_images/blog/_fba/retrocomputerpeople/rcp-e6a98.png)
Thunderbolt さん
遠い過去の物となってしまった８／１６ビット時代のパソコンとゲームに関するブログです。
初めての方でも気軽にコメントしてください。
また、過去の記事にもコメントして頂ければありがたいです。
-
nice! 111
記事 110
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
過去の遺産という形でゲームの画面イメージ、パッケージ、マニュアル等を取り上げておりますが、もし不都合がございましたら「プロフィール」に記してあるメールアドレスよりご連絡頂けますようお願いいたします。
Dash-8X 進行状況、その他 [近況報告]
Dash-8X のリリースに向けてバリバリとコーディング中。
Dash-8X のネーミングはもう既にお察しのとおり、日本語系／漢字系を除く NEC の８ビット系の BASIC 全てで動作する Dash システムです。
PC-8001 用にリリースした Dash-80 は N-BASIC の構想もわりと単純だったのであまり苦労もなくインプリメントできたのですが、Dash-88 パートに苦戦…
N-BASIC だと 'LOAD', 'RUN' 等は Disk-BASIC 専用命令なのでフックを書き換えるだけで済んでしまうところが、N88-BASIC だと他のデバイス（"SCRN:","CAS:","KYBD:"）との絡みで、フックの書き換えだけという訳にはいかないのですが、まあ、その辺りは Disk-BASIC がやっているのと同じような拡張のやり方で済むので問題はありません。
Dash が売り物にしている「フリーエリアを圧迫しない」点も、 Dash-80 では必要でなかったデバイスディスクリプタ処理を 8000H から 83FFH にあるテキストウィンドウの裏RAMを使用する事であっさり解決♪
問題は N-BASIC ではサポートされていなかった DMA方式のドライブの存在…
Dash は５インチインテリジェントドライブ専用なので、８インチドライブは無用というか邪魔者でしかありません。
ドライブ番号は、８インチDMA→５インチDMA→５インチINT の順で振られるのですが、IPL が読み込まれる時点では既にシステムに接続されているドライブのリストが作成されてしまっています。
このリストをそのまま使用すると、サポートされていないドライブに番号が振られている「みっともない状態」になってしまいますので、これは何とか避けたいところです。 「フリーエリアを圧迫しない」というポリシーにも反しますしね。
もうひとつの問題は、起動時に ”How many files (0-15) ?” と質問される DCB(?)、 FCB とファイルバッファの存在…
N-BASIC では FCB とファイルバッファは Disk BASIC でしか使われなかったため、Dash-80 では全く使用しない方法で組んでいました。
Dash-88 パートを組むにあたっては、他のデバイスで使用される FCB とファイルバッファを無視する訳にはいかないので、あれこれと試行錯誤中です。
ドライブのステータスを管理する DCB は、N88-BASIC のドライブ管理機能自体を使っていないので、全く無視しても良いかな（笑）
Dash-80mkII パートは、まだ手付かず状態なのですが、こっちの方が楽に行けそうな感じ♪
Dash-80 が PC-8001mkII で N80-BASIC から起動した場合でも N-BASIC で起動してしまうのは、N80-BASIC で拡張された 4th ROM をチェックしていないのが原因なので、チェックを追加すればOKのはず。
Dash-88 パートで手詰まり状態になったらこっちを先にやるかもです。
Dash-80SR パートは全くの未着手 orz
N80SR-BASIC の解析は進んでいるのですが、どうしてもフリーエリアを使用しなくてはならないようなので、メモリレイアウトをあれこれ模索中です。
N-BASIC / N80-BASIC / N80SR-BASIC / N88-BASIC と、４つの Dash システムを１枚のメディアに収める件は、実証実験も終わってOKなので問題なし。
元々はシステムを４つリリースすると管理が大変だという訳で「面倒だからまとめてしまえ」と始めた Dash-8X ですが、色々と要望も野望も出てきそうなので、もう少し（…まだまだの間違いかも＾＾；）時間が掛かりそうです。
個別のシステムがある程度フィックスした時点で「えいやっ」とひとつにまとめてリリースします。
ここからは、使っているアセンブラ「Macro assembler AS」の話。
これまでも、他のアセンブラでできる事ができないとか、マニュアルが不親切で分かりにくいとか、色々と泣かされて来ましたが、またまた大きなバグを発見 OTL
コードの途中に構造体( STRUCT )を配置すると、アセンブルリストを見る限りでは問題なくちゃんとアセンブルされているのですが、出力された HEX ファイルには構造体の領域が確保されていないという…もう顎が外れそうです。
まぁ、データ領域は大抵コード領域の後ろに配置するのが常ですけど、ヘッダーとかに構造体を使わないんでしょうかねぇ…。
アセンブルリストは正常なので、コードジェネレータのバグなのでしょうか…。
使い込めば使い込むほど「ドツボ」に嵌り込んでゆく気がするのは、気のせいなんでしょうか…
Dash-8X のネーミングはもう既にお察しのとおり、日本語系／漢字系を除く NEC の８ビット系の BASIC 全てで動作する Dash システムです。
PC-8001 用にリリースした Dash-80 は N-BASIC の構想もわりと単純だったのであまり苦労もなくインプリメントできたのですが、Dash-88 パートに苦戦…
N-BASIC だと 'LOAD', 'RUN' 等は Disk-BASIC 専用命令なのでフックを書き換えるだけで済んでしまうところが、N88-BASIC だと他のデバイス（"SCRN:","CAS:","KYBD:"）との絡みで、フックの書き換えだけという訳にはいかないのですが、まあ、その辺りは Disk-BASIC がやっているのと同じような拡張のやり方で済むので問題はありません。
Dash が売り物にしている「フリーエリアを圧迫しない」点も、 Dash-80 では必要でなかったデバイスディスクリプタ処理を 8000H から 83FFH にあるテキストウィンドウの裏RAMを使用する事であっさり解決♪
問題は N-BASIC ではサポートされていなかった DMA方式のドライブの存在…
Dash は５インチインテリジェントドライブ専用なので、８インチドライブは無用というか邪魔者でしかありません。
ドライブ番号は、８インチDMA→５インチDMA→５インチINT の順で振られるのですが、IPL が読み込まれる時点では既にシステムに接続されているドライブのリストが作成されてしまっています。
このリストをそのまま使用すると、サポートされていないドライブに番号が振られている「みっともない状態」になってしまいますので、これは何とか避けたいところです。 「フリーエリアを圧迫しない」というポリシーにも反しますしね。
もうひとつの問題は、起動時に ”How many files (0-15) ?” と質問される DCB(?)、 FCB とファイルバッファの存在…
N-BASIC では FCB とファイルバッファは Disk BASIC でしか使われなかったため、Dash-80 では全く使用しない方法で組んでいました。
Dash-88 パートを組むにあたっては、他のデバイスで使用される FCB とファイルバッファを無視する訳にはいかないので、あれこれと試行錯誤中です。
ドライブのステータスを管理する DCB は、N88-BASIC のドライブ管理機能自体を使っていないので、全く無視しても良いかな（笑）
★
Dash-80mkII パートは、まだ手付かず状態なのですが、こっちの方が楽に行けそうな感じ♪
Dash-80 が PC-8001mkII で N80-BASIC から起動した場合でも N-BASIC で起動してしまうのは、N80-BASIC で拡張された 4th ROM をチェックしていないのが原因なので、チェックを追加すればOKのはず。
Dash-88 パートで手詰まり状態になったらこっちを先にやるかもです。
★
Dash-80SR パートは全くの未着手 orz
N80SR-BASIC の解析は進んでいるのですが、どうしてもフリーエリアを使用しなくてはならないようなので、メモリレイアウトをあれこれ模索中です。
★
N-BASIC / N80-BASIC / N80SR-BASIC / N88-BASIC と、４つの Dash システムを１枚のメディアに収める件は、実証実験も終わってOKなので問題なし。
元々はシステムを４つリリースすると管理が大変だという訳で「面倒だからまとめてしまえ」と始めた Dash-8X ですが、色々と要望も野望も出てきそうなので、もう少し（…まだまだの間違いかも＾＾；）時間が掛かりそうです。
個別のシステムがある程度フィックスした時点で「えいやっ」とひとつにまとめてリリースします。
★
ここからは、使っているアセンブラ「Macro assembler AS」の話。
これまでも、他のアセンブラでできる事ができないとか、マニュアルが不親切で分かりにくいとか、色々と泣かされて来ましたが、またまた大きなバグを発見 OTL
コードの途中に構造体( STRUCT )を配置すると、アセンブルリストを見る限りでは問題なくちゃんとアセンブルされているのですが、出力された HEX ファイルには構造体の領域が確保されていないという…もう顎が外れそうです。
まぁ、データ領域は大抵コード領域の後ろに配置するのが常ですけど、ヘッダーとかに構造体を使わないんでしょうかねぇ…。
アセンブルリストは正常なので、コードジェネレータのバグなのでしょうか…。
使い込めば使い込むほど「ドツボ」に嵌り込んでゆく気がするのは、気のせいなんでしょうか…
Dash-8Xの対応は，後から出たものほど対応が難しそうな感じですね。
自分の作ったプログラムだけ動かすより，人の作ったプログラムと共存させて動かす方が難易度は遥かに高そうに思えます。
ASのバグについてはなんともご愁傷様です。
Thunderboltさんなら，いっそのことアセンブラから作ってしまった方が楽ではないかという気すらしてきました。
by apaslothy (2010-10-25 02:42)
apaslothyさん、コメントありがとうございます。
PC-8001/8801（無印）が専門なもので、両SRは分からない部分も多く BASIC の拡張は難しいものだと改めて感じています。
今回 ROM のディスアセンブルリストを見直していたのですが、PC-8801 V1BASIC から PC-8801SR V2 BASIC への拡張は、もう見事と言うしかありませんね。
NEC の互換性へのこだわりが垣間見れたような気がして、負けないものを作らなければと発奮させられました。
AS は大学で習ったPascal で何か役立つものを作ろうと「勢い」で始まったプロジェクトなのじゃないかと勝手に想像しています。
C のように小回りの利く言語じゃないですから、あれでアセンブラの字句解析を書くのは大変だろうなぁ（笑）
その上、途中から C にコンバートされているので、ソースはもう奇怪極まりない代物です。 一度自分でバグ取りしようかと思ったのですが、ソースを覗いてみて諦めました。
アセンブラを作るとなると、またひとつ進行中のプロジェクトが増えちゃいますね。 AS の吐く hex ファイルをバイナリに変換する hex2bin はどこにも見当たらなかったので短時間で作っちゃいましたけど、 やりたい事が多すぎて全体の進行がかなり遅れ気味なので止めときます。 凝っちゃう方なんで、やり出したらどっちがメインか分からなくなりそうなんです（笑）
by Thunderbolt (2010-10-25 04:28)
こんにちは、ほぼ同僚の若い子がNECのCP/M86の
純正システムをN88BASICでツールを作って作動
させるとHDDの円板の奇数のメーカーのドライブを
使えるようにしていました、いわゆるパッチですが
BASICしか作っていなかったです。
CP/MのBIOSはエディットして２０Mに対応させる
ようにしていましたが最終的に誰も作成しなかった
ので１０Mまでを確認しています。
by jh (2011-12-27 13:50)