PC98とX68000ってどっちが性能上なの？ part2

1 ：ナイコンさん：2022/07/10(日) 22:27:58 .net

PC-98の圧勝かな？
最高性能のPC-98→PC-9821Ra43 ( Celeron/433MHz )
最高性能のx68→X68030 ( MC68EC030/25MHz )


過去スレ
PC98とX68000ってどっちが性能上なの？
https://kizuna.5ch.net/test/read.cgi/i4004/1648117339/

795 ：ナイコンさん：2022/11/02(水) 00:23:59.37 .net

386のセグメントって開始アドレスと大きさを表していて、リニアに4Gだよ。
結局メジャーなOSは全セグメントレジスタ0で使っているみたいだけど。

796 ：ナイコンさん：2022/11/02(水) 01:08:33.45 .net

>>795
セグメント・ディスクリプタなるものがあり、それを配列上に並べた
ものをセグメント・ディスクリプタ・デーブル(SDT)と呼ぶ。
その配列の要素番号がセレクタ値。
セグメント・ディスクリプタには、セグメントのベースアドレスとサイズ
及び、書き込み禁止、実行禁止などのフラグ類を指定する。
なので、開始アドレスと、サイズを(忘れたが確か4096バイト単位で)指定できる。
WindowsやLinuxでは、アプリケーションが使うセグメントの
開始アドレスは0。サイズは、4GB(または、2GB位)
にしてある。

797 ：ナイコンさん：2022/11/02(水) 09:39:59.49 .net

GDTとLDTの組み合わせでセレクタの指すアドレスが決まるんだが、本当に386の事がわかってるのかな？

798 ：ナイコンさん：2022/11/02(水) 10:07:42.06 .net

セレクタが16ビットだから65536個、とか言ってる時点で解ってないかと

799 ：ナイコンさん：2022/11/02(水) 10:50:07.46 .net

5chや2chは、ちょっとレベルの高いことを書き込むと、馬鹿が反論してくる。

800 ：ナイコンさん：2022/11/02(水) 13:07:21.45 .net

そして長文さんに突っ込まれて黙りこんでしまうまでがテンプレ。

801 ：ナイコンさん：2022/11/02(水) 13:37:41.05 .net

>>772
ソースは読み難いよ・・・

802 ：ナイコンさん：2022/11/02(水) 21:14:56.82 .net

俺はZ80→8086とステップアップしたからだと思うが、8086のソースを読みにくいと思った事はないな

803 ：ナイコンさん：2022/11/03(木) 11:10:11.16 .net

68000と8086のソース見比べた感想を言えよ！
8080上がりな俺には68000のソースは読みやすかったぞ

ザイログ表記も読みやすいと思ったけど

804 ：ナイコンさん：2022/11/03(木) 12:47:12.26 .net

JavaScriptとJavaくらいの差？

805 ：ナイコンさん：2022/11/03(木) 14:08:22.66 .net

cとc#ぐらいの違い

806 ：ナイコンさん：2022/11/04(金) 15:55:58.94 .net

>>802

DS/SSが64Kに収まるプログラムはあまり変わらないと思うが....
64K超すコード書いた?

807 ：ナイコンさん：2022/11/05(土) 02:17:19.82 .net

>>772
セグメントサイズが 4GB まで広がった後も、
セグメントレジスタを使ったポインタを一般的に記録するためには、
セグメントレジスタ用に 16BIT、オフセットアドレスに 32BITの
48BITの領域が必要となり非効率。
また、セグメントレジスタに新しい値を代入するると、SDTのメモリー領域から
CPU内部に値を取り込む時間と、それを認識する時間が必要となるので、
普通のmov命令よりもかなり時間がかかってしまう。

808 ：ナイコンさん：2022/11/05(土) 02:26:20.45 .net

