究極の16bitゲーミングPCを妄想するスレ part 01

1 ：ナイコンさん ：2019/08/29(木) 20:16:06.43 ID:vOsPlM3s.net

究極の16bitゲーミングPCを妄想するスレ。

父のパソコンを超えたはずのアレや、東京ドームを貸し切って電脳遊園地を開催したソレでは物足りない！オレサマの叶わなかった願望を今ここで…！！ という諸兄が、嘗てのコンシューマ機もブッチ切った、ゲームのためのPCを空しく^H^H^H妄想するスレ。

究極の8bit機スレに倣い、「周辺も含め、プロセッサのレジスタ幅16bit、データバス幅16bit」をレギュレーションとさせていただく。
CPUも含め、プロセッサやデータバスの駆動クロックについては、縛りは無い。

また追加条件として、「セルフ開発環境の整備」も縛り条件として入れる。
実行専用のゲーム機ではダメ、ということ。ここは一応PC板なので。

実現時期についても明確な縛りは無いが、目安の一つとしては、リアル史上に存在したとすれば「1990年頃で製品展開は終わりだろうな」(32bitの時代に入るので)…という辺りで。

後知恵で実現可能な技術や製品を惜し気もなく投入した最高にスマートなスペックで語るか、それとも史実でアレやソレが登場する前にぼくのかんがえたさいきょうのポストペケロクを投入して市場制圧完了を妄想するかは自由。諸兄の妄想力に期待する。


究極の8ビット機を妄想するスレ Part 10
https://matsuri.5ch.net/test/read.cgi/i4004/1566789025/
>22 名前：ナイコンさん[sage] 投稿日：2019/08/27(火) 04:29:09.38
>＞究極の16bitゲーム機
>スレ立ててホイ

全ては、この一言のせい。ｵﾚｼﾞｬﾅｲ

---

VIPQ2_EXTDAT: checked:default:1000:512:: EXT was configured

597 ：ナイコンさん：2020/02/16(日) 10:32:01 ID:XUhkCQSE.net

98は漢字VRAMは分かれてて合成だったかな。
98のSLG系がVRAMに文字を直接書き込んでたか漢字VRAM使ってたか知らんけど。

598 ：ナイコンさん：2020/02/16(日) 18:46:34.27 ID:HpRDDB3L.net

>>595
あれは一枚絵の表示で結構時間掛かっていたのでゲームには向かないと思うけど

599 ：ナイコンさん：2020/02/16(日) 18:59:17.48 ID:K3WeY67d.net

>>597
X1みたいにPCGとしても使えるテキストVRAMがついてると便利だな

600 ：ナイコンさん：2020/02/17(月) 12:39:22 ID:KY4gehZZ.net

>>598
320x200での19268色モードだから64kB以内で済むし、MSXみたいにI/O経由でVDPへ転送じゃないので、速度は大丈夫だと思う
ただ、4x1ピクセルで１単位なのでリアルタイムのゲームは難しい
なのでゲームでも静止画のときや、簡易アニメーション向けになるやろうね

601 ：ナイコンさん：2020/02/17(月) 12:39:40 ID:KY4gehZZ.net

>>599
98にもユーザー定義文字があるじゃないか！　188文字分しかないけど。
アトリビュート指定で色もつけれる！　単色やけど。

602 ：ナイコンさん：2020/02/17(月) 19:27:25.28 ID:/XK5qNNB.net

バス幅16bit縛りで16bitカラーまではいけるんだから
素直に32/64k色モードつければ済む話
YPbPrだかなんだかの珍妙な画面モードなんか要らんだろ

603 ：ナイコンさん：2020/02/17(月) 19:28:45.94 ID:/XK5qNNB.net

>>594
VM2の段階で256色同時発色はつけられなかったんじゃねーかな
多色がいけるなら4096色同時発色モードだってあってよかったはずだが、現実にはついてない

604 ：ナイコンさん：2020/02/17(月) 19:48:25.68 ID:EYepe/JH.net

>>603
98の場合は単純に需要がなかったんじゃないか？
オフィス用途なら16色で困ることはあんまりないし、1ドットに8プレーン使うとなると描画の負担もでかくなる

ただ、80年代はカラーmacがものすごい値段でありながらプロのグラフィック用途を独占してたから、
当時のVRAM256KB機が価格上昇を数万円程度に抑えつつ640*400の256色表示に対応したら、相当のインパクトにはなってたと思う

605 ：ナイコンさん：2020/02/17(月) 20:31:36 ID:/XK5qNNB.net

初代の時点では正にビジネス専用だったのだろうけど
VM21が出る頃にはホビーユーザーがじわじわと増加して来ていたしなあ
つくづく、16色でいいから低解像度(320x200)モードが欲しかったよ

