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/

687 ：ナイコンさん：[ここ壊れてます] .net

>>686
いや、アクセスはいつでも出来たが、1バイトや4バイト単位で書き込んだときに、
一定のリズムでしか書き込めなかった。
次ぎのリズムが来るでWAITされる。
それは垂直同期のリズムではない。垂直同期は秒間60回だが、
このリズムは推定秒間100万回くらい。

688 ：ナイコンさん：2022/10/05(水) 19:21:33.51 .net

WAIT？
VRAMへの書き込みがバッファされるけどCPUが止まらない、と言ってる様にしておもうのだが
それをWAITと言うのか？
WAITってCPUの動きが止まる事じゃないのか？
マイ用語かよ…

689 ：ナイコンさん：2022/10/05(水) 19:49:37.45 .net

書き込みバッファは書き込みデータを受け取ったら直ぐにCPUを解放して、CPUは別な処理ができる仕組み
これは連続書き込み処理ができずにCPUが待たされてるって主張だから別物だろう

690 ：ナイコンさん：[ここ壊れてます] .net

PC-98のGVRAMはCPUバスに直接ぶら下がってなかったからその関係でバッファされてたってことだろうな
1回のアクセスで４プレーン全部が待ち状態に入るような設計でもないだろうし連続したアドレスじゃなくてアドレス下位10ビット、11ビット離れたアドレスにならノーウェイトで触れるとか、そんな感じの設計だったんじゃないかと思う
4kか8kぐらいの単位でバッファが別になってるからと予想
日立のマルチポートRAMがそんな感じだったからそう思うだけだけど
その予想が正しいなら、だけど連続したアドレスにアクセスしないで別プレーンや離れた場所のデータ更新してれば最初に書いた場所の隣に書いても待たされることは無かろう

691 ：ナイコンさん：[ここ壊れてます] .net

>>688
ちゃんと待たされるから、WAITだよ。
よく読めよ。

692 ：ナイコンさん：[ここ壊れてます] .net

>>683
それはVRAMのウェイトじゃなくてEGCやGDC使った時のリカバリータイムのことじゃないの？

693 ：ナイコンさん：2022/10/06(木) 20:38:28.47 .net

98でVRAMアクセスがWAITするとか気になった事はなかったな
どんだけVRAM酷使したん？
グラフィック止めてMCB弄ってVRAMをコンベンショナルメモリとして使ったとかトリッキーなことでもしたの？

694 ：ナイコンさん：2022/10/06(木) 20:55:59.24 .net

グラフィックの表示読み出しとバッディングして遅くなってるんだろうから、表示止めてしまえば遅くならなかったのでは？
漢字ROM読み出しなんかも、漢字TVRAM表示を止めてしまって、グラフィックに書き込むだけの読み出し専用漢字ROMにすると普通に読み取れるとか、一々止めないとならないのが98だった

695 ：ナイコンさん：2022/10/07(金) 01:22:08.86 .net

>>694
>グラフィックの表示読み出しとバッディングして遅くなってるんだろうから、
>表示止めてしまえば遅くならなかったのでは？
1バイト/2バイト/4バイトを書き込める周期が1MHzくらいだったが、
それはほぼディスプレイの横方向のscanの速度と同じくらいであることを
昨日気付いた。
640*400の画面の場合、1バイトで横8ドット分なので、横一列が80バイト。
なので、バイト数だと80*400=32000バイト=32(KB)
これをハードウェアが60(FPS)でディスプレイに表示しようとすると、秒間
32(KB/F)*60(F/S)=1280(KB/S)=1.28(MB/S)。
もしバイト単位で読み取ってるなら、大体 1.28M(回/S)で読み取っていることになる。
垂直帰線で下から上に帰る時間も必要だからもう少し速いscan速度ではあると思うが。
2バイト単位、4バイト単位で読み取ってるかも知れないから、もっと複雑ではあるが、
大体 1(MHz) 位の周期で横に進んでいることは確か。

696 ：ナイコンさん：2022/10/07(金) 01:24:30.00 .net

>>693
>どんだけVRAM酷使したん？
https://twitter.com/YutakaAoki3/status/1556681233069142017
↑これくらい。
(deleted an unsolicited ad)