>>807
[補足]
「セグメントレジスタ用に 16BIT、オフセットアドレスに 32BITの
　48BITの領域が必要となり非効率」の部分について。
セグメントを使わなかった場合、32BITのあらゆるアドレスを32BIT
(4バイト)で記録できるので、32BITの汎用レジスタにすっぽり収まるし、
リンクリストを作る場合も、リンクポインタを4バイトのメンバ変数に
記録することが出来る。
ところが、セグメントレジスタを使ったポインタを記録するには、
一般的には48BIT(6バイト)の領域が必要となる。
そのため、リンクリストを作る場合、リンクポインタに6バイトの領域が
必要となんる。1ノードあたりにこのポインタが、双方向リストの場合、
2つずつ必要となるから、ノードの個数をNとした場合、N * 12バイト
必要となる。一方、セグメントを使わない方式の場合、N * 8バイトで済む。

また、汎用レジスタは32BITなので、48BITの値を入れることが出来ない。
なので、基本的に48BITのポインタは1クロックでコピーすることも出来ない。
WindowsのSendMessage()やPostMessage()では、wParam, lParamで
32BITの値を2つ渡すことができるようになっているが、32BITのポインタなら
2つのポインタをとても簡単に渡すことが出来る。ところが、48BITのポインタ
なら、1つのポインタをwParamとlParamの2つに分けて渡す事が必要となり、
受け取る側では、別れていたポインタを1つに合体するような処理が必要と
なってしまう。

809 ：ナイコンさん：2022/11/05(土) 02:29:57.78 .net

>>808
[補足2]
さらにいえば、他のCPUへ移植性が失われてしまう問題が有る。
今のWindowsでは、(積極的には)セグメントを使って無いので、Armなどにも
無理なく移植することが出来ている。
もし、x86でセグメントを積極的に使ってしまっていた場合、Armには
移植できなかったことであろう。

810 ：ナイコンさん：2022/11/05(土) 03:41:23.00 .net

もともとWinNTはx86だけがターゲットではなくて
MIPSなどもターゲットだったから使えなかったのではないかと。

811 ：ナイコンさん：2022/11/05(土) 09:48:18.15 .net

MIPS, PowerPC, Alpha版があったね

812 ：ナイコンさん：2022/11/05(土) 10:22:12.59 .net

Windowsだけ取り上げて80x86をダメ扱いしたいだけかよw

813 ：ナイコンさん：2022/11/05(土) 13:02:40.90 .net

>>812
x86のセグメントは現実的に効率のよい使い方が見つからない。
もしかして配列の範囲チェックに使うつもり？
だとすると、配列要素数は任意に取れるが、配列の種類というか配列自体の
個数は、基本的に65536個に制限されるぞ。

814 ：ナイコンさん：2022/11/05(土) 17:25:02.85 .net

セグメントの効率が悪い、というのが問題になるケースって、なに？
配列の要素数が65536あればたいていの用途には耐えられるよ？

ありもしないトラブルを挙げて「だからセグメントはー！」ってやってるのってさ、
ワクチン反対派みたいだよね

815 ：ナイコンさん：2022/11/05(土) 17:59:24.13 .net

>>814
ここではセグメントは絶対悪なんだぞ
セグメント方式に利点があってもそれらは全て無いものあつかいされるのだ
ワクチンと同じで完璧でないから叩かれるだけのサンドバッグだからセグメントガーには反論しちゃダメだよ

816 ：ナイコンさん：2022/11/06(日) 00:00:13.58 .net

>>814
あなた、IQ低すぎるね。
配列の要素数は任意個だが、配列の個数が65536個に制限されるとさっきから言っている。
それでもなお、少な過ぎると言っている。
てんで話がかみ合ってない。

817 ：ナイコンさん：2022/11/06(日) 00:03:03.66 .net

無知すぎる人に補足しておこう。
int arr[N];
の N が配列の要素数。
int arr1[N1];
int arr2[N2];
int arr3[N3];
の場合、要素数が、N1個、N2個、N3個の配列が3 個あり、
「配列の個数」は3。
こおのように配列のよう総数と配列の個数は全く別の概念。