606 ：ナイコンさん：2020/02/17(月) 20:35:03 ID:KY4gehZZ.net

>>602
フロッピー時代やったからねぇ…
流石にフロッピーでフルカラーは無理っしょ

あるいは jpeg が80年代前半にでも登場していれば、フロッピーでも何とかなったんかもしれんので、フルカラーへの需要も生じてたかもしれん。
ただ 8086 だと jpeg 伸長は、能力的に厳しかったかもしれんが。

607 ：ナイコンさん：2020/02/17(月) 20:42:42 ID:IIloEFoo.net

88もビジネス向けのつもりだった。なのにみんなゲーム目的で買ったから追加された400ラインはほとんど使われず
640x200というゲームとしては中途半端な使い方がメインだった。名作ゲームはいっぱい生まれたけどね。

608 ：ナイコンさん：2020/02/17(月) 20:45:58 ID:V9q2AhQG.net

88の縦長フォントほんと嫌いだった

609 ：ナイコンさん：2020/02/17(月) 20:52:21 ID:KY4gehZZ.net

>>607
88の400ラインはキャラクタ単位でしか色つけられなかったから、しゃーない

610 ：ナイコンさん：2020/02/17(月) 20:57:59 ID:rSVlab5k.net

>>606
フルカラーではないが、ｘ68はフロッピー時代に16ビットハイカラーを普通に実現していたし、
16ビットPCで16ビットカラーはそんなにおかしな話ではないと思う

611 ：ナイコンさん：2020/02/17(月) 21:50:42 ID:/XK5qNNB.net

>80年代はカラーmacがものすごい値段でありながらプロのグラフィック用途を独占してた
まあたマカー史観ですよ

Photoshop3.0が出る前にデジタルペインティング環境の決定打と言えるものは存在していなかった

各環境ごとにメジャーなペインティングツールはあったものの、
そもそもデジタルCGペインティングという用途が碌になかったからね80年代。出力手段すら碌になかった
ひどい時には管面を写真撮影で済ませるとかそういう勢いで、リバーサル出力すら面倒だった
TIFFやRGBベタを食わせてCMYKに分解した白黒二値の紙焼き用にプリントアウトなんて手段すらあったのが80年代

Photoshop3は94年か5年

612 ：ナイコンさん：2020/02/17(月) 21:51:57 ID:/XK5qNNB.net

欧米だとDeluxePaintや、90年代に入ってPainterとかじゃねえのメジャーなツール
日本では16色や256色に特化したアニメ絵描き用ツールが隆盛していたけど
フルカラーまでいかなくても32kや4kのツールというものがほとんど無かった
それこそx68kがその隙間に居たくらいで

613 ：ナイコンさん：2020/02/17(月) 21:57:39 ID:KY4gehZZ.net

>>610
15/16bppはフルカラーじゃなくてハイカラーでしたね、最近使わなくなったから間違えた
ただ、640x400 でハイカラーだと無圧縮で500kBだから、そのままだと2HD（1.2MB）ですら２枚分しか入らない
何らかの圧縮をしないとやってられなくなる
自分はX68持ってなかったので、そこら辺はX68ユーザー達はどうしてたんだろ？

614 ：ナイコンさん：2020/02/17(月) 22:01:45 ID:IIloEFoo.net

jpegを最初に触ったときはV30で表示に数分ぐらいかかった気がする。
まだVRAMに比べてメインRAMが少なすぎた。

615 ：ナイコンさん：2020/02/17(月) 22:07:14 ID:/XK5qNNB.net

98でjpegを見るのに掛かる時間の過半は減色関連だったので
この辺を省力化できるならV30機でも1枚1分くらいで見ることはできた
turboRが処理速度の割にjpeg展開が速いのもYJK→RGB変換と減色が要らないからで、R800が凄いわけではない

616 ：ナイコンさん：2020/02/17(月) 22:07:32 ID:rSVlab5k.net

>>613
当時のCPUだとJpegはかなり重かったから、やっぱりtiffだったのかな？
可逆圧縮なので自然画にはけっこう厳しかった覚えがあるが

617 ：ナイコンさん：2020/02/17(月) 22:16:57.05 ID:QgJLkJ2a.net

日本人なんて鮪ペイントで喜んでただよ

618 ：ナイコンさん：2020/02/17(月) 23:37:56 ID:zTaflbFB.net

X68000 稲妻走る 画像圧縮pic
https://m.youtube.com/watch?v=yJVdoC3QCEw

619 ：ナイコンさん：2020/02/17(月) 23:42:33 ID:/XK5qNNB.net

PICはSusieのプラグインがあるけど
x68kで描かれた画像は正常なアスペクト比で再現できる環境が無いんだよな…

