【L2/L3 M2/M5】ベーシックマスターシリーズ MARK11【Jr/S1】
日立のベーシックマスターシリーズ(68系)のスレです。
MB-S1も入ります。
ベーシックマスター1600は出来れば他(8bit・16bitビジネスPCとかB16専用スレッド)でお願いします。
前スレ
日立ベーシックマスターシリーズ レベル3 Mark6
http://ikura.2ch.net/test/read.cgi/i4004/1345048044/ ブロック転送のコード見れば6800設計したやつはバカだと分かる >>105
8080ってインダイレクトしか出来ないんだっけ?
でもそれとレジスタの多さは無関係だと思うけどw 方や電卓がご先祖様
方やミニコンがご先祖様
いろいろあらぁな EXXってZilogではなくてIntelだったっけ? >>105
リトルエンディアンについては意見が分かれるな つまるところ、コードを処理するハードの方に都合よく出来てるか
あるいはコードを組む人間の方に都合よく出来てるかの違い。
ダンプリストやビットの羅列を「読める」人にとってはどっちでもいいこと。 久々に見たS1用68008カードのヤフオク出品、蓋を開けてみたら最低落札価格 36万8000円って…
一体何をしたかったんだ? >>113
きっと、みんなに自慢したかったんだよ。 ACRTCの採用例とか聞いたことないけど何かありますか? AGD-98と言う名のNEC-9801のCバス用で開発されたGraphic-Cardで採用されている。 確か 2050で使われていた気がする
あと、産業用のカスタムコンピューターにけっこう使われていたりしたらしい B16にも載ったんだ
秋葉原の Bit-innで 68000?とACRTCのデモ用ボードで高速グラフィック描画していたのも
懐かしいね・・・・・・日立は 68000とACRTCでパソコン格安で出せばよかったのにね >>123
シャープがX68kに採用してれば色々と面白かったかもなぁ。 >>124
ごめん
調べずに間違えた
ACRTCはX68000でも考えていたそうだけど、スプライトとかゲームに必要な機能を考えると
合わないし、コストもかかるのでカスタムICにしたって話を聞いたです。 >>126
CPUにDMAと主要チップに日立製使ってんだから検討はしてても不思議じゃないよな。
ゲームに使えないってのは分かるけどGUI環境への対応考えたら使ってた方が良かったんじゃないかな。 なにせ耳にしたのが X68000発売当時だったもので
SX-Windowsはいろいろ考えた結果、ああいう形に落ち着いた感じで
発売当初は GUIに対応しあぐねていたみたいです
発売当初、ビジュアルシェルを始めて見て、あんな感じの UIをユーザーが自由にライブラリーから呼び出して
使えるのでしょうか、と聞いたらそんなものはありませんと言われました
一部ではライブラリーが ROMに書き込まれているという憶測も飛び交いましたが・・・・・・
ACRTCはホスト CPUからグラフィックメモリーにアクセスするためには ACRTCのアクセスエリアを
いったん通す必要もあり、またウィンドウも1つしか制御できないところから 設計思想的に
合わなかったんだろうと けっきょくマルチポートメモリーを積んで解決策としたんじゃないでしょうか ACRTCの恐ろしいところはMPU側からのソフトウェア的I/Fがたったの2ワードしか見えない
こと。1ワード16bitなので計4バイト。
(8bit I/Fモードにするとさらに半分でたったの2バイト!)
なので、ACRTCに組み込まれた描画機能のみで賄えない「何か」をしようとしたら、その
2ワードのI/Fを経由してエッチラオッチラとフレームバッファのデータを読み書きしないと
いけない。
例えばDiskから読んだ画像データをフレームバッファに表示させたいなんて場合が該当する。
さすがにそれでは遅すぎるので、DMACを使った矩形領域転送にも対応しているけれど、
DMAの間MPUはBUSを相当な割合で握られることに。
またマルチウィンドウに関しては、ハードウェアウィンドウだと確かに1面しか設定できない
ため、2MBのフレームバッファ内に必要なウィンドウイメージを枚数分描画しておき、同じ
フレームバッファ内に設定した表示エリアに矩形転送して実現するよう、日立では推奨
していたみたい。
ただ、65536色モードなんかにしたら2MBでも1024x1024しかフレームバッファに持てない
から、これで日立推奨方式をしろって言われても…ねぇ… ついでに言うと、ACRTCはデュアルポートのDRAM(通常のランダムアクセスポートにシリアル入出力
の付いたヤツね、所謂VRAM)が出る前の世代の製品なので、当然それに対応していない。
フレームメモリに使えるメモリは汎用DRAMなので、8bitパソコンが必死になってやってた表示アクセス
とMPUアクセスのスケジューリングという命題から当然ながら逃れることはできない。
1例としてデュアルアクセスモード1というのを示すと、
描画プロセッサREAD→表示READ→描画プロセッサWRITE→表示READ→描画プロセッサREAD
というサイクルを繰り返している。DRAMに対しては通常のランダムアクセスモードでのアクセスだ。
これは基本的に8bitパソコンがやってるのと同じこと。メモリがシングルポートなのでどうしようもないが、
高速なアクセスモードも使用せず、ひたすらシコシコと地道な努力が涙ぐましい。
一方所謂VRAMってやつは1ランダムアクセスサイクルと同じ所要時間で、最大1column分の全データ
をシリアルアクセスメモリ(要はシフトレジスタ、SAM)に転送できる。
1columnの長さが水平画素数よりも多いならば、水平帰線期間に一度SAMに転送しておけば、以後
フレームメモリに対してはMPUがアクセスし放題という夢のような環境を実現できる。
同期BUSにおけるサイクルスチールの再来のような楽園の再現だ。
当時は画期的で圧倒的にも見えたけど、技術の進歩も早かったので、ほんの少し時間が経てば時代
遅れとなる運命でしかなかったという…諸行無常の一例だね。 でも、x68kってハードウェアスプライト機能のおかげで当時のアーケードゲーム
の移植なんかは他機種の追随をゆるさなかったかど、グラフィック描画機能自体は
あの時代の水準で見ても決して速くなかったよな? いや、速かったよ
一般用のハードウェア描写よりも CPU+レイヤー操作回路で描き込んだ方が速いって過渡期だった
X68000はそのあたり配慮がされていたし Oh! Xにアセンブラで画面描写するプログラムが載っていて
速さの点では問題ないことがわかった
かなり 68000用に最適化されたパソコンだったからなぁ
そのまま頭を EC030にすげ替えるより ヒヤリングしていたデモ機をそのまま売ればよかったのに
(互換性云々は当時の X68000のプログラム熱からすれば容易に解決されただろうし)
もしくは 20MHz(当時あれば)にクロックアップしても良かった この頃はアセンブラで書けば高速化できるほぼ最後の時期だね。
GNU C相手でもまだ勝ったり負けたりしてた記憶(まぁライブラリがアレだったりもしてたから…)
今はSIMDがらみを除いて、VisualCなんかとは勝負を挑もうなどという気力も湧かない… 今のコンパイラはバリバリ最適化するもんなぁ
CPUのことを熟知していないと出てきたコードを読んでみてもサッパリわからん >>134,136,139 の金魚のフンのような、相槌コメントが笑える。 このゲーム好きでよくやったなぁ
今やったらクソゲーだけど w
https://i.imgur.com/hxxJJJJ.png ベーシックマスターJrとPC-6001で迷ってPC-6001を選んだ
正解だった S1のPCG⇔グラデータの相互変換ってどういう仕組みだったの
キャラクタをグラフィック画面に高速表示してたという事? 検索してたらMB-6890 Basic Master Level 3 の MAME ROM なんてのがあったんだが、最近のMAMEってLevel3も動くの? だれか持ってませんか?
ベーシックマスターJr.のエミュレータ eMB-688X(EMB688X.EXE)
レベル3のエミュレータ eMB-689X (EMB689X.EXE)