697 ：ナイコンさん：2022/10/07(金) 02:47:53.08 .net

いろいろ端折ってるな

698 ：ナイコンさん：2022/10/07(金) 15:19:18.56 .net

>>696
それ当時の98FAで実行して何フレ出てたの？

699 ：ナイコンさん：2022/10/07(金) 15:34:05.92 .net

本当に余力があるならこんなに端折った３D画面にはならないからな

700 ：ナイコンさん：2022/10/07(金) 18:04:57.91 .net

ポリゴンじゃないけど、
モザイク状態だけどヌメヌメ動くメタルホークモドキは当時からあったな。＞98

701 ：ナイコンさん：[ここ壊れてます] .net

>>698
もう忘れたけど、50FPS越える程度だったと思う。
なお、特殊な方法でどんなFPSになってもゲームの進行速度は一定になる
ようにしてあった。

702 ：ナイコンさん：[ここ壊れてます] .net

特殊な方法ねぇ

703 ：ナイコンさん：[ここ壊れてます] .net

>>701
CPUで描画するシステムで、そのフィル量とフレームレートが出てるなら、あの当時としては描画速度は速いと思うんだけど？

704 ：ナイコンさん：[ここ壊れてます] .net

>>703
断言してもいいが、それはマシンが速いからではない。

705 ：ナイコンさん：[ここ壊れてます] .net

俺がX68000を持っていたならもっと高速化できたことであろう。

706 ：ナイコンさん：[ここ壊れてます] .net

日本人は、ハードウェアだとか、アメリカ企業だとかの功績を認めて、
個人の力を舐めすぎ。それが国力低下を招いた。
https://yutakaaoki.github.io/test_say/index.html
これを試して欲しい。
誰もこの作者の功績を認めず、Wasmやymfmのせいだとばかり言う。
最近は、AIの音源分離技術を持ってきてそれで対抗しようとする人も出てきた。

707 ：ナイコンさん：2022/10/08(土) 10:24:02.92 .net

PC-98のグラフィックが遅いって騒いでも
68000の性能がV30とトントンだからねぇ
静止画以外はX68kのボロ負けなんだよな

708 ：ナイコンさん：[ここ壊れてます] .net

NECはEWS4800という68000CPUを使ったWSを上位モデルとして発売していた
よって98は68の格下

709 ：ナイコンさん：2022/10/10(月) 06:54:43.45 .net

日立は2050を68系という名の日立セカンドソースで、2020を86系で使い分けてた

710 ：ナイコンさん：2022/10/10(月) 21:32:35.58 .net

MC68000はV30よりドライストーンのスコアは上だったとは言え、誤差みたいなもんだったし
X68000は画面回りにマシンパワー喰われてその誤差みたいでも上の性能が無意味になってたな
リニアな部分のメモリ空間が広くてもDOSより手抜きのOSのせいで全て台無しだった
386のせた98相手じゃ手も足も出ないよ

711 ：ナイコンさん：2022/10/11(火) 06:36:01.43 .net

EWS4800は68系じゃなくMIPS系では?

712 ：ナイコンさん：2022/10/11(火) 11:04:14.37 .net

CISCとRISCの両方出てた

713 ：ナイコンさん：[ここ壊れてます] .net

いずれにせよオジサンたちがダメにしたのだよ

714 ：ナイコンさん：[ここ壊れてます] .net

まあある意味正解ｗ
おじさんたちが頑張ってものすごい勢いで
ＰＣを進化させたから古いＰＣは軒並み性能不足になった
当時の性能のＰＣなんて発売してもすっぺく低すぎて使えないからねｗ

いまのCPUだってそうだよね5年前の・・・・いまのCPUは5年前のでもちょっと我慢すれば使えそう
進化が停滞したんだねｗ
若い人もっと頑張ればいいのに・・・・・

715 ：ナイコンさん：2022/10/11(火) 21:44:03.95 .net

プロセスルールの微細化と高クロック化で速度が上がった時代はとうの昔に終わったのに何をか言わんや