818 ：ナイコンさん：2022/11/06(日) 05:04:11.52 .net

ssが枯渇するとなかなか悲惨

819 ：ナイコンさん：2022/11/06(日) 10:05:56.73 .net

DOS時代にスタックオーバーフロー(アンダーフローか？)は経験あるけど、そう何度もあることじゃなかったな
>>816
配列の個数もたりないとか言うあり得ないトラブル出してきてるだけにしか見えないのは俺の目の錯覚かな？
陰謀論やりたいならTwitterでやれよw

820 ：ナイコンさん：2022/11/06(日) 13:58:40.57 .net

>>819
有り得ないなんていったら、64BIT OS要らないし、4GB以上のメモリーも
要らない。

821 ：ナイコンさん：2022/11/06(日) 14:59:38.06 .net

昔スタックの消費を抑えるためにリエントラント諦めたこと思い出した。

822 ：ナイコンさん：2022/11/09(水) 22:27:25.52 .net

WindowsでもLinuxでもスタックオーバーフローはあるぞ

>>820
具体的な例を出せないおまけの負けだなw

823 ：ナイコンさん：2022/11/10(木) 01:34:48.99 .net

>>822
あなたは本当に配列の個数が65536個に収まると思ってるのかいな。

824 ：ナイコンさん：2022/11/10(木) 17:19:31.46 .net

8086 << M68000
80286 > M68000
じゃね？

マルチプロセス前提の386は比べるまでも無いけど

825 ：ナイコンさん：2022/11/10(木) 18:08:16.07 .net

正直言って80286はかなり速い
学校にあった9801VXいじって腰抜かした
プログラム作って動かした体感だと
80286 10MHz ＝ 68000 16MHz

826 ：ナイコンさん：2022/11/10(木) 18:27:42.04 .net

更に、68000が16MHzを使えるようになった頃には、
80286は25MHzが使えるようになってるからやたらと速いCPU

827 ：ナイコンさん：2022/11/10(木) 19:02:57.55 .net

8086 < M68000
V30 = M68000 = 8086 ×1.3倍
80286 = 8086×2倍 > M68000
80386 = 80286(DOS)
こんなイメージだったな

828 ：ナイコンさん：2022/11/10(木) 19:53:49.02 .net

98の世界じゃあ286は最低ラインのスペックだよね

829 ：ナイコンさん：2022/11/10(木) 20:26:23.00 .net

98は漢字テキストVRAMとC-BUSが優秀だからなー
X68Kとは基礎体力が違いすぎる。

830 ：ナイコンさん：2022/11/10(木) 20:39:45.77 .net

68000 10MHz＝80286 5MHzのイメージだな
68000の遅さはメモリのせいもあるかもだが

831 ：ナイコンさん：2022/11/10(木) 23:01:54.60 .net

ただ、BASIC言語のグラフィックのLINE文は、X68000は速かったと思う。

832 ：ナイコンさん：2022/11/10(木) 23:18:18.71 .net

>>829
テキストを扱うと9801は速かった。
グラフィックは違うはず。
9801は、プレーン方式、X68000はパックドピクセル方式だったのも、
後者はゲームなどに向いていた一つの原因。
これもあって1ドット単位の横スクロールは、9801では速度が出せなかった。
9801で、黒と青などの単一色の画面のゲームがあったもプレーン方式で速度
を出すため。

833 ：ナイコンさん：2022/11/10(木) 23:39:05.93 .net

CPUの話
デバイスの話

色々あるさー

98ユーザー「286と比べM68000はトランジスタ量少ないだろ！」
68ユーザー「ゲーム比べたら分かんだろ！」

平行線である(笑)

834 ：ナイコンさん：2022/11/10(木) 23:57:28.78 .net

>>828
はあ？
最低は8086だろ

835 ：ナイコンさん：2022/11/11(金) 00:01:00.90 .net

8086と比べるのは68000
286と比べるのは68020
386と比べるのは68030

836 ：ナイコンさん：2022/11/11(金) 10:23:06.93 .net