620 ：ナイコンさん：2020/02/18(火) 00:01:16.26 ID:Kt/3MDWo.net

>>616
X68000だと速いローダーがあってJPEG一枚数秒で表示できてた気がする

621 ：ナイコンさん：2020/02/18(火) 00:17:54.68 ID:KhoZlY8U.net

AT互換機のDOSゲームの動画なんだが、スプライトやBGがなくても
286でこのくらいのゲームが動くものなんだな

https://www.youtube.com/watch?v=S_ZEWvokp3o

622 ：ナイコンさん：2020/02/18(火) 14:23:48.07 ID:LaHkkdhU.net

>>620
それでも数秒…

623 ：ナイコンさん：2020/02/18(火) 14:30:33.29 ID:lmbT9G03.net

32k色出るなら1パスでマイルドな誤差拡散とか掛けてマッハバンドもそれほど露骨に出ない程度にはできるから、やりようでは24bitカラーに展開しながらで減色行程を省ける
256色や16色だと一度24bitベタで吐いてから分析してパレット選択した後に誤差拡散とかで2パス必要でつまり24bitベタを二度舐める必要があるので減色処理の方がむしろ展開そのものより重い

32k色以上の環境で486DX2以上だとそれほど苦でもなかったかな
まあDX4は欲しいねとかやはりP5だよとかP55C以前は無理とか上を見ればキリが無いが

624 ：ナイコンさん：2020/02/18(火) 14:47:45.99 ID:LdSUkeqR.net

そういえばx68000用のセラムンopの動画とかあったよな50MBくらいの
あんなの再生できる環境なんて当時どれくらいあったんだろうな

625 ：ナイコンさん：2020/02/18(火) 14:56:38.15 ID:tSXbC7z2.net

セラムン（笑）

626 ：ナイコンさん：2020/02/18(火) 18:40:51 ID:9gHYOpzy.net

>>624
x68用と言っても80年代の話なのか90年代に入ってからなのかで大分違いそう
TOWNSや9821なら普通にムービー再生できるだろうし

627 ：ナイコンさん：2020/02/18(火) 23:22:34 ID:tGOh7z9h.net

286は当時の事情的にセグメントを採用したのは理解できるんだけど、
セグメントのない24bit空間をリニアに使うモード｢も｣搭載してほしかったな
ワークステーションも想定したような作りなのに、ネイティブモードでも常にセグメント付きなのが惜しい

628 ：ナイコンさん：2020/02/18(火) 23:33:51 ID:yU339NA8.net

>>627
MZ-2861に65536色モードがあるけどどんなVRAM構造になってるんだろう

629 ：ナイコンさん：2020/02/19(水) 00:42:18 ID:3fl/N2yx.net

>>627
>セグメントのない24bit空間をリニアに使うモード
それだと386の出来損ないが出来るだけじゃないか？
286でレジスタ拡張して24bitリニアモードを追加しても、すぐに16MB上限で引っかかって
結局、386か486の時点でやっぱり32bitリニアモードも追加する事になったと思う
ただでさえカオスなのに、より一層カオスなCPUになっただろう。
まぁ（モトローラと違って）インテルだから、よりカオスっても顧客から許される（諦めてもられる）かもしれんがｗ

630 ：ナイコンさん：2020/02/19(水) 00:45:04 ID:3fl/N2yx.net

（諦めてもられる）→（諦めてもらえる）

631 ：ナイコンさん：2020/02/19(水) 01:42:40.77 ID:hU4RH3YH.net

286はリアルモードでもセグメント方式で16MBアクセスできる裏モードつけて欲しかったま

632 ：ナイコンさん：2020/02/19(水) 01:43:08.28 ID:hU4RH3YH.net

286はリアルモードでセグメント方式で16MBアクセスできる裏モードつけて欲しかったな

633 ：ナイコンさん：2020/02/19(水) 07:44:13.40 ID:ltJOA8v/.net

>>628
FM-77系みたいにビットプレーンを多数重ねる形式ではないか？

634 ：ナイコンさん：2020/02/19(水) 12:42:39.14 ID:3fl/N2yx.net

>>632
あるよ
隠し命令の LOADALL 命令ってヤツ。
ただし使い勝手はすこぶる悪い。

635 ：ナイコンさん：2020/02/19(水) 13:02:22.97 ID:3fl/N2yx.net

LOADALL 命令を使うぐらいなら、前倒しで 286 に FS/GS セグメントレジスタを追加して
この２つだけ 8bit 左シフトする事で 16MBアクセスできる様にして欲しかった

　CS/DS/ES/SS : 4bit 左シフト ＝ 1MB まで
　FS/GS : 8bit 左シフト ＝ 16MB まで