716 ：ナイコンさん：2022/10/11(火) 21:51:34.29 .net

メモリー最大にしても85年のパソコンを90年で現役と言うのは無理だな

717 ：ナイコンさん：[ここ壊れてます] .net

全てにおいてX68kが98を凌駕してないと気がすまない
だから嘘もつきます

718 ：ナイコンさん：[ここ壊れてます] .net

別モノだから最初から相手にならんでしょ

719 ：ナイコンさん：2022/10/15(土) 10:37:34.53 .net

ワープロ検定の練習で使って
頑張っても3級合格ラインに届かなかったX68000ACE
１級検定の合格ラインを余裕で越えられたPC-9801VX

別物すぎるな
X68000は高いだけのゲーム機に過ぎなかった

720 ：ナイコンさん：[ここ壊れてます] .net

>>719
それでいいんじゃない？

X68000はスプライトを贅沢に使ったゲームを遊びたい人、作りたい人が使う機種、で合ってるだろ？

一般的なオフィスワークやるには全く向かないってだけで一概に98より劣るとは全く言えないね

実際、スプライトを贅沢に使ったゲームを遊ぶ、って用法に於いては右に出るモノなかったでしょ？世界に目を向けても。アミーガとかのストⅡ見たらそれがハッキリと理解できると思うよ

まあ98がオフィスワークにおいて世界1のマシンだったか？といえばどうなんだろね？あえてハッキリは言わんけど


ちなみ俺は当時X68000買ってません。憧れたけどね。貧乏だったのでゲームにそこまで金はかけられずPC-98でアシストレター買ってワープロやったりアシストアートでお絵描きしたりしてました

721 ：ナイコンさん：[ここ壊れてます] .net

確かになx68Kでワープロ検定なんて
思いもしないよwあなた天才だね
98はATOKが一般的だったしね
昔、職場に自分のPC持ち込んでる人がいて
辞書ソフト複数入れて環境設定して
遊んでる人いたなぁHDDの肥やしねw

722 ：ナイコンさん：[ここ壊れてます] .net

>>719
そうだと思う
自分はゲーム機として買った
当時はｘ68000以外で
ゲーセンのゲームやるならゲームの基盤とコントロールボックス（まあ電源）とモニタとコントローラ揃えなきゃいけなかった
（超劣化版でいいならファミコン、劣化版でいいならPC-enjineって選択肢はあったけど）
それと比べれば値段もほぼ同じくらいになる
アフターバーナー2と源平とバブルボブルとドラスピで元とった気になってた
それとは別にＺｏｏｍのゲームがすごく幸せだった、いまだにファランクス自力クリアした時のうれしさはおぼえてる
性能は98の方がたかい
（アリスの館で当時のプログラマの人がそういってた）

723 ：ナイコンさん：[ここ壊れてます] .net

アクションやシューティングゲームをパソコンで遊びたいならX68000をチョイスするのはアリだったけど
それ以外のゲームではX68000でなければ、と言う理由はなかったし
ホームユースでもワープロや表計算を使おうとしたら逆にX68000を選ぶ理由がない
DTMならX68000を選ぶのは悪手以外の何物でもなかった

724 ：ナイコンさん：[ここ壊れてます] .net

X68kをパソコンとして使うなら「日本語処理を実用レベルで出来るようにしろ、話しはそれからだ」だろ
ゲーム機として使うユーザばかりだったから文句言うヤツ少なかっただけだぞ

725 ：ナイコンさん：[ここ壊れてます] .net

X68000で表計算ソフトってあったんですか？

726 ：ナイコンさん：[ここ壊れてます] .net

>>725
ググったらありました

表計算ソフト Business PRO-68K CZ-212BS
高そう

727 ：ナイコンさん：[ここ壊れてます] .net

>>722
PC Engine

728 ：ナイコンさん：[ここ壊れてます] .net

X68000をパソコンとして使ってたユーザは希少だな
コスパ最悪のクソ高いゲーム機にしかしてない奴多すぎw

729 ：ナイコンさん：[ここ壊れてます] .net

今みたいに3万のCSでアーケードの完全移植なんて
できなかったんだよ
コスパはさほど悪くなかったよ
本体3万ゲーム1本4万なんてゲーム機あったんだよ
知ってる？