>>831
いや比較にならん程9801VXの方が速かった
X68000 10MHzとPC9801VX 10MHzで大量のラインを描画させるとVXは3倍もの速度で描画される
後から知ったが9801VXはハードウェアでライン描画しててこいつがとんでもなく速い

837 ：ナイコンさん：2022/11/11(金) 10:28:00.93 .net

>>829
漢字VRAMは正直汎用性がなくいまいちだと思う
フォントも変えられないフォントサイズも変えられない
グラフィックを2画面合成できる設計にして片方を文字表示に使う設計の方が良かったと思う
TOWNSもそうだけど後年に出たマシンはみな漢字VRAMは搭載してない
一太郎も結局倍角や特殊表示の為にグラフィックに文字描画してる

838 ：ナイコンさん：2022/11/11(金) 10:49:22.64 .net

>>836
X68000は垂直VRAMだからダイレクトに描画できるんだよ

839 ：ナイコンさん：2022/11/11(金) 12:01:15.20 .net

>>838
そんなこと知ってるけどCPU描画のX68000よりハードウェア描画のPC9801VXの方が圧倒的に速かった
実機で実際にテストしたんだから間違いない
本当に圧倒的と言えるほどの速度差がある

840 ：ナイコンさん：2022/11/11(金) 12:09:28.15 .net

>>837

後年というか、486くらいになると性能があがってしまい、
テキストVRAM自体の意味が薄れてしまうからね。
386の頃までは圧倒的に有利だったよ。

一太郎はグラフィックとテキストVRAMのモード切り替えだった。

X68Kの設計はCPUパワーが68030くらいあればよかったと思うけど、
68000ではパワー不足感がすごい。

841 ：ナイコンさん：2022/11/11(金) 14:42:57.14 .net

>>839
そう語っている本があったのを知ってる。ハードウェアとはGDCと呼ばれていたもの。
しかし、実際にPC-9801FAで試して見ると、直線は、GRCGでマシン語で書いたほうが
BIOSでGDCを使って書くよりずっと速かった。

842 ：ナイコンさん：2022/11/11(金) 14:44:26.52 .net

>>836
PC-9801のライン文はそんなに言うほど速くない。
あなたは何か勘違いしている。
せいぜいX68000のライン文と同じくらいだったはず。

843 ：ナイコンさん：2022/11/11(金) 14:45:38.12 .net

>>840
いや、9801においては、テキストはグラフィックより圧倒的に速かった。
あなたも勘違いしている。それは、DOS/V機。
DOS/V機はグラフィックが速かったら悪しい。

844 ：ナイコンさん：2022/11/11(金) 14:58:48.85 .net

>>842
いやPC9801VXのBASICのライン描画はX68000なんか比較にならないほど速いよ
VXの隣にVMがあったけどこっちだと遅い、CPUパワーの差以上に遅い
何故ならVXはハードウェア描画でVMはソフトウェア描画だったから

845 ：ナイコンさん：2022/11/11(金) 15:00:47.35 .net

>>841
そりゃFAは486だからだろｗ
全ての命令を1クロックで実行してしまう超弩級CPUだぞ

846 ：ナイコンさん：2022/11/11(金) 15:02:13.45 .net

>>845
CPUは速くてもG-VRAMへめちゃくちゃ遅くて、せいぜい、1MHz間隔でしか
読み書きできないぞ。

847 ：ナイコンさん：2022/11/11(金) 15:03:54.36 .net

9801のプログラマはめちゃくちゃ研究して努力してマシン語でやっと高速に
描いていただけで、別にマシンが速かったわけではないぞ。

848 ：ナイコンさん：2022/11/11(金) 15:06:22.50 .net

当時の98のゲームは、プログラミング能力によって高速にしていただけだ。
ほとんどの人はその様な速度を得ることが出来なかった。
例えば「差分描画」というテクニックとかで。
ポリゴンを描くのでさえ変化した部分を見つけて差分描画していた人がいる位。
そのようなテクニックを使った場合、実際に書いていたのはポリゴンの辺の
近くの小さな面積で、ポリゴン全体を描いていたわけではない。