コード(CS)やスタック(SS)は従来通りの 1MB までなので制約はそのままだが
データ(FS/GS) は 16MB まで使えるようになるので、これだけでも大分改善されてたはずだ

636 ：ナイコンさん：2020/02/19(水) 17:53:32.50 ID:XHaQ9Jon.net

このスレのように16bitレジスタ/バス縛りなら必死で286の拡張を指向するのもわからなくもないが
現実は386でいいだろで終わりだからな。正に不毛。

637 ：ナイコンさん：2020/02/19(水) 18:03:24.29 ID:rIEDqlr5.net

というかなんでゲームのプログラムでそんなにリニアにメモリアクセスする必要性があるんだ？
バンク切り替え、レジスタで十分じゃん。

638 ：ナイコンさん：2020/02/19(水) 18:06:16.16 ID:XHaQ9Jon.net

変造286で86や386とのバイナリ互換なくすのは、頭どうかしてるんじゃねレベルの悪手にしか見えんしな
AT互換や98の変造でいいだろってご意見と同じ、スレを浪費して潰すために続けているようにしか見えん

639 ：ナイコンさん：2020/02/19(水) 19:11:22 ID:qKZqB5iV.net

68000って、なんだかんだで70年代の設計としては相当優れてたんだな

640 ：ナイコンさん：2020/02/19(水) 19:23:14 ID:rIEDqlr5.net

それはみんな知ってる。というか8086のセグメント機構がが過小評価されてることが問題。

641 ：ナイコンさん：2020/02/19(水) 20:59:04.45 ID:XHaQ9Jon.net

まだメモリが高価で大容量なんか活かしようの無かった頃に無理やり32bitレジスタ導入した時代が読めてないCPUって見方もできるので
ようやくメモリが安くなってくる頃には、ワークステーションや組み込みはどんどんRISC化して行ったし
それも32bitはx86が平らげてしまった

642 ：ナイコンさん：2020/02/19(水) 21:59:31 ID:qKZqB5iV.net

そしてメモリマップの関係で、大容量メモリが安くなっても搭載に難があったx68が不憫すぎる
x68の開発時点で68020が存在してたんだから、将来の32bit化を視野に置いてメインメモリを後ろに配置していればよかったんだが……

643 ：ナイコンさん：2020/02/19(水) 23:46:57 ID:3fl/N2yx.net

>>638
>変造286で86や386とのバイナリ互換なくすのは、頭どうかしてるんじゃねレベルの悪手にしか見えんしな
286はこうだったらよかった、すら議論しちゃダメなのかね？
その場合、次に出てくる386のリアルモードでも FS/GS は16MBアクセスが維持されるから、その意味ではバイナリ互換は継承される事になる

もちろん、史実の286にはFS/GSは無かったし、史実の386のリアルモードの FS/GS は1MBアクセスだった事は百も承知している

644 ：ナイコンさん：2020/02/19(水) 23:49:48 ID:XHaQ9Jon.net

>286はこうだったらよかった、すら議論しちゃダメなのかね？
このスレでする話ではない
文句あるなら他所へ行くなり、自分でスレ立ててそこでしろ
この注意ももう何度目だ？

645 ：ナイコンさん：2020/02/20(木) 00:41:26.98 ID:tfk+tjSp.net

>>644
おめーの指示は受けねーよ

646 ：ナイコンさん：2020/02/20(木) 00:43:09.12 ID:td0PI8q0.net

なら出て行けキチガイ

647 ：ナイコンさん：2020/02/20(木) 05:50:45.62 ID:uZEdvVe8.net

65816のwikiに
＞プログラムのセグメンテーションまたは16MBの完全にリニアなアドレッシングを可能にするプログラムとデータバンクレジスタの分離。
と書いてあるけど、65816はセグメントによる64KBの壁なしで使うことも出来たのか。
ならこれが究極の16bitゲーミングPC用のCPUか？

648 ：ナイコンさん：2020/02/20(木) 06:32:49.67 ID:oDj3JXfc.net

レジスタで直接扱えるデータは16bitまでで、
プログラムカウンタ用のセグメントレジスタとデータレジスタ用のセグメントレジスタの2本のセグメントレジスタが有るので2箇所の64KBの計128KBがレジスタで使えるだけだが、
命令セットのオペランドとして24bitアドレス指定かできる
だからロングジャンプとして16MB何処にでも直接飛べるし、
ロングアドレッシングとして定数24bit＋16bitXレジスタの16MB何処でもアクセスできる

