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/

753 ：ナイコンさん：2022/10/20(木) 10:49:07.74 .net

>>749
68010なら富士通のFACOM Gシリーズがある。87年

68000は設計が古すぎてWSのUNIXが要求する堅牢性を満たす事ができない。
68010でそれらを修正して満たせたものの、性能はほぼ据え置きなので無理があって使用感もかなり重かった。

754 ：ナイコンさん：2022/10/20(木) 19:32:35.08 .net

X68kは方向性がゲーム機なんだから頭を使う系の面白さとは無縁だろ

755 ：ナイコンさん：2022/10/22(土) 13:42:02.32 .net

マルチタスクOSを動かすならスッピンの68000より8086のほうがマシまである
8086だと、皆が大嫌いなセグメントレジスタを使えばプロセスを分離するのは、割りと簡単に作れたから
メモリ保護やら隠ぺいやらの機能は無いけどな

756 ：ナイコンさん：2022/10/22(土) 16:43:24.10 .net

8086でマルチタスクは1970年頃ならともかく、1987年になると80386が出荷された時代だからやりたくないな。

757 ：ナイコンさん：2022/10/22(土) 18:15:04.54 .net

87年で新機種のパソコンが68000と言うのがあり得ないレベルに非常識だったがな

758 ：ナイコンさん：2022/10/22(土) 20:29:45.69 .net

V30！

759 ：ナイコンさん：2022/10/22(土) 21:21:11.57 .net

68000は研究者向け製品としては優れてたが、工業製品としてはダメだった
一流のガンダムのような商品を作って大量生産すると言う形式が失敗した例だろう

日本人はその例を学習せずひたすら同じ間違いを続けている

インテルがやったのは、大衆向けの商品に最新の研究成果を注ぎ込み
常に最適最高のＣＰＵを供給して最大の売り上げを得る手法だ
そのためにはちゃんと広告や企画なども計画立ててる
計画を立ててるからこそ毎年新製品を出せる
その製品は自社のＣＰＵとＭＳのＯＳとソフトハウスのソフトウェアによって作られてる
なんとまぁ完璧な生態系だ

モトローラはそれが足りなかった
68000を搭載したＣＰＵは手軽にビジネスのプレゼンを作れなかったので、モトローラ社内ではインテルのパソコンを使っただろう

760 ：ナイコンさん：2022/10/22(土) 21:31:23.88 .net

だろう物語　太郎著

761 ：ナイコンさん：2022/10/22(土) 22:01:46.16 .net

>>759
68000は製品としては3000万個以上出荷されているから大成功やで
もっともモトローラは儲かってなさそうだがな

762 ：ナイコンさん：2022/10/23(日) 02:27:00.31 .net

68000は高速化できなかったのがな…

763 ：ナイコンさん：2022/10/23(日) 09:03:17.43 .net

1987年なら68EC020ぐらいの性能は欲しいところ
モトローラも普及目指して68EC020を戦略的低価格まで落とせばよかったのに

764 ：ナイコンさん：2022/10/23(日) 22:33:36.27 .net

68000はメモリ空間が広いだけしか取り柄なかった

765 ：ナイコンさん：2022/10/23(日) 22:41:27.15 .net

セグメントレジスタなんかやってられないよ。

766 ：ナイコンさん：2022/10/27(木) 21:51:45.28 .net

シングルプロセスなら68000は悪くなかったが
マルチプロセス、マルチスレッドなら80x86系のほうが実現は楽だったし、デバグも月とスッポンぐらいの違いで68000は面倒だった

767 ：ナイコンさん：2022/10/27(木) 22:04:09.47 .net

そりゃMMUが組み込まれた方が向いているだろうけど、
386用のOSが出てくるのはずっと後だから。

768 ：ナイコンさん：2022/10/28(金) 08:57:40.37 .net

セグメントは仮想メモリのご先祖様的なものだからな
アンチセグメントが誇張して悪し様に言ってるほど悪くないどころか、
64k越えない範囲なら便利な機能だっまよ
64k超えのデータ扱うのが一般的になったころは386や486だったし何の不都合もなかった

769 ：ナイコンさん：2022/10/28(金) 09:03:17.25 .net

セグメントもMMUの一種でしかなく、MMUが何か無いと話にならないので、MMU有りとMMU無しを比較するのは機能のある無しそのものでしかない
機能のある無しの優劣と、MMUの中でセグメント式が使いにくいって比較とが混同されてる

770 ：ナイコンさん：2022/10/28(金) 12:20:28.87 .net

68000は8086以下だったって結論しかない

771 ：ナイコンさん：2022/10/28(金) 12:21:39.14 .net

>>768

>セグメントは仮想メモリのご先祖様的なものだからな

セグメント機能が進化して仮想メモリになるわけではない。
8086のセグメントでは仮想メモリは使えないよ。

>64k超えのデータ扱うのが一般的になったころは386や486だった

8086や8ビットマイコンでは扱えなかったから分割操作していただけで、
一度に64Kを超えるものを扱いたい要求はふつうに発生していた。

772 ：ナイコンさん：2022/10/28(金) 13:01:42.65 .net

8086はセグメントサイズが64kに制限されてたから評価悪いだけなのを、セグメントだから評価わるかったんだと履き違えてる馬鹿のひとつ覚えがまた始まったなw

773 ：ナイコンさん：2022/10/28(金) 14:26:10.43 .net

要求があった＝必須だったと暗黙の前提にしちゃう馬鹿が、思い込みだけでセグメントはーってやってるだけだろ

774 ：ナイコンさん：2022/10/28(金) 15:47:16.86 .net