849 ：ナイコンさん：2022/11/11(金) 15:09:44.11 .net

>>845
486SX-16MHzというミラクルCPUだからなｗｗ

850 ：ナイコンさん：2022/11/11(金) 15:19:20.17 .net

>>849
CPUは速いがGVRAMが遅いからゲーム製作は難しかったんだぞ。

851 ：ナイコンさん：2022/11/11(金) 15:26:45.17 .net

当時から、差分描画テクニックで高速化した3Dゲームを見せると、
ハードが高速だと勘違いされて困ったことがある。
いくら言っても理解してもらえなかった。

852 ：ナイコンさん：2022/11/11(金) 15:36:09.49 .net

98エミュレータは有れども、BASIC言語は著作権の問題で使えないし、
速度も実機とエミュレータでは同じではないかも知れないので、いくらでも
歴史を捏造できてしまう状況にある。
そうやって、技術的に誰が優れていたかを捏造する人がいる。

853 ：ナイコンさん：2022/11/11(金) 15:43:44.45 .net

話はずれるけど、エミュレータって、実機で遅い命令が速くて、実機で速い命令が遅い
というようなことが有り得て、話がややこしくなることがある。
一個の命令で書けるが遅い場合に、複数の命令で描いた方が速い場合が有る。
昔の場合なら、
・loop label 命令は dec cx, jnz label と2つの命令で書いた方が速い。
・dec cx は専用命令なのに、486ではなぜかsub cx,1 と書いた方が速い。
・pusha, popa より、push ax, push bx, push cx, push si, push diなどと
　ばらばらにpush, pop した方が速い。
・nop命令は遅いので別の命令にした方が速いことがある。
・専用命令であるenter, leave 命令は遅いので汎用命令が書いた方がなぜか速い。
など。
そうやって細かい高速化が施されているのに、エミュレータでは速度バランスが逆転していて
努力が無に帰してしまうことがある。

854 ：ナイコンさん：2022/11/11(金) 16:16:37.75 .net

テキストVRAMを誇ってるけどX68000の設計チームはX1turboでもうやったことだから
そこを持ち上げても何にもならんよ

855 ：ナイコンさん：2022/11/11(金) 16:19:57.83 .net

>>854
ハード屋じゃないので、「ハードウェアを誇る」という意味が分からない。
ハードは誰かに作らせておけばいいという感覚がある。

856 ：ナイコンさん：2022/11/11(金) 16:53:57.02 .net

ケンカって(笑)
PC88後期、PC-286VFユーザーだったけど
正直、ｘ68欲しくてしょうがなかったけどなぁ

当時、x68中古の広告ずっと見てたわ(笑)
TOWNSは欲しくなかったなぁ

857 ：ナイコンさん：2022/11/11(金) 20:15:43.84 .net

>>854

遅い68000で使うための工夫がろくにないのがな。
MS-DOSみたいなテキストVRAM前提なOSだったし、よくわからん機械だった。

858 ：ナイコンさん：2022/11/11(金) 21:32:12.03 .net

1987年スタートのマシンで漢字VRAMなんて時代遅れの物を採用はありえねえだろ
PC9801は1982年発売で古かったから仕方ないにしても

それからX68000のテキスト画面には高速なラスターコピー機能が付いてて滑らかにテキストスクロールできる
PC9801にはできないヌルヌル4ドットテキストスクロールもできる

859 ：ナイコンさん：2022/11/11(金) 21:43:28.94 .net

あれのどこが高速だったんだ？
嘘も大概にしとけよ

860 ：ナイコンさん：2022/11/11(金) 21:56:30.19 .net

>>859
テキストエディタ(superED)も通信ソフト(TMN)もヌルヌルスクロールだよ
Human68kも付属のiocs.xを入れればヌルヌル

861 ：ナイコンさん：2022/11/11(金) 22:23:51.67 .net