まあ元々の6502で2進数演算モードと2進化10進数モードとの切り替えだった延長として、
8bitデータ演算モードと16bitデータ演算モードとを切り替える手法を取ったんだから、
24bitデータ演算モードを付けて切り替えられるようにすれば良かったんだろうけど
攻め方が足りなかったな

649 ：ナイコンさん：2020/02/20(木) 06:45:44.12 ID:qggWqiM5.net

このセグメントフォビア君は、たぶんずっと同じ一人が書き続けているのだと思うのだが、
その根拠に彼は、セグメント参照は常に固定だと思い込んでいる節がある。
つまり彼は、セグメントレジスタの数×セグメント空間のメモリしか扱えない、と強固に思い込んでいるのだ…。

650 ：ナイコンさん：2020/02/20(Thu) 07:18:34 ID:4oivhQcn.net

>>609
ん？
400ラインで色つけられたの？

651 ：ナイコンさん：2020/02/20(Thu) 12:29:04 ID:tfk+tjSp.net

>>650
付けれたで
テキストのアトリビュート設定がグラフィックスにも適用された

652 ：ナイコンさん：2020/02/20(Thu) 13:00:59 ID:tfk+tjSp.net

>>647
65816は本読んだだけの知識のみで、実機さわった事ないけど
データバンクレジスタは１個だけしかないので、その点は不便そうに思えた
ブロック転送はバンク値を２つ指定できるので16MB間での転送は出来るけど、
バンク値は固定値指定のみだから柔軟性には欠ける

653 ：ナイコンさん：2020/02/20(Thu) 13:21:55 ID:BXVZjV5S.net

セグメントの64KBの壁つっても128KBをループで参照するのも大した手間もなくできるのに
なんでそんなに完全なリニアにこだわってんるんだ？

654 ：ナイコンさん：2020/02/20(Thu) 13:29:03 ID:qggWqiM5.net

セグメントサイズを超えたデータブロックを参照したりコピーする時でも
そもそもリニアアドレス空間なシステムでもHDDとのデータ転送だって一発で終わらず
クラスタサイズやバッファサイズで何度もぱたくり切り替えて転送してるのに
どうしてここまでセグメントアーキテクチャを憎悪できるのか
当時の(現在もだが)扱われるデータのサイズやスケール感すら実感が無いのでは

655 ：ナイコンさん：2020/02/20(木) 13:46:18.02 ID:bWhkqAtw.net

>>639
それが1990年前後まで使われてたから速度不足で悩まされた
本来なら68020、68030辺りが低価格化して普及すべきだったんだが

656 ：ナイコンさん：2020/02/20(木) 13:47:10.42 ID:bWhkqAtw.net

>>642
あとDMACも32ビットアドレスに対応したものに変更しないと駄目だね

657 ：ナイコンさん：2020/02/20(木) 15:11:33.80 ID:UXNOxPHl.net

>>639
ミニコンより低価格のエンジニアリングワークステーションなんて分野を生み出したからな

業界に痕跡を残して消えたメーカー　優秀なマシンを輩出するも業績に悩まされたApollo Computer
https://ascii.jp/elem/000/001/550/1550550/

658 ：ナイコンさん：2020/02/20(木) 15:23:17.34 ID:UXNOxPHl.net

apolloとSunが初期のエンジニアリングワークステーションの2大メーカーだった
勝者がSunで敗者がapollo Computer

業界に痕跡を残して消えたメーカー　UNIXの覇者Sun Microsystems
https://ascii.jp/elem/000/001/550/1550550/

659 ：ナイコンさん：2020/02/20(木) 15:27:01.34 ID:UXNOxPHl.net

68000が優れてたのはDECのミニコンの設計を参考にしたからとも言われてる

業界に痕跡を残して消えたメーカー　CPU設計に大きな影響を与えたDEC
https://ascii.jp/elem/000/001/199/1199091/

660 ：ナイコンさん：2020/02/20(木) 15:45:46.46 ID:hB0SXRhi.net

みんな知ってるし、お前より詳しいよ。

661 ：ナイコンさん：2020/02/20(Thu) 16:42:55 ID:bWhkqAtw.net

そりゃ9801みたいなショボいパソコンなら64KB以上のデータなんて滅多に扱わないから64KBのセグメントに不満ないんだろうねｗ

662 ：ナイコンさん：2020/02/20(Thu) 16:43:54 ID:covhwVgy.net

それ1982年の話っしょ

663 ：ナイコンさん：2020/02/20(木) 17:05:54.27 ID:BXVZjV5S.net

64KB以上のデータ扱うのも大した手間じゃないと言ってるのに、
なぜ扱えないみたいな話になってるのだろう。イタイお人だ。
だいたい386機登場以降も286、V30機の市場のでかさからリアルモードで書かれたゲームが大半だったろ。

