■ このスレッドは過去ログ倉庫に格納されています
PC98とX68000ってどっちが性能上なの? part2
- 667 :ナイコンさん:2022/10/04(火) 21:25:46.86 .net
- 「畑違い」ってな、俺は当時の9801でマシン語で使い倒していたし、
当時の工学社の雑誌I/Oでも、68000は内部はほぼ32BIT的で優れている、
と何度も書かれていた。
実際にマシン語でプログラミングした実感でも、Z80は凄く使いやすかった
のに、x86の16BITモード(MS-DOS)は、非常に使い勝手が悪かった。
主な理由はセグメント。
それで、Win95以降は、セグメントを一切使わないようなFLATメモリー空間
にしてしまった。それで使い勝手が一気に良くなって、アプリが劇的に作り
安くなった。
- 668 :ナイコンさん:2022/10/04(火) 21:56:13.28 .net
- >>654
>なんならデータブロックや配列や構造体ごとにセグメントアドレス側をぱたくり切り替えて使ったって構わんのだし
ただ、64KB以外にも1MBの壁もあった。
だいぶ忘れたけど、640KBは、VRAMやらROMやらDOS領域やらで使えない領域があるから、
EMSメモリーを使わない限りは、残りの640KBしか使えなかった。
だから、仮にあなたのいうようなやり方で、構造体毎にセグメントを切り替えるようにしたとしても、
16BITモードだと、EMSメモリーというややこしいバンク切り替えみたいなものを使わない限りは、
640KBまでしかメモリが使えなかったから、結局そんなに効率良くは使えなかったんだよ。
それで、Win95は、ドライバは16BITのものが多かったが、アプリやOSは32BITモードで動いていたから
64KBの壁も、1MBの壁も取り払われて、ブルースクリーンになりさえしなければ、アプリ開発は
劇的に楽になった。ただし、出たばかりの頃はグラフィックアクセラレータやGPUが無かったから、
グラフィックはDOSよりも劇的に遅くなってしまったが。
- 669 :ナイコンさん:2022/10/04(火) 21:56:30.09 .net
- >>667
お前の無能の恥の上塗りは間に合ってるんでチラシの裏に書くか、鏡にむかって好きなだけ喚き散らしてていいよw
- 670 :ナイコンさん:2022/10/04(火) 22:11:12.13 .net
- >>669
あなたもそうかも知れないが、
「セグメントを使っても効率は悪く無い」
という主張する人みたことある。
でも、独自節だと思う。
- 671 :ナイコンさん:2022/10/04(火) 22:13:17.63 .net
- ほとんど98でプログラムしたこと無いのに98が速かった、などという人がいて、
実際に自分でやってみたら遅さに驚くだろう。
速いゲームがあるのは、超絶テクニックで作られていただけ。
当時、オールアセンブラで書かれていても、98で速いゲームを作れたのは
とても少数派だった。
- 672 :ナイコンさん:2022/10/04(火) 22:17:22.82 .net
- 「アセンブラで書き際すれば速くなる」
などと考える人が後を断たたないが、それも半分正解で半分間違い。
98の場合は、VRAMに大量のWAITが入っていたのでアセンブラで書いても
グラフィックが超絶遅かった。
しかも、横8ドット分がまとめて1バイトになってしまっていたから
それだけでも効率が劇的に落ちることが多かった。
だから、パックドピクセルのDOS/V機ではテクスチャを張ったポリゴン
のゲームが登場したが、98ではほぼ登場しなかった。
- 673 :ナイコンさん:2022/10/04(火) 23:33:33.62 .net
- 「VRAMに大量のWAIT」って言うけどどのタイミングでどれだけ入ってたんだい?
具体的な数値を全く上げずに「大量」とだけくりかえしてると「またエアプがデタラメ言ってる」にしかならんのよね
- 674 :ナイコンさん:2022/10/05(水) 00:14:57.85 .net
- スレが伸びてるから何かと思ったら、リニアに拘る無能が「俺はすごかったんだ、その俺が言うんだからセグメントは制限が強くて使いにくかったんだ」と繰り返してるだけか
- 675 :ナイコンさん:2022/10/05(水) 00:32:45.18 .net
- AOKIうぜえよ
- 676 :ナイコンさん:2022/10/05(水) 00:37:10.30 .net
- 自演ウヨ太郎「スレが伸びてると思ったら〜こういうことか!」
- 677 :ナイコンさん:2022/10/05(水) 01:22:41.85 .net
- >>672
どこぞで聞いただけの噂を信じ込んでるだけのバカだからほっとけ。
当の本人はその噂の真偽が判断できないんだから相手にしてても時間の無駄だぞ。
- 678 :ナイコンさん:2022/10/05(水) 01:37:35.30 .net
- 98でフルアセンブラで組んでたけど、セグメントも64KBの壁も別に苦じゃなかった。
グラフィックはGRCGがあったし。
64KBを超えるデータを扱う時はセグメントレジスタをインデックスとしてみて16byre単位でアクセスしてた。
プロテクトモードのセグメント切り替えは遅いけど、リアルモードのセグメント切り替えは遅くなかった。
MS-DOSのシステムコールが1MBを超える部分をサポートしてないのがキツかった覚えがある。
- 679 :ナイコンさん:2022/10/05(水) 03:01:41.50 .net
- そういう制約でこじんまりしたプログラムになるからしょぼかったんだよ
- 680 :ナイコンさん:2022/10/05(水) 08:34:34.51 .net
- X68kもフリーエリアと言うメモリ制限がきつくてこじんまりとしたしょぼい、でも見た目だけは派手にできるので誤魔化しやすいプログラムばっかり作ってました
- 681 :ナイコンさん:2022/10/05(水) 09:29:39.76 .net
- >>678
それは、あなたがやろうとしていたことと、9801のハードウェアが相性が良かっただけです。
- 682 :ナイコンさん:2022/10/05(水) 09:55:12.55 .net
- >>673
エアプではない。
実際に当時、G-VRAMにマシン語から直接描画していたときに測定した結果。
WAIT値についてははっきりはしないが、2回のG-VRAMアクセスの間に
マシン語の命令を少なくとも5個くらい書いても速度が落ちないような状態だった。
G-VRAMエリアはキャッシュが無効化されていただろうから、そもそも、
G-VRAMアクセスするとCPU命令自体もWAITが掛かっていただろうが、
それにプラスして少なくとも5命令文の時間はWAITが有ったと考えられる。
昔聞いた記憶だと、EPSON機は本家より圧倒的にG-VRAMに対する
WAITが少ないということで、実際に友達のマシンで試して見ると、
差は歴然であった。
- 683 :ナイコンさん:2022/10/05(水) 10:00:45.06 .net
- >>682
[補足]
「5命令」というのは、「少なくとも」、という意味で、もっと入れても速度が
落ちなかったかも知れない。つまり、WAITはもっと大きかったという意味。
タイミングは、説明しにくいが、VRAMアクセスが周期的に動作しているような
感じであった。
つまり、CPUが16MHzだとすると、VRAMには、1MHz(?)ごとにしか、書き込めない
ようなイメージ。
一定の決められた時間間隔があり、そのタイミングが来るまでWAITするような感じ。
だから、そのタイミングが来る直前までにVRAMアクセス以外のCPU命令を実行する
とWAITせずにCPU命令を実行できた。
だから、何かの計算をVRAMアクセスの合間合間に挟むことが可能だった。
- 684 :ナイコンさん:2022/10/05(水) 10:47:25.70 .net
- >>680
X-BASICの話でもしてるのか?
- 685 :ナイコンさん:[ここ壊れてます] .net
- まさかと思うけど、今ごろになってアスキーの青本のハードウェア編だけ読んでテキトーかましてドヤ顔したいのかな?
- 686 :ナイコンさん:[ここ壊れてます] .net
- >>683
よく知らないけど、垂直帰線中しかアクセスできなかったということ?
なんかサイクルスチールとかその手の単語が思い浮かぶが、98ってそうなの?
- 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回のアクセスで4プレーン全部が待ち状態に入るような設計でもないだろうし連続したアドレスじゃなくてアドレス下位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
- 本当に余力があるならこんなに端折った3D画面にはならないからな
- 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
- まあある意味正解w
おじさんたちが頑張ってものすごい勢いで
PCを進化させたから古いPCは軒並み性能不足になった
当時の性能のPCなんて発売してもすっぺく低すぎて使えないからねw
いまのCPUだってそうだよね5年前の・・・・いまのCPUは5年前のでもちょっと我慢すれば使えそう
進化が停滞したんだねw
若い人もっと頑張ればいいのに・・・・・
- 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
1級検定の合格ラインを余裕で越えられた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
そうだと思う
自分はゲーム機として買った
当時はx68000以外で
ゲーセンのゲームやるならゲームの基盤とコントロールボックス(まあ電源)とモニタとコントローラ揃えなきゃいけなかった
(超劣化版でいいならファミコン、劣化版でいいならPC-enjineって選択肢はあったけど)
それと比べれば値段もほぼ同じくらいになる
アフターバーナー2と源平とバブルボブルとドラスピで元とった気になってた
それとは別にZoomのゲームがすごく幸せだった、いまだにファランクス自力クリアした時のうれしさはおぼえてる
性能は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ユーザーこそエロゲーやって喜んでる猿しかいなかっただろw
- 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ファイルにしてるだけだったw
- 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は研究者向け製品としては優れてたが、工業製品としてはダメだった
一流のガンダムのような商品を作って大量生産すると言う形式が失敗した例だろう
日本人はその例を学習せずひたすら同じ間違いを続けている
インテルがやったのは、大衆向けの商品に最新の研究成果を注ぎ込み
常に最適最高のCPUを供給して最大の売り上げを得る手法だ
そのためにはちゃんと広告や企画なども計画立ててる
計画を立ててるからこそ毎年新製品を出せる
その製品は自社のCPUとMSのOSとソフトハウスのソフトウェアによって作られてる
なんとまぁ完璧な生態系だ
モトローラはそれが足りなかった
68000を搭載したCPUは手軽にビジネスのプレゼンを作れなかったので、モトローラ社内ではインテルのパソコンを使っただろう
- 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だからだろw
全ての命令を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だからなww
- 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ユーザーだったけど
正直、x68欲しくてしょうがなかったけどなぁ
当時、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も同じとこ出来るよなw
- 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
- 高速なCPUマシンって98シリーズしか無かったからなぁ
高速なCPU周り、充分なグラフィック装備!なPCがあったら買ってるがな
富士通「俺んところのPCは?」
- 885 :ナイコンさん:2022/11/13(日) 13:16:54.19 .net
- PC98って、GRAM上にあるプログラムがそのまま動いたり
要らない機能があったりしたなぁ
- 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
- タイムスリップしたような錯覚をしてしまう内容だわw
俺は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換装も可能
最高ですがな
- 896 :ナイコンさん:2022/11/13(日) 23:58:51.40 .net
- >>893
その当時ならば、「ライン描画」としては速いと感じたのかもしれないな。
しかし、3Dゲーム作ろうとすると、ワイヤーフレームならともかく、
ポリゴン描くには、水平方向に無数にラインを書く必要があるから、
VX程度のライン描画能力では不十分。秒間フレーム数を落とせば作れるだろうが。
- 897 :ナイコンさん:2022/11/14(月) 00:01:07.51 .net
- >>890
>俺は883だが当時はGRCGやEGCについて詳しく書かれている書籍が見当たらず
>NECも公式に公表してなかったと記憶してるが
ASCIIのあの有名な本に出ていたと思うけど、NECがASCIIに情報提供していた
んじゃないかと思ってた。
非公開と言っておきながら、実は教えていたんじゃないかと。
あるときから、大人の世界はそういうものだと気付いた。
- 898 :ナイコンさん:2022/11/14(月) 00:06:23.63 .net
- >>896
でもVXで動くスターウォーズって高解像度なのに68版より滑らかだよねー
- 899 :ナイコンさん:2022/11/14(月) 00:17:37.16 .net
- >>890
ムーンストーン
- 900 :ナイコンさん:2022/11/14(月) 00:21:06.63 .net
- >>888 >>889
当時の資料を見返してみたら、マスクレジスタを使わなくても、
重ね合わせが出来る様になっていたみたいだ。今まで勘違いしてた。
後、9801で弱かったところの、横方向にBIT単位にずらす仕組みがあるので、
ブロック転送も横方向にドット単位の位置に転送し易い。
その機能を使えば1ドット単位での横スクロールも出来ることは出来る。
(ただし、キャラクタが重なっている時には工夫が必要)
- 901 :ナイコンさん:2022/11/14(月) 00:29:40.22 .net
- >>900
P,S,Dの3つの入力の「積和」をROPコードで好きなように選べるようになっている。
P = パターンデータ。 (VRAMをReadしたときに4プレーン文を読み込める)
S = CPUデータ。
D = VRAM上のデータ。
R = 書き込まれるデータ
R0〜R7 : ROPレジスタのBIT
に対して、
Pと~P(Pの反転)
Sと~S(Sの反転)
Dと~D(Dの反転)
として、
R=R7・(P・S・D) + R6・(~P・S・D) + ・・・
のように、R0〜R7 で 8つのパターンを好きなように組み合わせられる。
- 902 :ナイコンさん:2022/11/14(月) 00:33:50.33 .net
- >>901
でも、実験したけど、なかなか思う様にならなかったな。
資料に書いてあることと違うような現象が起きているように思えて、混乱した。
本に書いてあることと実際が違っているのではないかと思った。
なお、本はNEC公式のものではないし、そもそも、NEC公式の資料は存在
していないと言われていた。ただ、恐らく情報をリークはしていたと思う。
結局、市販ゲームでEGCが使われたものは少なかったようだ。
- 903 :ナイコンさん:2022/11/14(月) 00:51:50.78 .net
- EGCが思ったように使いこなせなかったのが未だに心残りだな。
動作しているサンプルプログラムがあればまた違っていたかも知れないが、
持ってなかった。
- 904 :ナイコンさん:2022/11/14(月) 09:21:38.20 .net
- PC-286に実装されなかったこともあってEGCは流行らなかったな。
17インチ1024x768x256色くらいまではあげても良かったかもだけどな・・・
- 905 :ナイコンさん:2022/11/14(月) 12:08:24.26 .net
- PC9801、PC286シリーズに求められたのは、早いVMだけだから。
一太郎が動けば十分なのよ
- 906 :ナイコンさん:2022/11/14(月) 13:12:59.55 .net
- EGCの転送サンプルってあったと思うけどなぁ
まぁその辺に転がってなかったのは事実だけども
- 907 :ナイコンさん:2022/11/14(月) 14:22:45.91 .net
- 速いVMだけを求めてられてるだけでも、より高性能なハードで追従できないようにNECが出してれば良かったろうに
何故高解像度モード機のメモリマップが違うんで画面モード切り替えでは対応できないなんて変な事してたんだろ
- 908 :ナイコンさん:2022/11/14(月) 16:17:49.11 .net
- NEC「販売戦略です。全部、別々に買ってほしかったからです。」
NEC信者「販売戦略なら仕方がない。うん、買おう!」
- 909 :ナイコンさん:2022/11/14(月) 16:22:08.60 .net
- 販売戦略的にはN5200が担当するゾーンだったし、H98は謎な機械だったな。
- 910 :ナイコンさん:2022/11/14(月) 16:41:07.91 .net
- XL「俺は?」
- 911 :ナイコンさん:2022/11/14(月) 23:56:20.65 .net
- >>906
キャラクタを書くときの様に、キャラクタの外側は、元々あった背景を残して
キャラクタの部分だけを描く様にしたい場合に、ROPで出来るはずなのに、
なんか上手く行かなかったような記憶がある。
04A8H ポートのマスクレジスタ(16BIT)を使えば出来たが、それだと
マスクパターンを変えるためにI/Oポートにアクセスしないといけない
ので遅くなる。
この事とは関係無いが、EGCで横方向の1ドット単位のシフト転送は出来た。
- 912 :ナイコンさん:2022/11/15(火) 13:52:43.02 .net
- >>911
昔のツレ書いたEGCLIB.ASMなる物を見つけたので
中身見ると・・・・800行くらいある、要所を切り取ると
_block_move proc near
push bp
mov bp,sp
mov ax,[bp+4]
mov bx,[bp+8]
mov cx,[bp+12]
dec cx
mov DGROUP:_work_x1,ax
mov DGROUP:_work_x2,bx
mov DGROUP:_work_xs,cx
mov ax,[bp+6]
mov bx,[bp+10]
mov cx,[bp+14]
mov DGROUP:_work_y1,ax
mov DGROUP:_work_y2,bx
mov DGROUP:_work_ys,cx
mov ax,028f0h
mov DGROUP:_work_rop,ax
mov bx,offset DGROUP:_work_saddr
mov [bx+0],word ptr 0
mov [bx+2],word ptr 0a800h
call _block_move_main
pop bp
ret
_block_move endp
な感じだった
- 913 :ナイコンさん:2022/11/15(火) 13:59:05.17 .net
- Cのソースにはコメントが少しある
asm mov dx,04a0h
asm mov ax,0fff0h
asm out (dx),ax /* アクセスプレーン…4画面同時アクセス */
asm mov dx,04a2h
asm mov ax,000ffh
asm out (dx),ax /* 入力指定レジスタ */
asm mov dx,04a4h
asm mov ax,work_rop
asm out (dx),ax /* ROPコード */
asm mov dx,04aeh
asm mov ax,work_xs
asm out (dx),ax /* 転送長指定レジスタ */
asm mov bp,ax
- 914 :ナイコンさん:2022/11/15(火) 22:13:29.07 .net
- https://www.zuiki.co.jp/x68000z/
>もしも
>X68030の「次」があったなら…
X68060ZZを作る気らしいぞ
- 915 :ナイコンさん:2022/11/15(火) 22:47:19.61 .net
- シャープの計画にあったという次期Xの資料を公開してほしいな
UNIXマシンになる予定だったらしいけど
- 916 :ナイコンさん:2022/11/16(水) 06:15:48.43 .net
- シャープはX68を諦めてWindowsのMebiusになったからな
- 917 :ナイコンさん:2022/11/16(水) 09:31:41.59 .net
- MebiusはVaio 505対抗機種をすぐに出してたな、それがMuramasaに発展した
後にDynaBook SSが出てきてB5ノート御三家といえる時代になった
- 918 :ナイコンさん:2022/11/16(水) 21:25:11.57 .net
- 富士通はFMV-BIBLOあったけどぶ厚かった
NECはノートで存在感なかったな
- 919 :ナイコンさん:2022/11/17(木) 15:54:54.89 .net
- >>914
PowerXじゃないんだ…祝一平さんがいないから無理か
- 920 :ナイコンさん:2022/11/17(木) 16:02:27.23 .net
- >>917
MebiusはVAIO前に出してたよ。Windows95の時代に初のワイド液晶ノートにビックリした覚えが。
- 921 :ナイコンさん:2022/11/17(木) 19:02:55.45 .net
- >>920
薄型B5サイズのノートのことね、VAIO505より前はぶ厚かったでしょ
VAIO PCG-X505 97年 10月
Mebius PC-PJ1 98年 6月
DynaBook SS 3000 98年 7月
調べたら発売順はこうだった
ビジネスバッグで持ち運べるサイズが到来した
- 922 :ナイコンさん:2022/11/17(木) 22:30:25.80 .net
- >>919
俺が適当に書いただけでまだ決まっていないよ
でもエミュレータで再現するんだったら高スペックには出来ないだろな
- 923 :ナイコンさん:2023/01/24(火) 18:53:01.68 .net
- >>915
PowerPC601 66MHz
- 924 :ナイコンさん:2023/01/26(木) 23:53:11.90 .net
- RS/6000とかそんな感じだったね
パソコンオタク小僧は知らないだろうけど・・・・
- 925 :ナイコンさん:2023/02/11(土) 23:08:12.89 .net
- 時代的には603てないのか?と思ったけど初代に68010やEC020でなく68000使うぐらいだから時代遅れの601で設計進めてたんだろうな
- 926 :ナイコンさん:2023/02/20(月) 21:01:16.33 .net
- V30とどっこいどっこいの性能なのに夢を超えたとかほざいてた
- 927 :ナイコンさん:2023/02/20(月) 21:33:02.19 .net
- まぁ、どっちも>>1の粗末なイチモツよりも高性能だな
- 928 :ナイコンさん:2023/02/21(火) 11:16:50.54 .net
- 夢というか、キチガイの妄想だな
- 929 :ナイコンさん:2023/02/21(火) 12:33:54.05 .net
- >1の間抜けさは群を抜いてるがな
- 930 :ナイコンさん:2023/02/22(水) 22:12:17.36 .net
- 夢を超えてたのにあとになればなるほど現実に負けて降りてしまう悲劇のX68000というゴミカスなパソコンがあったんだよw
- 931 :ナイコンさん:2023/02/23(木) 08:42:22.92 .net
- >1の粗末なイチモツに比べたら
TK-80でさえ高性能だな
- 932 :ナイコンさん:2023/02/23(木) 09:16:31.67 .net
- >>930
最初の広告やCMはカッコよかったのに中期になると父のパソコンを超えろだの山下章が出てきてコイツならこーんなゲームも遊べちゃうんですだの如何にも大人が考えた少年目線みたいな広告やCMになってしまってダサすぎて萎えた
- 933 :ナイコンさん:2023/02/23(木) 13:21:45.99 .net
- >1のゴミカスぶりにくらべたら、どんなパソコンも上出来だけどな。
- 934 :ナイコンさん:2023/02/23(木) 13:33:30.91 .net
- 今回もPC-98の大勝利だったね!
- 935 :ナイコンさん:2023/02/23(木) 17:00:19.34 .net
- X68000がPC-98に勝てるのってなにかあるっけw
- 936 :ナイコンさん:2023/02/23(木) 17:28:17.71 .net
- まっ、>1の低性能ぶりにくらべたら、
Z80でさえ超高性能だな。
- 937 :ナイコンさん:2023/02/23(木) 18:54:38.65 .net
- X68000の惨敗、ボロ負けだな
ざまぁw
- 938 :ナイコンさん:2023/02/23(木) 19:51:10.56 .net
- ああっ?
98はスト2や餓狼ができんじゃろうが?
- 939 :ナイコンさん:2023/02/23(木) 22:08:45.35 .net
- 86年にハイエンド狙いの新機種開発でMC68000をチョイスするとかバカだよ
- 940 :ナイコンさん:2023/02/24(金) 06:41:00.13 .net
- さて、このスレも閉めますかね
>1の阿呆さ加減がわかったことだし
- 941 :ナイコンさん:2023/02/25(土) 00:24:40.85 .net
- https://dic.nicovideo.jp/t/a/x68000
X68000は、価格こそ一式約40万円と競合機種の中では高価ではあったが、アクション描画能力でMSXを上回り、処理性能でもPC-98と互角(16bitで10MHz)
らしいな
- 942 :ナイコンさん:2023/02/25(土) 09:18:29.02 .net
- まあ別に嘘は言ってないけど正確では無いよね
98vmあたりなら確かに互角なんじゃね?98って普通にPentiumまであるから全く勝負にならねぇんだけどな
- 943 :ナイコンさん:2023/02/25(土) 10:57:00.82 .net
- RAが出たのいつだっけ?
X68kの3ヶ月後ぐらいだった覚えあるけど、その時点で突き放されてるんだよね
- 944 :ナイコンさん:2023/02/25(土) 11:29:46.55 .net
- 68が1987年。メモリ1Mbyteで36万9千円
同年の98UV21がメモリ640Kで31万8千円
98RAが出てくるのは1988年で49万8千円
昔はパソコンも高かった。
- 945 :ナイコンさん:2023/02/25(土) 12:15:29.04 .net
- RAじゃなくて、そのつぎのDA/U2(3.5インチFDD)をモニタと8Mの拡張メモリとDOSまとめて40万しなかったのはそれだけ値下げしたってことか
- 946 :ナイコンさん:2023/02/25(土) 12:20:57.44 .net
- 後期型の98で勝ち誇って頭オカ
まあCPUしかとりえのないパソコンだからかね
- 947 :ナイコンさん:2023/02/25(土) 12:27:10.75 .net
- X68000は自慢のMPUも最初からケチがついてるゴミだけどね
X68000が出経ってたん時は68020がでてから何年経ってた?
- 948 :ナイコンさん:2023/02/25(土) 13:01:56.60 .net
- >>946
勝ち誇る?
事実を聞いただけで勝手に負け認めちゃってるよ
実際x68000使っておまえは何が出来たの?ゲーム遊んでばっかりのロードランナーくん?高いおもちゃだったな
- 949 :ナイコンさん:2023/02/25(土) 13:09:02.65 .net
- 98ってCPUしか交換できんのか
- 950 :ナイコンさん:2023/02/25(土) 13:10:09.07 .net
- >1のお粗末ぶりに比べたら全部すごく良くできてるな
- 951 :ナイコンさん:2023/02/25(土) 14:03:06.48 .net
- まあx6の相手は88で十分よ
- 952 :ナイコンさん:2023/02/25(土) 14:11:34.72 .net
- X68が倒せたのは88とX1だもんなぁ
誰が見てもX68000は「16ビット笑」だったよね
- 953 :ナイコンさん:2023/02/25(土) 14:31:29.58 .net
- まぁ>1の相手はi4004で十分かな
始まって三分で折れちゃう程度だし
- 954 :ナイコンさん:2023/02/25(土) 14:36:25.79 .net
- 同時期でもX68kはボロ負けの時期が長過ぎたんだよなぁ
PC-98がV30の8Mhzで互角といっても、98が286、386になれば足元にも及ばないレベルで、X68kの負けだし、V30のみの機種でも実際はV30HLだから同じ16MhzでもX68kの惨敗は変わらなかったりするんだよね
ぇ
「同時期」で比較してもこれなんだよなぁ
- 955 :ナイコンさん:2023/02/25(土) 16:28:33.47 .net
- X68000初代発売日で比較すればマウント取れるんで、それ以外での比較は遠慮してください
- 956 :ナイコンさん:2023/02/25(土) 16:53:17.26 .net
- >1の人生も砂場時代で終わったんだろうね。
- 957 :ナイコンさん:2023/02/25(土) 18:45:30.24 .net
- あいつはなぜアスキーを追い出されたのか
- 958 :ナイコンさん:2023/02/25(土) 19:47:42.52 .net
- 最終モデルの030で比べようぜw
X68kが終わった理由がよくわかる
コスパ悪すぎ
- 959 :ナイコンさん:2023/02/26(日) 11:26:45.90 .net
- 98が停滞してたとかよく書き込みあるけど、X68000は全くと言って良いほど変わらなかったもんなぁ
発売当初のままの性能と機能で名前だけ変えたモデルチェンジしてただけで
- 960 :ナイコンさん:2023/02/26(日) 14:19:07.71 .net
- PC-98はWindows世代のPCに変化していった
x68は80年代を引きずったまま
- 961 :ナイコンさん:2023/02/26(日) 14:20:07.23 .net
- つまりPC-98は往生際が悪かった
- 962 :ナイコンさん:2023/02/26(日) 14:47:23.94 .net
- X68000は時代についていくことを最初から諦めて、発売当初ですら時代遅れなMC68000採用してるからなぁ
シャープに続けていく気がなかったんだろうな
- 963 :ナイコンさん:2023/02/26(日) 16:53:19.55 .net
- X68kは80年代を引きずったというか、仮想敵が8ビット機のままだったというか、
過去だけを見てたのは事実だわなぁ
未来を見てなかったから性能向上もなにもできなかったわけだし
- 964 :ナイコンさん:2023/02/27(月) 05:48:38.88 .net
- human68kのクソさがハードのクソさをさらに強調してる
なんだよアレは
まともにOSの上で動くプログラム作ったことない素人がOS作りました、とでも言われても納得できるデキだぞ
- 965 :ナイコンさん:2023/02/27(月) 09:00:30.38 .net
- どっちも>1のお粗末なモノに比べたらずっと高性能
- 966 :ナイコンさん:2023/02/27(月) 11:21:49.10 .net
- >>964
特に凄いところはないが普通の出来だろ?
MS-DOSとほぼ同じ
- 967 :ナイコンさん:2023/02/27(月) 12:24:35.15 .net
- アレが普通のデキとか言われて同意するやつは、Human-68kでしかプログラム書いたことがないか、嘘つきのどちらかだ
- 968 :ナイコンさん:2023/02/27(月) 15:36:40.66 .net
- MS-DOSの中を見たことのない>967か。
とりあえず>1と同程度の脳みそしかないのだろうなあ。
合掌
- 969 :ナイコンさん:2023/02/27(月) 18:29:29.71 .net
- human68kとかHuman-68kみたいな書き方してるんだから
実際に使った事のないただのアンチだろ
MS-DOSを68kに移植して32bit化とファイル名21.3型式になってるのと
Ver2.0以降はバックグラウンドタスクを実行できる様になってるんだし
640KBしか使えないMS-DOSよりずっと良くできてるよ
- 970 :ナイコンさん:2023/02/27(月) 18:56:57.77 .net
- MS-DOSってCONFIG.SYSに記述するDEVICEの順番を変えただけでメモリのフリーエリアが変化して
できるだけフリーエリアを多く確保する為何度もCONFIG.SYSを書き換えてはPCを再起動を繰り返さなければならなかったのが
ほんとにクソだったな
X68では必要な物全部DEVICE登録しておくだけなので凄く楽だった
- 971 :ナイコンさん:2023/02/27(月) 19:05:07.03 .net
- 具体的にどうクソなのかを説明してない時点でお察しだよ。
以前「X68はハードの問題で入力遅延が〜」とか言ってたニワカと同じ、というか同一人物っぽいが。(後でボロクソに突っ込まれて逃亡した実績あり)
- 972 :ナイコンさん:2023/02/27(月) 20:37:33.14 .net
- そんな奴を産んでしまった母親も後悔していることだろう
- 973 :ナイコンさん:2023/02/27(月) 21:00:50.91 .net
- PC-98の勝利って事で終了だな
- 974 :ナイコンさん:2023/02/27(月) 21:09:26.92 .net
- 勝ち負けにこだわるのはゴミアンチだけ。
- 975 :ナイコンさん:2023/02/27(月) 21:22:02.47 .net
- >>970
PRO1MB~compact8MBのユーザーだったけど。
MS-DOSのメモリ設定がややこしいのは採用したCPUや過去との互換性のためだから仕方ない。
設計事務所でバイトしてた時に98VXとDAの管理を任された時、いろんなボードがささっていてconfigの管理は少し面倒だったけど、
一度決まればそんなに書き換えてばっかりって事はなかったよ。ノウハウも確立していたし。
- 976 :ナイコンさん:2023/02/28(火) 09:13:21.14 .net
- X68はどうあがいても絶望しかないけどな
マトモなOSひとつないし
マルチタスク?
タスクスイッチャーモドキの事をいってるのかな?
X68ってエアユーザだけが持ち上げるクソだよ
- 977 :ナイコンさん:2023/02/28(火) 09:36:05.63 .net
- 性能もアプリのライナップもX68の惨敗なのを認めたくない、認められない現実を見れないクズしか居ないのがX68kなんだねw
ざまぁ
- 978 :ナイコンさん:2023/02/28(火) 09:51:54.11 .net
- 「いつものアンチ」にしたいだけのいつものキチガイか
- 979 :ナイコンさん:2023/02/28(火) 10:03:34.78 .net
- pc98とは?初期型の9801?
9821シリーズまですべてを含んだ98?
- 980 :ナイコンさん:2023/02/28(火) 11:07:24.42 .net
- 性能は仕方ない
V30で互角なんだから
- 981 :ナイコンさん:2023/02/28(火) 11:30:19.40 .net
- 030も9821も全部込みで比べようぜ!
- 982 :ナイコンさん:2023/02/28(火) 13:02:12.25 .net
- 公平というなら、全部込みだろ
- 983 :ナイコンさん:2023/02/28(火) 13:27:56.18 .net
- 全部込で性能なら最後まで出た98だろうな
win95や98の時にもあったし
すべての性能が68の数百倍?
- 984 :ナイコンさん:2023/02/28(火) 14:17:27.63 .net
- MC68000が非力過ぎて全てが台無しになってるから、勝てないのは当たり前なんだ
- 985 :ナイコンさん:2023/02/28(火) 16:22:10.60 .net
- どちらも>1のオツムに比べたら遥かに高性能
これだけは間違いない
- 986 :ナイコンさん:2023/02/28(火) 18:20:41.04 .net
- X68kが負けるのは不公平なんだよ!
- 987 :ナイコンさん:2023/02/28(火) 20:30:28.83 .net
- 比べるなら同時期の機種同士でしょう。
ただ、性能云々よりもシューティングゲームやアクションゲームが作れる(作られてる)マシンが欲しかったのでX68を選んだけどね。
逆にシミュレーションゲームやビジネスが目的ならなら98を選んでたかも。
- 988 :ナイコンさん:2023/02/28(火) 20:57:51.71 .net
- X68kが勝てる時期で比べないと意味ないだろ
- 989 :ナイコンさん:2023/02/28(火) 21:09:45.44 .net
- 98はDOSで勝負しろよ
- 990 :ナイコンさん:2023/02/28(火) 21:13:50.23 .net
- シューティングゲームやアクションゲームならコンシューマでX68000の出番はないな
シミュレーションゲームやビジネスソフト使うなら98だしやっぱりX68000の出番はないな
- 991 :ナイコンさん:2023/02/28(火) 21:16:11.46 .net
- まあ、どっちも>1のお粗末なモノに比べたらよくできてる
- 992 :ナイコンさん:2023/02/28(火) 21:20:41.79 .net
- 不正コピーするというアングラなゲームならX68kだろw
- 993 :ナイコンさん:2023/02/28(火) 21:37:43.07 .net
- PC-98は正統派なゲームが多かったよ
- 994 :ナイコンさん:2023/02/28(火) 21:39:43.05 .net
- 正統派なエロゲ
- 995 :ナイコンさん:2023/03/01(水) 16:31:52.57 .net
- ファンクションコールまともに設計できない素人が作ったOSなんてゴミとしか言えんわなぁ
X68はSHARPが言うとおりに32ビットじゃなくて16ビットだね
- 996 :ナイコンさん:2023/03/01(水) 16:57:40.28 .net
- まあ、どっちも>1のお粗末なイチモツに比べたらよくできてる。
- 997 :ナイコンさん:2023/03/01(水) 20:01:24.56 .net
- 素人が片手間に作らされたし
- 998 :ナイコンさん:2023/03/02(木) 06:57:43.18 .net
- X68kはハードもOSもゴミw
X68kユーザはクズでキチガイで犯罪者w
これじゃ98に負けるのも当然だよw
- 999 :ナイコンさん:2023/03/02(木) 16:34:40.87 .net
- X68000の惨敗だった。
- 1000 :ナイコンさん:2023/03/02(木) 18:18:57.21 .net
- まぁ、>1の愚かさと間抜けさに比べたらどっちも遥かにまし
- 1001 :2ch.net投稿限界:Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1001
198 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200