>>858
OSがテキスト前提なのにテキストVRAMなしは効率が悪いだろう。
バランスが悪い。

862 ：ナイコンさん：2022/11/11(金) 22:27:20.99 .net

ヌルヌルスクロールじゃなくて、ノロノロスクロールが正しい。
良い子のみんなは騙されないようにね

863 ：ナイコンさん：2022/11/11(金) 22:43:40.80 .net

98はMOSTだっけ

864 ：ナイコンさん：2022/11/11(金) 22:45:24.00 .net

PC-8801ユーザーからすれば、X68000は凄いというイメージがあった。
98はCPUはクロックは速いが、16BITモード(DOS)だとセグメントに64KBの壁が
あってポログラムは大変だったし、グラフィックが遅くてゲームには向いてなかった。

865 ：ナイコンさん：2022/11/11(金) 23:37:34.54 .net

>>862
superEDはめちゃくちゃ速いぞ
あれ以上速かったら目がついていかないわ

866 ：ナイコンさん：2022/11/12(土) 01:23:46.48 .net

>>862
ちゃんとVSYNCと同期とってヌルヌルスクロールしてる
初期のエディタはDOSコールのみで作られてたのだろう
ハードウェアを直接操作すれば馬鹿みたいに速くなって当然

867 ：ナイコンさん：2022/11/12(土) 02:19:00.52 .net

X68000はテキストも専用のBITMAP方式(プレーン方式)のVRAMを4枚持っていて、
パックドピクセル方式のグラフィックVRAMと重ね合わせ出来て、さらに
それに加えてスプライトも重ねあわせ出来るのでかなり凄い。
グラフィックの基本設計に関してはX68000の圧勝。
速度は知らんが、ゲームを見ている限り、X68000は速いように見える。

868 ：ナイコンさん：2022/11/12(土) 02:20:28.72 .net

9801のグラフィックの速度を見るとき、平均的なゲームの速度を見なくてはならない。
一部の特殊なゲームの速度が速くても、そのゲームが超絶テクニックで高速化していた
だけかも知れないので、それをもってして9801が速いと言うことにはならない。

869 ：ナイコンさん：2022/11/12(土) 08:17:36.29 .net

ゲームは重ね合わせとスクロールがハード実装されている方が有利だからな。

870 ：ナイコンさん：2022/11/12(土) 08:31:38.40 .net

MSXとファミコンのよう
CPU性能は明らかにMSXのほうが高かったのに
表示能力のせいでファミコンからMSXへの移植は劣化している感が半端なかった

871 ：ナイコンさん：2022/11/12(土) 09:22:15.43 .net

>>868
EGC搭載以降の98はラインやボックスフィルといった単純なグラフィックコマンドだけは爆速
VXのBASICのグラフィック命令が爆速なのもこのため

872 ：ナイコンさん：2022/11/12(土) 09:42:57.21 .net

98もスプライトとか重ね合わせとか後付けのビデオカード出ればよかったが…
Win95が出るまではビデオの方向性なかったからなー

873 ：ナイコンさん：2022/11/12(土) 11:13:43.98 .net

superEDをエミュに入れて使ってみたがやはり速いな
10MhzでもYoutubeにある98の檸檬のCMでIBMとの比較スクロールより速い
96x32文字で画面の広さも良し

874 ：ナイコンさん：2022/11/12(土) 14:40:02.61 .net

あの一太郎のやつか?
ワープロとテキストエディタを比較してするとは････

875 ：ナイコンさん：2022/11/12(土) 21:42:33.21 .net

superEDと比べるなら一太郎ではなく、Vzだな

876 ：ナイコンさん：2022/11/12(土) 22:01:24.58 .net

>>875
98のVzじゃテキストの4ドットスクロールや8ドットスクロールはできないから98の負けだな

877 ：ナイコンさん：2022/11/12(土) 23:15:50.72 .net

98のテキストは1ドットスクロールできるんだが
そんな事も知らんで勝ち誇られてもなぁ