664 ：ナイコンさん：2020/02/20(Thu) 23:05:34 ID:tfk+tjSp.net

64kB の壁は大したことなくて、それよりも 640kB の壁のほうが大きかった
拡張基板のBIOSアドレスを整理して、なるべく C0000H〜DFFFFH 間で 64kB以上のEMS空間を確保して
ちまちまと切り替えていた記憶が。

665 ：ナイコンさん：2020/02/21(金) 03:50:43.69 ID:N5GFzUHM.net

i686でもPSEとかPAE使えば4GB以上使うのはたいした手間ではない

666 ：ナイコンさん：2020/02/21(金) 03:52:36.23 ID:eWpvetrg.net

640KBの壁とか貶すけど
AmigaもAtariSTもスタンダードは512KBしか無く、市販ソフトもこれを動作条件に設定するしか無かったし
X68kも初代とACEは1MBで、ここにフォントやドライバを読み込めば640KBを嗤う余裕など無かった
Macintoshに至っては128KBからスタートだ

85年の段階で640x400x16色640KBのVM21仕様を最低条件とした98は、高スペックで広大なメモリ空間を誇った環境だったと言っていい

667 ：ナイコンさん：2020/02/21(金) 03:55:28.34 ID:eWpvetrg.net

PAEを使っても、プロセスはもちろんカーネル空間も32bit/2GBのままだが？
斜め読みしかできず意味を半端にしか汲み取れず、制約を理解できていないニワカ馬鹿の典型例だな

668 ：ナイコンさん：2020/02/21(金) 04:05:56.14 ID:uFE/7uCy.net

386ならリアルモードで4GBのメモリ空間を使うことが可能だったようだぞ
一度、プロテクトモードに入ってから、セグメントリミットを4GBにしてから
リアルモードに戻ってくるやつ

https://en.wikipedia.org/wiki/Unreal_mode

669 ：ナイコンさん：2020/02/21(金) 04:21:28.73 ID:xkO0LX5V.net

PAEの話じゃないし

670 ：ナイコンさん：2020/02/21(金) 04:40:42.17 ID:uFE/7uCy.net

DOSの後期のゲームだとUMB使ってコンベンショナルメモリ空けないと
起動すらできないゲームあったな
あれはもうある意味386や386SX以降専用だったよね

671 ：ナイコンさん：2020/02/21(金) 08:15:58.07 ID:Vcg2e780.net

>>667
何でそう思っちゃった？
32bit Windowsでもカーネルオプションで3GBに拡張出来るけどニワカか？

672 ：ナイコンさん：2020/02/21(金) 09:20:54.36 ID:wa7KHmcI.net

使い勝手が悪かろうとLOADALL命令でリアルモード16MB扱う前提での日本の286パソコンが有っても良さそうなもんだったが
FEPとかフォント絡みとかだけでも640MB外に逃がせれば、
日本のパソコンのメモリ環境の狭さは解消したろうに
DOS/Vが出るまで何をやってたんだろう？
286なDOS/Vでもフォントを置けてたのからすると、ゲームにも使える程度の小回りきいてたんじゃないのか？

673 ：ナイコンさん：2020/02/21(金) 12:45:18 ID:D3aL2+7K.net

>>672
KBでしょ？？
KBだよね？？

674 ：ナイコンさん：2020/02/21(金) 12:50:41 ID:wa7KHmcI.net

>>673
あ、そう
その前の16MBの学習で入力されてしまってたのを見逃した
16MB内に640MBが内包されてた事になっちまう

675 ：ナイコンさん：2020/02/21(金) 13:00:27 ID:/2ua1z3j.net

>>672
LOADALL命令では単純に解決しない問題があるからだと思う。

セグメント・ディスクリプタのベースアドレスを変更して16MB中の64kBを指定するわけだが
たとえばESのベースアドレスを0x000000から0x123400に変更している最中に割り込みがかかって、その割り込みルーチンがESを使ってしまうと
あらぬ物理アドレスをアクセスすることになる。最悪、システムが暴走する。
なので、ベースアドレスを0x000000へ戻すまで、割り込みを全面禁止するか、ESを使わないことが確実な割り込みのみを許可するしかない。
ESを使っているかどうかは、BIOS ROM中の割り込みルーチンだけでなく、全ての拡張基板上のROMの割り込みルーチンまでをも確認する必要がある。
割り込みルーチン以外にも、ただのBIOSサービスルーチンを呼ぶ時も同様（こっちは自前のルーチンを持てばいい話だが）

それと当然、長時間、割り込み禁止すると必要な割り込みまでされなくなるので、それ関係の副作用も発生しかねない。

このように LOADALL命令を呼び出すだけで気楽に16MBのメモリが使えるようになる訳ではない。

