アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
PC-8001のグラフィック (スコア:1)
ビットマップに見えるものは、2×4マスを二進数に対応させて256種類用意されたタイルパターンで、これを80×25文字のスクリーンに並べてビットマップを表現する、ある場所がビットマップか文字かはアトリビュートエリアで決定する。
要するにキャラクタデータが二種類用意されていて、それを切り替えている。
という感じではないかと当時考えていたのですが、あたってます？
Re:PC-8001のグラフィック (スコア:3, 興味深い)
おっしゃる通りです。
補足しておくと、PC-8001はスクリーンモードの横幅が40文字と80文字の2種類あって（縦は 25と20…15か18もあったっけか？）、スクリーン用エリアが80バイトの後にそのラインのためのアトリビュートエリアが40バイト続いてました。width 40のときはスクリーン用エリアの奇数番目（xxx1, xxx3）のみ処理され、偶数番目は無視される仕組み。
で、アトリビュートエリアの方は40バイトしかなくて、スクリーンエリアと1対1ではなかったのですが、この部分は、ランレングス式（と言えばいいのか？）で処理されてました。その行の最初からキャラクタの赤、5文字からはグラフィックの青、みたいにそれぞれ2バイトで。で、キャラクタとグラフィックでは同じ色でも、カラーコードが別にしてあって、それで切り替えていたのだと。
ここの制御部分は結構いい加減で、特にBASICで処理すると、画面を消去しないまま20回以上、１ラインで色やキャラクタ／グラフィックの切り替えを行うと、色化けや文字化けが発生してました。回避するには、POKE文で直接アトリビュートをいじるか、マシン語使うしかなかったです。
逆にそれを逆手にとって、POKE文一発で（BASICとしては）高速に棒グラフを書き換え、なんてのをやってたなあ。で、自作ゲームのタイマーに応用して、カラーアトリビュートの仕組みの解説つけてベーマガに投稿したのもいい思い出です。
Re:PC-8001のグラフィック (スコア:1)
なんか N-BASIC でグラフを書いたら、線が交差するところに変な文字が出てきたりしたのは。
長年の謎が解けた。ありがとうございます。
Re:PC-8001のグラフィック (スコア:0)
Re:PC-8001のグラフィック (スコア:0)
Re:PC-8001のグラフィック (スコア:0)
Re:PC-8001のグラフィック (スコア:1, 参考になる)
たしか、uPD3301がやっていたことは、アトリビュートエリアの管理と出力だけだったように記憶しています。色情報としての3ビットと並んで、キャラクタかグラフィックかを示す1ビットが、アトリビュートエリアの内容に応じたタイミングでuPD3301から出力され、この1ビットによって、キャラクタジェネレータROMの出力と、その「原始的TTL回路」の出力が切り替えられていたような……。違いましたっけ？