878 ：ナイコンさん：2022/11/12(土) 23:36:55.36 .net

98のテキストで1ドットスクロール？
表示開始位置を変えてく機能を上手く使えば1ドットスクロールに見せられなくもないが、アレを1ドットスクロールと言って良いんかね？

879 ：ナイコンさん：2022/11/12(土) 23:50:44.59 .net

>>876
OPT.1+ROLLUP/DOWNのこれ4ドットスクロールなのか
VSYNCと縦解像度512ドットのせいか、1ドットスクロールかと思えるほどヌルヌルに感じる
キーリピート間隔を無視したOPT.1+↑↓はサクサクだし
漢字VRAMなんて要らないと思わせる速度は確実に持ってる

880 ：ナイコンさん：2022/11/12(土) 23:52:39.03 .net

表示開始位置を変える手法ならX68000も同じとこ出来るよなｗ

881 ：ナイコンさん：2022/11/13(日) 11:46:26.13 .net

X68Kのテキストって早いイメージなかったけど、
後年はソフトの工夫で改善できたのかな？

882 ：ナイコンさん：2022/11/13(日) 12:20:11.91 .net

>>881
iocs.xが付属してきてから(エキスパート、プロからか？)はコマンドのスクロールも普通に速いよ
スルスルーって文字スクロールする

883 ：ナイコンさん：2022/11/13(日) 13:05:00.36 .net

>>864
90年代前期頃、PC98用エロゲ作ってる小さなソフトハウスで働いてた
MS-C++ 7.0とアセンブラを使ってMIFESでプログラミングしてた
PC98はあまり好きなPCではなかったが当時は98一強だったから仕方なかった

884 ：ナイコンさん：2022/11/13(日) 13:14:24.73 .net

高速なＣＰＵマシンって98シリーズしか無かったからなぁ
高速なＣＰＵ周り、充分なグラフィック装備！なＰＣがあったら買ってるがな

富士通「俺んところのＰＣは？」

885 ：ナイコンさん：2022/11/13(日) 13:16:54.19 .net

ＰＣ98って、ＧＲＡＭ上にあるプログラムがそのまま動いたり
要らない機能があったりしたなぁ

886 ：ナイコンさん：2022/11/13(日) 18:04:57.45 .net

98は要らない子

887 ：ナイコンさん：2022/11/13(日) 18:28:07.90 .net

>>871
一色のラインやボックスフィルをCPUで書くときに高速化できるのはGRCG。
EGCは、基本的に2D画像のブロック転送。
もし画面に見えてない部分のGVRAMの容量がもっと大きければ、EGCは
スプライトの代わりとして用いることが出来たかも知れないが、そういう
領域がほとんど無かったので640x400ドットモードでは使い辛かった。
640x200だとスプライトの代わりに用いることが出来た。
また、縦スクロールシューティングゲームでは画面の左右に黒い部分を
作り、そこにスプライトのデータを入れておいて転送するテクニックを
使った人がいた。黒い部分はテキストの「■」を上に重ね合わせて
見えなくしており、テキストに隠れた下にスプライトデータが有った。
しかし、EGCは、マスクパターンの処理が余り効率よく出来ないようだった。

888 ：ナイコンさん：2022/11/13(日) 18:39:05.78 .net