そもそも論として、86/186/286 はセグメントレジスタの本数が足らなさ過ぎるんだがね。
俺が >>635 で、286の時点でFS/GS追加してくれてたらなぁ、と書いたのは、そういう事。

676 ：ナイコンさん：2020/02/21(金) 13:09:08 ID:wa7KHmcI.net

https://en.wikipedia.org/wiki/LOADALL
RAMDRIVE.SYS (1985)
SMARTDRV.SYS (1986)
HIMEM.SYS (2.03, 1988-08-04; 2.04, 1988-08-17)
The Extender (1985)
The Connector (1985)
Lotus 1-2-3, Above Disk (1986)
OS/2 1.0 and 1.1 used the 286 LOADALL instruction

ってなのからすると、1985年からなら十分にLOADALL命令が使えてた訳でしょ
単にブロック転送としてならXMSでUMBも使ってたが、単なるDMA転送的な使い方だったし
それを矩形転送、透明色での重ね合わせレベルまで拡張してればゲームでも使えてたろうに

677 ：ナイコンさん：2020/02/21(金) 14:19:48.49 ID:s+74frYo.net

>>667
仮想メモリとかそういう知識がないみたいだね。
1プロセスにつき32bit空間だよ。複数プロセスなら個々に32bit空間だよ。
つまり32bitOSは、1プロセス1GB使うプログラムを同時に5個立ち上げることも可能。

678 ：ナイコンさん：2020/02/21(金) 14:21:17.07 ID:mL8zWgul.net

286キチガイ君は、専用スレ立ててそっちでやってくれるか。
再三注意して聞かないので、今後FGレジスタ言い出した奴は荒らしとみなす。

679 ：ナイコンさん：2020/02/21(金) 14:24:37.80 ID:mL8zWgul.net

>>677
PAEは32bitOSで最大2GBのプロセスを複数「オンメモリで」実行させるための方便。

レジストリ設定で3GBｶﾞｰとか
お前は仮想メモリを知らないに決まっているとか
馬鹿にしたくて相手を案山子扱いする荒らしは失せろ

680 ：ナイコンさん：2020/02/21(金) 14:29:04 ID:wsQ7y8jp.net

>>679
レジストリ設定？バカも休み休み言え
パソコン大先生のハック教室の話なんかしてないからｗｗ

681 ：ナイコンさん：2020/02/21(金) 14:40:29 ID:B49bD05n.net

こいつ裏レジスタ君か

682 ：ナイコンさん：2020/02/21(金) 15:14:01 ID:s+74frYo.net

>>679
MSの32bitOSにそんな機能はないし、MSが用意したAWEは
1プロセスでEMSのようにメモリを入れ替えて1プロセスで2GB以上のRAMにアクセスする機能。

でおまえは何が言いたいんだ？　壁を越えるのは制約が多くできないと言ってるのか？
多くのゲームは動作する環境を増やしたいから、システム要件下げてるという主張ではなかったのか。

683 ：ナイコンさん：2020/02/21(金) 15:38:42 ID:B49bD05n.net

PAEはWindows2000以降で有効。WidnowsがMSの32bitOSでないとは聞いたことがないが…

684 ：ナイコンさん：2020/02/21(金) 15:54:26 ID:B49bD05n.net

Windowsに限らず何らかの拡張手段を取らない32bitOSは最大4GB(2^32bytes)の物理メモリ空間を扱い
常識的な実装ではアドレス空間の最上位ビットをシステム空間とユーザー空間の判別に用いるため、
一般的な32bit環境で取り扱う事の可能な「物理メモリ容量」は2GB(2^31bytes)となる。

また、常識的な実装ではプロセス毎に割り当てられる仮想メモリ空間においても同様の措置が取られるため、
32bitOS環境で単一のプロセスが扱うことのできるメモリ空間もまた2GBが上限となる。4GBではない。
物理上限2GBのメモリ空間の中に、論理上限2GBのプロセスが複数ひしめき合う環境、それが(未拡張の)32bitOS環境である。

で、そうなると実際問題として、32bitOS上ではユーザー空間2GBをフルに確保できる環境というものは実現し得ない、ということになるのが一点。
さらに、2GBフルとは言わないまでも、数百MB以上も食う巨大なプロセスを何個も実行できない、スワップしても収められない、というのがもう一点。
そこで導入されたのがPAE、物理メモリ拡張という手段で、
プロセス空間は2GBのまま(32bitコードのままなのでそこは作り直しでもしない限り超えようがない)、OSシステム全体として管理可能な物理メモリは4GBを超えよう、という泥縄実装である。

