■ このスレッドは過去ログ倉庫に格納されています
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/
- 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
総レス数 1001
198 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200