730 ：ナイコンさん：[ここ壊れてます] .net

ん〜X68000のPCとしての使い方ね
レイトレーシングするMDX作るZーMUSICする
DoGaするMIDIする。パソ通する位か・・

731 ：ナイコンさん：[ここ壊れてます] .net

ゲームの改造程度でもパソコンとして活かしてたろ
本来ならゲーム専用に改造機能を追加できてたべきだったが、その手のハックはまだまだ後だった

732 ：ナイコンさん：[ここ壊れてます] .net

98ユーザーこそエロゲーやって喜んでる猿しかいなかっただろｗ

733 ：ナイコンさん：[ここ壊れてます] .net

98は16色の絵描きは多かったがな。
プロ顔負けの職人も結構いた。まあ当時はMIDI（のWRD）なんかも職人は多かったけど。

734 ：ナイコンさん：2022/10/16(日) 13:49:35.60 .net

勝ち負け言い出したらX68kが勝てるのは同世代の低価格ゲーム機ぐらいだぞ

735 ：ナイコンさん：[ここ壊れてます] .net

98ユーザーはDOSの時お家でどう使ってたの？

736 ：ナイコンさん：[ここ壊れてます] .net

>>735
エロゲーやってるだけ
プログラムの一つも書けない奴が殆どだった

737 ：ナイコンさん：[ここ壊れてます] .net

>>733
すげえ上手えなぁって人がいたけどMacで描いたのを16色に減色してMAGファイルにしてるだけだったｗ

738 ：ナイコンさん：[ここ壊れてます] .net

16色絵描き職人はMSX2の方が上手かったなぁ

739 ：ナイコンさん：[ここ壊れてます] .net

マウスで絵が描ける人は尊敬する
何事も修練だとは思うが
自分には無理でした

740 ：ナイコンさん：[ここ壊れてます] .net

ツール次第だよ
Z'sstuffとその延長のpaintgraphicシリーズは普通にマウスで書ける
と言うか古いソフトだからペンタブが微妙

741 ：ナイコンさん：[ここ壊れてます] .net

当時はスキャナもペンタブも高かったしな。
買えない庶民はマウスが基本だし、ゲーム開発会社でもマウスで描くのは結構あった。

742 ：ナイコンさん：[ここ壊れてます] .net

しかもマウスはコロコロマウスであったよね

743 ：ナイコンさん：[ここ壊れてます] .net

あの頃もWSのマウスは光学式だったよ
専用のマウスマットが必要な奴

744 ：ナイコンさん：2022/10/18(火) 17:46:29.76 .net

パーソナルワークスステーション

745 ：ナイコンさん：2022/10/18(火) 19:34:58.23 .net

>>744
1987年頃は、ワークステーションにまだ68000をつかっていた頃だわ
その後sparcに変わっていったな

746 ：ナイコンさん：2022/10/18(火) 21:06:39.75 .net

MIPSとかSPARCとかPA-RISCとか

747 ：ナイコンさん：2022/10/19(水) 08:39:52.45 .net

まあタブレットもスキャナーもなくたってみんなないなりにやってたよね。
紙に下絵を描いて、その上にサランラップを貼ってマジックでなぞる。それをモニターの画面に貼ってツールでなぞるとか。
あの頃はそういう不便とか足りないところを知恵と工夫で補ってたね。

748 ：ナイコンさん：2022/10/19(水) 15:59:51.80 .net

X68kのグラフィックは歪む

749 ：ナイコンさん：2022/10/19(水) 16:08:25.63 .net

87年に68000のWSって何かあったっけ？
68020の事？

750 ：ナイコンさん：2022/10/19(水) 17:27:12.38 .net

X68kはエキサイティングだったけど
インタレスティングではなかったな

751 ：ナイコンさん：2022/10/19(水) 17:40:42.70 .net

>>749
SGIのIRISってそのぐらいの時期に68000じゃなかったっけ？

752 ：ナイコンさん：2022/10/19(水) 23:43:35.21 .net

>>751
それはない

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

頻度が違いすぎる。