CP/Mの移植ばかりだった頃は必須ではないな。

775 ：ナイコンさん：2022/10/28(金) 22:52:43.79 .net

Windowsになる前は必須じゃねーよw

776 ：ナイコンさん：2022/10/29(土) 00:06:49.68 .net

Windowsの前もコンベンショナルメモリ開けるの大変だっただろ。

777 ：ナイコンさん：2022/10/29(土) 14:40:38.13 .net

SX-Windowよりは楽だったけどな(真顔)
32ビット環境じゃないわ、あのクソSX-Windowsは

778 ：ナイコンさん：2022/10/29(土) 19:21:42.85 .net

ページングできないMMUではマルチタスクはまともにつくれない。
8086も68000も向いておらん。WSはちゃんとMMU外付けしている。

779 ：ナイコンさん：2022/10/31(月) 02:44:02.13 .net

アオキさぁ（真顔）

780 ：ナイコンさん：2022/10/31(月) 14:57:43.56 .net

「まともな」マルチタスクの条件にページング方式なMMUって必須か？

781 ：ナイコンさん：2022/10/31(月) 15:22:53.75 .net

ノンプリエンプティブマルチタスクではなく、プリエンプティブマルチタスクじゃないとまともなマルチタスクではないって意味ならMMUは要らないよな
なんかマルチタスクではない別な事と勘違いしてるような

782 ：ナイコンさん：2022/10/31(月) 15:39:35.45 .net

MS-Windowsはまともなマルチタスク
SX-Windowはまともでない半端なマルチタスク

783 ：ナイコンさん：2022/10/31(月) 16:13:02.61 .net

MMUを使わないマルチタスクって、終了したタスクのメモリ回収ってどうするつもり?

784 ：ナイコンさん：2022/10/31(月) 19:09:50.92 .net

>>783
malloc() みたいに Heap 的なものでOSが把握する全メモリ空間から確保するなら、
アプリ終了時にOSが全てfree()することも不可能ではない。
ただし、この方式では、アプリのメモリ空間は断片化し、複数のアプリが
使うメモリーがアドレス空間内で入り交ざったようになる。
もちろん、MMUがなければ、メモリ保護も出来ないから、他のアプリのメモリー
空間を別のアプリが書き換えてしまうことも可能になるから、安全な環境は
作りえないだろうが。

785 ：ナイコンさん：2022/10/31(月) 20:12:14.53 .net

>>784
メモリ保護に目をつぶってもガベージコレクションしまくるんでしょ？
まともじゃない。

786 ：ナイコンさん：2022/10/31(月) 20:12:28.92 .net

メモリフラグメントはMMUの有無に関係なく発生する

787 ：ナイコンさん：2022/10/31(月) 20:37:30.26 .net

頻度が違いすぎる。

788 ：ナイコンさん：2022/10/31(月) 22:04:48.00 .net

>>786
仮想アドレスと物理アドレスの対応関係を作れるタイプのものであるなら、
仮想アドレス空間内で複数アプリのメモリー領域が交互に入り混じったり
することは無い。
1つのアプリ内で過去にmallocしたメモリーブロックを
複雑なタイミングでfreeすると断片化することがあるが、それはまた別の問題。

789 ：ナイコンさん：2022/10/31(月) 22:31:33.77 .net

>>788
[補足]
仮想アドレスと物理アドレスの対応関係を作れるCPUの場合、
なぜ、アドレス空間内で複数アプリのアドレス領域が入り混じらないかというと、
アプリ毎に独立した仮想アドレス空間を持つことができるから。
たとえば2つのアプリA, Bがあったとすると、Aのアドレス空間とBのアドレス空間を
全く別にすることが出来る。

790 ：ナイコンさん：2022/11/01(火) 16:35:46.05 .net

i386のセグメントレジスタがもっと積極的に使われればよかったのにね。
x64では実質的に無くなってしまった。

791 ：ナイコンさん：2022/11/01(火) 23:37:40.80 .net

>>790
サイズがでかくなり、CPUの最大のint整数に入らないので効率が落ちる。

792 ：ナイコンさん：2022/11/01(火) 23:39:56.12 .net

>>791
[補足]
たとえば、32BIT CPUなら、アドレスが(最大)32BITだが、整数型の最大のビット数も
32BIT。だから、セグメントを用いない線形アドレスなら、丁度、ポインタ(アドレス)
が32BIT 整数に入るので便利。
ところが、セグメントを用いると、セグメント:32BITアドレスとなってしまい、
32BIT整数に入らなくなる。
これで効率が落ちる。

793 ：ナイコンさん：2022/11/01(火) 23:42:57.11 .net

メモリ保護ってのは基本はマルチユーザー向けの機能で、個人ユースでは煩わしいし当時のコスト的にオミットされて正解だった
SX-Windowの時代はWindows3.1で、あれはページング方式ではなく、セグメント方式よね
64KB・640KB・1MBで壁があるハードウェアよりリニアなメモリ空間のほうががいいよ

794 ：ナイコンさん：2022/11/02(水) 00:15:07.19 .net

x86の場合、セグメントレジスタは、32BITモードだと、
「セレクタ」と呼ばれる値を格納するものになる。しかし、セレクタ
は16BITしかなくて、65536個しか区別できない。
なので、アプリで構造体間のメモリ保護に用いようなどとすると、
65536個の構造体しか扱えないことになり、現実的に使い物にならない。

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 命令は遅いので汎用命令が書いた方がなぜか速い。
など。
そうやって細かい高速化が施されているのに、エミュレータでは速度バランスが逆転していて
努力が無に帰してしまうことがある。