PAE環境下では、2GB以上の物理メモリをOSが管理し、相変わらず最大2GBのプロセスを2GB超の物理メモリ上に展開することができる。
2GB(3GB)しか取れなかった物理メモリ上でOSプロセスとユーザープロセスが犇めく状態から、32bitプロセスにフルに2GB割り当てる事すら可能となる。
しかし相変わらずプロセス上限は2GBであり、これはユーザープロセスもシステムプロセスも変わらず、スワップ容量もそのままである。
…まあ、こんなならもう64bitOSにした方が良くね？ってなるわな。

AWEは、利用するには再コンパイルが必要になり、再設計レベルで構造変更ということになるので、
対応するユーザー空間プロセスなんてほとんど見たことがない。
PAE環境下のWindows環境でAWEを活用していたものなんてシステムキャッシュくらいじゃねえの

685 ：ナイコンさん：2020/02/21(金) 15:55:45 ID:B49bD05n.net

参考までに、PentiumProのMMUの持つ物理アドレス幅は36bit(64GB)。
論理上は、最大64GBの物理メモリ上に最大31bit空間の32bitプロセスを複数ロードし実行し得る。

チップセットやマザボがどれだけ対応するかはまた別の話だが。

686 ：ナイコンさん：2020/02/21(金) 16:00:07 ID:kbWW9BoG.net

ロートル裏レジ君でもわかるように例えるなら
MSDOS上でCP/M80エミュを複数実行するようなもんか
結局CP/M80は64KBを超えられない
32ビットプロセスも2GBを超えられない

687 ：ナイコンさん：2020/02/21(金) 16:01:29 ID:B49bD05n.net

>でおまえは何が言いたいんだ？　壁を越えるのは制約が多くできないと言ってるのか？
そんな話はしていない(お前しか言っていない、お前がここで言い出した)

>多くのゲームは動作する環境を増やしたいから、システム要件下げてるという主張ではなかったのか。
そんな話もしていない(お前しか言っていない、お前がここで言い出した)

688 ：ナイコンさん：2020/02/21(金) 16:02:44 ID:B49bD05n.net

>MSDOS上でCP/M80エミュを複数実行するようなもんか

それだと64bitOSで32bitプロセスを実行するのも変わらんて話になるが
言わんとしてる事はわからんでもないが馬鹿は「理解しない」だろう。
荒らしが目的で絡んでくるキチガイに例え話は悪手。

689 ：ナイコンさん：2020/02/21(金) 16:03:09 ID:s+74frYo.net

>>683
> PAEは32bitOSで最大2GBのプロセスを複数「オンメモリで」実行させる

のことだよ。どんな論理力だよ、おまえ。 というか　>>684 ←間違いだらけだし。

690 ：ナイコンさん：2020/02/21(金) 16:09:54.35 ID:s+74frYo.net

>>687
ん？　おまえに質問してないけど？

ID:eWpvetrg　= ID:B49bD05n = ID:eWpvetrg

なのか？　どんだけIDコロコロして自演してんだよwww

691 ：ナイコンさん：2020/02/21(金) 16:19:14 ID:MrVQnA+6.net

面倒くさい説明をさせる ← それは間違いだらけだｗｗ ← 具体的には何も指摘できない←ｲﾏｺﾚ

692 ：ナイコンさん：2020/02/21(金) 16:22:33 ID:s+74frYo.net

ID:eWpvetrg　= ID:mL8zWgul = ID:B49bD05n =　ID:kbWW9BoG = ID:MrVQnA+6

こんな暴れ方するのはいつものアフィカス君だね。

693 ：ナイコンさん：2020/02/21(金) 16:25:50 ID:B49bD05n.net

敵は一人に決まっていると思い込むいつもの

694 ：ナイコンさん：2020/02/21(金) 16:35:10 ID:MrVQnA+6.net

逆だろ
一人に粘着してるから間違いようが無えんだ

695 ：ナイコンさん：2020/02/21(金) 16:43:45 ID:B49bD05n.net

いちいち読んでないけど
>ID:mL8zWgul = ID:B49bD05n
合ってるのはここだけだな

IDが変わるのはこちらでは制御のしようがない。任意に変更もできないし、維持もできないからな
まあ全てを敵だと思い込んで勝手に消耗してくれるなら、それはそれで手間が省けるというもの

696 ：ナイコンさん：2020/02/21(金) 18:24:48 ID:/2ua1z3j.net

>>695
32bitの話は、専用スレ立ててそっちでやってくれるか。ここは16bitだ。
今後 PAE 言い出した奴は荒らしとみなす。

697 ：ナイコンさん：2020/02/21(金) 18:27:58 ID:B49bD05n.net

>>696
俺ではなく、言い出した奴に言ってくれ
あと勝手に仕切るなキチガイ