>>887
PC-9801のGVRAMは、プレーン方式で4枚のVRAM領域を使って、16色を
実現していて、各プレーンは1色しか出せない。画面に16色の図形を
描画する際には、4回分の描画が必要となる。
GRCGは、I/Oポートに、パターンを設定しておくと、マシン語で、GVRAM
に対する一回の(書き込み)mov命令で、4プレーン同時に書いてくれる。
その結果、大体4倍近い速度で固定した1つのパターンで直線やポリゴンなどが描ける様になる。
但し、GRCG OFFの時より少しWAITが増えるので、4倍にはならない。
I/Oポートは物凄く遅いため、頻繁にパターンを変えるわけにはいかないので、
固定したパターンになってしまう。だから、点線やディザパターンでの塗りつぶしには可能
といえば可能だったかも知れないが、I/Oポートが遅すぎたため、効率よくディザパターンを
縦方向に変化させることは難しかったので単色用に使われることが多かった。
また、EGCは、GVRAM上でReadしてから、Writeすると、4プレーン全体を一度に
転送できる機能を持っていた。これでブロック転送が出来た。
AND, OR などの機能も有ったが、中途半端で、ゲームに必要な MASK パターンをそれで
効率よく実現するのは難しいようだった。一度 AND してから OR すればいけたかも
しれないが、それだと半分の性能しか出ない。
ほかに、EGC用のマスクパターンを設定する I/O ポートがあったことはあったが、
I/OポートにWAITが掛かっていたので、それも効率よく使いこなすのは難しい傾向が
あった。

889 ：ナイコンさん：2022/11/13(日) 18:51:28.20 .net

>>888
[EGCの補足]
EGCを使わないでゲームのキャラクタをマスクパターンで重ね合わせようとすると、
mov bx,VRAMアドレス
mov ax,[bx]　;Read
and ax,マスクパターン
or ax,描画パターン
mov [bx],ax　;Write
のようになる。これが4プレーン分必要。
EGCの場合は、Readが不要になり、WriteだけでI/Oポートに入れたマスクパターンのandも
orもハードウェアがやってくれる機能があったから、高速にはなったことはなった。
ただ、残念なのはマスクパターンを(遅いところの)I/Oポートに入れるしかなかったことと、
描画パターンは、GVRAMから読み込まないといけなかったのに、GVRAMの見えてない部分が
少なすぎたこと。画面モードが640x400と、640x200の二種類しかなく、
後者はアスペクト比が1:2になってしまうので、使いづらく、前者はGVRAMで、画面に見えてない
部分が少なすぎた。
9801は、バックサーフェスの様な見えないGVRAMも持っていたが、それはI/Oポートを
使ってバンク切り替えしないといけなかったが、肝心の切り替えのI/Oポート
にWAITがかかっていたため切り替えに時間がかかり、バックサーフェスから
フロンとサーフェスへの転送は、効率良くは出来ないようだった。

890 ：ナイコンさん：2022/11/13(日) 19:56:37.47 .net

タイムスリップしたような錯覚をしてしまう内容だわｗ
俺は883だが当時はGRCGやEGCについて詳しく書かれている書籍が見当たらず
NECも公式に公表してなかったと記憶してるが
当時の会社に外注で出向してきていたフリーのプログラマーもGRCGやEGCについてよく分かってないと言っていた記憶がある
因みにそのフリーのプログラマーはブラックオニキス3であるムーンクリスタルを作っていた人みたいで
俺がムーンクリスタルの事を聞いたら「ソースいる？笑」と言っていた想い出
本気でソース貰えばよかったと今では後悔してる

891 ：ナイコンさん：2022/11/13(日) 22:55:29.89 .net

NEC「非公開です」

ほんと88VAとか21Xa7とかロクな事しないよな
死ねよNECと思ってた(笑)

892 ：ナイコンさん：2022/11/13(日) 22:59:54.42 .net

EGCって結局200ライン画面で使う事になるんだよな・・・・
隠れた200ラインにパターンを置いておく

でもしかし結局、普通転送で遅くても400ラインモードでゲームを作っていったほうが
現実的なんだよな(笑)

無駄な事にパソコン通信しまくって資料集めまくった・・・・

893 ：ナイコンさん：2022/11/13(日) 23:37:32.08 .net

じゃあ何でVXのライン描画はあんなに速かったんだ？
尋常じゃない速さだった

894 ：ナイコンさん：2022/11/13(日) 23:43:59.93 .net

VXはモンスターマシンよ

895 ：ナイコンさん：2022/11/13(日) 23:56:01.45 .net

交換可能な5インチベイに何でも入れれる
486換装も可能
最高ですがな