X68000に足りなかったもの part2

1 ：ナイコンさん：2022/11/04(金) 06:30:28.95 .net

ピーコ嫌いなユーザー

パターン定義用のSRAM
スプライトのサイズ
高品質なADPCM音源
ADPCMステレオ化、PCM対応、高サンプリング化

ピーコ嫌いなユーザー

X68版がオリジナルのソフト。
今でいうところのオフィススイート。
68030（ECつかない奴）搭載モデル。
DOSもどきじゃない、ちゃんとしたマルチタスクなOS。
モラルがあるユーザー。

ピーコ嫌いなユーザー
※前スレ
X68000に足りなかったもの
https://kizuna.5ch.net/test/read.cgi/i4004/1654543014/

798 ：ナイコンさん：2024/03/26(火) 10:27:08.96 .net

>>796
いやVAのスプライトは水平表示限界を超えるとVRAMを共有してるテキスト画面をも巻き込んでグチャグチャのでたらめな映像が出力されるんだよ
問題外
完全に欠陥

799 ：ナイコンさん：2024/03/26(火) 10:30:41.39 .net

>>797
ゲーム機なら当たり前の上下左右反転機能がない
スプライト座標の左上が0で、画面から少しだけ顔を出すスプライトを表示するにはプログラマがスプライトサイズを変更、パターン読み出し位置を変更しなければならない
大きなスプライト表示できても32個はいくらなんでも少なすぎ

800 ：ナイコンさん：2024/03/26(火) 12:51:19.54 .net

水平解像度が640固定じゃなかったかな
おかげで最大表示可能なピクセル面積ではX68Kを超えるのに実表示面積では超えないようなこともあったような

801 ：ナイコンさん：2024/03/26(火) 13:15:09.83 .net

>>800
そう、グラフィック解像度に関わらずスプライト画面解像度は常に横640ドット
水平表示制限が256ドットなので画面の半分も満たない量が並んだだけですぐに表示が破綻する

802 ：ナイコンさん：2024/03/26(火) 17:39:46.22 .net

256ドットまでならスプライトのドットを横2倍にして320ドット中256ドットまでにすれば良かったろうに

803 ：ナイコンさん：2024/03/26(火) 18:51:05.59 .net

自機と弾だけに限定するとか、あらかじめ配置を限定するとかまじめに配置をチェックして消すとかは出来たにしても、やらないで済むならやりたくない苦労だよね

640なのはマウスカーソルに使いたいというのもあるのだろうから残すにしても、制限超超過表示されないだけにして、320ドットモードも追加していたら使い勝手比べようもないくらい良くなったのにね

804 ：ナイコンさん：2024/03/26(火) 18:53:44.95 .net

>>803
VA版のR-TYPEは自機と自弾だけスプライトで他はグラフィックで描画という設計だった
欠陥仕様のせいでスプライトあるのにスプライトを積極的に使えないという悲しい惨状

805 ：ナイコンさん：2024/03/26(火) 19:22:42.41 .net

VAのR-TYPE、出来自体は良いけどスクロールがモッサリして遅かった記憶がある

806 ：ナイコンさん：2024/03/26(火) 19:32:44.42 .net

ま、まぁおかげでキレイに表示できてるので……
（グラフィック２面の１つを背景、１つにキャラクタ描画というのは PC-8001mkIISR や 77AVや、FM-TOWNS[ハード描画] みたいよね）

807 ：746：2024/03/26(火) 20:27:09.29 .net

>>795
横からすまん
おそらく私の書き込みから始まった一連のレスなんで・・・

808 ：ナイコンさん：2024/03/26(火) 20:50:21.17 .net

>>780
固定アドレスからディスクリプタキャッシュまで含んでロードする命令なのでデーター転送に使うのは無理だけど、どういう想定なのだろう
　＞レジスタとしてはデタラメな値を単なるデータ転送として使う

809 ：ナイコンさん：2024/03/26(火) 21:39:59.17 .net

>>808
セグメントレジスタまで書き換えるので普通のリアルモード命令では指定できないプロテクトメモリのアドレスまで指定できてしまう

810 ：ナイコンさん：2024/03/26(火) 22:19:22.55 .net

>>809
こういうことでしょ？　これは普通な使い方じゃない？　（本来想定の処理としてはデバッガ実装での使用だと思うけど）
（セグメントレジスタではなく、ディスクリプタキャッシュね）

pushf
cli
cld
pushf
pop bx
xor ax,0x80
mov es,ax
中略
mov word ptr es:[0x18],bx
mov word ptr es:[0x26],0x0000 ; si
mov word ptr es:[0x28],0x0000 ; di
mov word ptr es:[0x32],0x8000 ; cx
//848 のベースアドレスははds*16 を設定し、
// esのディスクリプタキャッシュのベースアドレスを2MBに設定
mov word ptr es:[0x36],0x0000
mov byte ptr es:[0x36],0x20
中略
loadcli
rep movsw ds:0 から 0x300000:0 へ64K転送
popf


>>780 で、「メモリ上に一気に設定する」というのは「メモリ上【から】一気に設定する」の書き間違いとして「レジスタとしてはデタラメな値」はグラフィックやテキストなどのユーザーデーターを示していると思われるので、LOADALL命令のメモリロード処理を用いてメモリ間データー転送をするという話なのだろうけど普通に考えると不可能なので、どういう想定なのかと……

って、あれ？　もしかして、書き間違えではなくて本当にLOADALLがメモリに値を書き込み処理と勘違いしていたのかしら？？
（それでも対象メモリが固定領域なのでメモリ間転送には使えないのでやっぱり不思議）

♯ スレチごめんなさい

811 ：ナイコンさん：2024/03/27(水) 04:14:42.42 .net

>データレジスタとアドレスレジスタの区分は要らなかった

68000MPUのことはよく知らんけどレジスタ指定ビットが増えたりせんの？
レジスタが分かれてればそもそも別命令ってことでレジスタ分3ビットだけど
すべて汎用だとすると4ビット必要

たかが1ビットじゃんといわれりゃそれまでだけどな

812 ：ナイコンさん：2024/03/27(水) 10:05:52.89 .net

コード空間とデータ空間が明確に分かれてたら意味あったけど
68kは曖昧だったからね
モード別に空間分かれてたから、モード別にレジスタセット用意するほうが意味あったかも

813 ：ナイコンさん：2024/03/27(水) 13:52:15.95 .net

>>806
VA版はグラフィック32色モードだからそこまで綺麗じゃないけどね

814 ：ナイコンさん：2024/03/27(水) 16:56:27.07 .net

68kはハーバードアーキテクチャ風にシステム(ROM)空間とデータ(RAM)空間で16MB別々にも持てた
実際にそういう実装をした汎用PCにはお目にかかったことないが

815 ：ナイコンさん：2024/03/27(水) 17:21:46.37 .net

68000のアドレッシングモードも削れたと思う・・・
インデックスレジスタ間接とかディスプレースメント付きアドレスレジスタ間接とか

816 ：ナイコンさん：2024/03/28(木) 04:36:08.66 .net

とにかくなんでもアセンブラで書くのがあたりまえの時代だったから、速度を削ってもアセンブラで作りやすくするべきという思想
コンパイラの最適化もあてにならなかったし。

817 ：ナイコンさん：2024/03/29(金) 20:33:08.92 .net

アセンブラなんて時代遅れ、これからはコンパイラだぜ！ということでもてはやされたのがRISC
1982年にRISC-I、命令数は32個
1983年にRISC-II、命令数は39個

同時期のCISCというと80x86系だと82年に80186、83年にとMC68000
命令数は数えたくないっすね

性能はというと、RISC-I VS 186、RISC-II VS MC68000どちらもRISCが勝ってる
そう、性能「は」ね・・・

818 ：ナイコンさん：2024/03/30(土) 00:23:19.75 .net

当時どこの馬の骨ともわかんないなんの互換性もないRISCを選ぶのは厳しいよ
・・と無理やりX68に話を戻してみる。

べらぼうにお高いUNIXコンピュータ用で私ら一般とは無縁だった。
雑誌の海外の話題コーナーにあった程度と思う

819 ：ナイコンさん：2024/03/30(土) 02:48:28.59 .net

大学の電算室でSPARCいじってた記憶、結構面白いアーキテクチャだった

820 ：ナイコンさん：2024/03/30(土) 05:28:05.06 .net

性能なら80286が良かったになってしまうのでは

821 ：ナイコンさん：2024/03/31(日) 11:33:42.34 .net

32bitフラットな680x0ってのは憧れだった。
「20bitの壁」や「16bitの壁」の時代なんで

822 ：ナイコンさん：2024/03/31(日) 16:26:08.97 .net

20bitの壁ってなに？

823 ：ナイコンさん：2024/03/31(日) 16:29:01.61 .net

8086の限界１MBの事だろう

824 ：ナイコンさん：2024/03/31(日) 18:08:50.45 .net

24bitのリニアなメモリ空間を誇っても
実メモリなんか1MBしか無くて、そこにドライバのみならずフォントやIOCSのパッチ等まで読み込まれ
実際に利用可能なユーザー空間は640KBを笑えなかった、という不都合な真実は語られないよねえ

X68kなんかそれでもまだ初代から1MBの大容量RAMｶｯｺﾜﾗｲ だったが
AMIGAでさえ商業ソフトは512KB基準、初代Macintoshなんてたったの128KBだもんなあ

…あれあれ？24bitの広大なメモリ空間が売りじゃなかったっけ？

825 ：ナイコンさん：2024/03/31(日) 18:15:25.11 .net

エミュ環境で何の疑問もなく12MBフル実装の環境で遊んでみても、特に使い道もないし、感慨も無いよなあ…
なんなら8MBくらいRAMディスク+ディスクキャッシュにでも充てた方が快適まである
24bitの広大なリニア空間を、ただのディスクキャッシュにする贅沢ｶｯｺﾜﾗｲ

EMSでおつりが来る罠

826 ：ナイコンさん：2024/03/31(日) 18:15:31.05 .net

アミガやマッキントッシュは存じませんが、きちんと増設できたでしょ？
98だってVMは384KBで増設しないとアドレス空間に空きがあったのは同じことですよね、何が違うというのでしょう？

827 ：ナイコンさん：2024/03/31(日) 18:16:39.33 .net

さあてそこでダイナマックだ

828 ：ナイコンさん：2024/03/31(日) 18:53:32.08 .net

1MBの場合は実際に使えたメモリはどれくらいなの？

829 ：ナイコンさん：2024/03/31(日) 19:24:59.64 .net

24ビットアドレスの最大の恩恵はアドレスレジスタひとつの値変えるだけでVRAM全てが触れたことだな
MS-DOS前提のパソコンじゃそんなのムリだろ

メインメモリの空きはおま環だから600k台空けられる人も居ただろうし500k切ってた人も居ただろう
俺はメモリ2M載せてたんで空きメモリで苦労した憶えはない

830 ：ナイコンさん：2024/03/31(日) 20:05:19.73 .net

SMDOS(笑)環境は最大でもプレーン単位でアクセスできれば良いので一プレーン32KB
VGAのマジック解像度だった320x200x8bppパックドピクセルも、64KBセグメントに納まる（が故のマジック解像度だった）

実際にアクセスするのはパターン書き換え領域などのもっと小さな面積/データ量だったので
全域リニアにアクセスできるからってポインタが常にGVRAMの先頭からでないと発狂するようなアレな子以外は、何も困ることがない

831 ：ナイコンさん：2024/03/31(日) 20:08:30.67 .net

ディスクI/Oも、実際にI/O1回ごとに転送するのはレコード単位だと数KB～せいぜい数十KBなので
64KBセグメントﾃﾞﾊ~ 16MBのリニアアドレッシングﾃﾞﾅｹﾚﾊﾞｰ …みたいな事は、全くない。
DOS環境ですら、何MB読み書きしようがsmallモデルどころかcomモデルで足りる…と言われる所以

Etherのパケットだって1パケット数KBだからな

832 ：ナイコンさん：2024/03/31(日) 21:37:35.90 .net

ディスクI/Oがレコード単位・・・？
FDがセクタ単位でR/WしてたからHDもセクタ単位じゃないかな
MOは判らん

833 ：ナイコンさん：2024/03/31(日) 22:15:45.46 .net

>>827
機種やOSバージョンによって違うがRA以降とV30HL搭載PC-9801なら704KB(うちEMSが64KB、
コンベンショナルが640KB)

834 ：ナイコンさん：2024/03/31(日) 22:49:42.55 .net

セクターはかろうじて聞きかじっているが、バッファやレコードには馴染みがないのだという。

程度が知れますなあ…ディスクI/O触ったことないか。まあそうだろうよ…

835 ：ナイコンさん：2024/03/31(日) 23:50:08.77 .net

パソコンの外部記憶装置、FATのようにフォーマットされた媒体ならセクタ、トラック、シリンダを使う
レコードは使わない

836 ：ナイコンさん：2024/04/01(月) 17:55:56.78 .net

BIOS任せ、OS任せにすりゃそうなるわな
でもそれが普通なのよ
ディスクI/O直叩きできるから偉いってもんでもないんよね

837 ：ナイコンさん：2024/04/02(火) 19:36:23.33 .net

むしろ足りてたものってなんだ？

時代遅れの性能でも名前がパーソナルワークステーションだからマイコンよりすごいスーパーマシンだ！って言ってた信者？
（でもソフトはコピーで済ませる）

838 ：ナイコンさん：2024/04/04(木) 13:10:58.87 .net

「セクタ単位でしかアクセスしない、でもそれが普通なのよ」ならなおさら、1セクタ何バイトだよ言ってみろｶｯｺﾜﾗｲ

さて、数（十）セクタまとめてバッファやレコード単位で読み書き、そのバッファサイズさえ数（十）キロバイトだった…という話を続けよう。
で？16MBのフラットメモリ空間でないと、その数（十）バイト単位での読み書きにも不自由するんだっけ？

86系のセグメント以前に、そいつの頭が不自由すぎるだけの話じゃないのか？

839 ：ナイコンさん：2024/04/05(金) 01:04:43.19 .net

リアルモードだと256x256を超えるサイズのリアルタイム回転は大変だけど4MBをリニアにアクセスできると2048x2038の広い画面も回転できるよ

840 ：ナイコンさん：2024/04/05(金) 18:58:07.67 .net

>704KB
EMSのウィンドウをカウントするのは苦しくね？

841 ：ナイコンさん：2024/04/05(金) 19:08:32.65 .net

intが16bit
メモリモデル
高級言語の場合DOS機との違いはこのへんか

386は社会的にどうだったかは憶えていない。

842 ：ナイコンさん：2024/04/10(水) 15:41:17.06 .net

EMSのウィンドウが許されるならBIOS-ROMを殺してシャドウRAMにしたUMB領域も許されるのでは？

843 ：ナイコンさん：2024/04/10(水) 16:37:20.08 .net

話の流れ的に物理メモリ量として1MBの連続メモリを積んだ場合に実際にどれだけソフトウエアとして使えるハードかの話なだけでDOSの管理とかは無関係なのでは
1MbitDRAM×8でのメモリマップがどうかで
ノートとかでROM-DOS積んでフリーエリア広いのも有るとか言い出せてややこしいし

844 ：ナイコンさん：2024/04/10(水) 18:00:04.16 .net

DOS、Human68kはFATを採用している
これらのOSは複数セクタを1クラスタとして、クラスタ単位で管理する
１バイトの大きさのファイルでも1クラスタを占有する
これはファイルの管理をクラスタ単位＋最後のクラスタの有効バイト数の組み合わせで行っているからだ
またファイルR/Wの処理は階層化されアプリ層に近い方からバイト数、クラスタ、セクタと処理の単位が変わる
DOSはディスクのI/OをBIOSを呼び出すことで行うがその単位はセクタであり、そのサイズはハードウェアに依存するがFDで256バイトや512バイトなど小さいサイズが多く、HDDでは4096バイトや8192バイトになる場合もある

DOSやHuman68kのファイルR/Wはバイトを、ディスクI/Oはセクタ、クラスタを基本にしており「バッファ」「レコード」とは概念の切り口が違うので混同しないよう注意されたい

845 ：ナイコンさん：2024/04/11(木) 16:15:47.35 .net

config.sysでbuffers指定してるのに、関係ないんだって。


ニワカか

846 ：ナイコンさん：2024/04/11(木) 19:12:12.65 .net

その辺は8086系(386より前のメモリモデル)しばりのDOS機なわけで。
68系のX68000は関係ないということで・・・

847 ：ナイコンさん：2024/04/12(金) 07:00:34.13 .net

CONFIG.SYSのBUFFERS=で指定する領域って片方向のディスクキャッシュのサイズでファイル読込みのファンクションコールされたときに読んだデータを保持する固定サイズの領域をいくつ確保するかってだけでディスクI/Oのデータサイズを変更する機能はないぞ
ファイル書き込みの時は1クラスタまるまる書き込みするなら上書きするが、そうでなかったら1度対象のクラスタ読みだして更新する部分だけデータ上書きしてディスクに書くってやってる関係でどんなに大きなファイルを書こうと実際には細切れにして処理してるだけ
VERIFY=ONが指定されてたら書き込んだあとに読み込んで比較するまでするからクラスタ単位で区切って処理するほうが楽まである
この辺りはMSDOSでもHuman68kでも事情は同じ
しかしMSDOSだとファンクション3Fh、40hで扱えるデータはバイト数を16ビットで指定するから1度にR/Wできるのは64kまでだ

ファイルR/W関係でデータの大きさを表す単位として「バッファ」「レコード」って意味不明すぎだろ

848 ：ナイコンさん：2024/04/13(土) 06:24:00.43 .net

>>843
うんまあそうなんだけど・・・
X68000は実メモリ少ないから24bitフラットでも意味なくね？という流れがこじれてこうなったわけで

私ならバンクメモリやEMSで約1MBの空間をこねくり回すDOS機より優れていると思うんだがな。

849 ：ナイコンさん：2024/04/13(土) 06:57:27.41 .net

だれも異見のない「X68000」に足りないものは拡張スロットかな・・・
最初から横置き機ラインナップしてたらツインタワー機とどちらが売れたんだろうな

850 ：ナイコンさん：2024/04/13(土) 09:39:49.84 .net

最初からツインタワーと平置きの2ラインにするなら、最初から拡張スロットにつっこむ拡張機器もそれなりに用意してなければツインタワーしか売れないと思う

851 ：ナイコンさん：2024/04/13(土) 11:01:30.17 .net

PROユーザーだったけど、最初に買った拡張ボードは4MBのメモリーボード(確かI/Oデータ製)だったなぁ。その次にMIDIボード。

852 ：ナイコンさん：2024/04/13(土) 14:28:17.45 .net

X68kはメモリ２M以上はあってもあんまり恩恵なかったなぁ
特にゲームが

853 ：ナイコンさん：2024/04/13(土) 22:48:42.40 .net

>>851
Windows全盛期になってから丹青で中古かったわ。
業務用だったのか他社のロゴ（ただのシール）がついてた。
ソフトの入手が（主に財布の都合で）できなくて手放した　ouz...

854 ：ナイコンさん：2024/04/13(土) 22:49:11.27 .net

>>852
とりま増RAMのTownsやEMSありきの98からすると贅沢な悩みやな　ﾌﾟﾝﾌﾟﾝ!!

855 ：ナイコンさん：2024/04/13(土) 22:54:57.57 .net

本体SASI端子のせいでSCSI純正ボードを買うはめに…
そして2枚目としてMIDIボードを装着したら拡張スロットは頭打ち

856 ：ナイコンさん：2024/04/13(土) 23:00:15.99 .net

>>850
そういやX68ってあまりボードなかった印象あるな。
EMSと外付けHDD　Ｉ／Ｆ（&まれに音源）で拡張スロットふさがる98とはエライ違い

857 ：ナイコンさん：2024/04/14(日) 10:16:59.61 .net

音源とSCSIが標準装備されないのはNECの怠慢

858 ：ナイコンさん：2024/04/14(日) 13:08:50.10 .net

低コスト機種とオールインワン機種に分けたんだろ
未実装パータンだけの機種だと改造されやすいしな

859 ：ナイコンさん：2024/04/15(月) 16:12:55.32 .net

拡張スロットルを使わなくても内臓だけでフルメモリに出来る考慮が最初から欲しかった
フルが無理ならせめてXVIみたいに8MBでもいいから

860 ：ナイコンさん：2024/04/15(月) 19:49:31.35 .net

>>858
低コスト機のはずのProの方が安価だったような記憶

861 ：ナイコンさん：2024/04/16(火) 03:37:17.66 .net

あんなに高かったのにシャープのオプション商法で1MB増設ボードがスロットではなくドライバー必須ネジ12本の分解装着
最初から搭載しておけば良かったのに

862 ：ナイコンさん：2024/04/16(火) 12:59:22.07 .net

結局、X68kはメモリー2Mあればそれ以上あってもあまり意味がなかったのが哀しいところやね

863 ：ナイコンさん：2024/04/16(火) 13:42:33.35 .net

メモリが高いのもあるけど必要とするコンテンツがあまり無い
少ないメモリでオレかっこいいの時代

864 ：ナイコンさん：2024/04/16(火) 14:14:39.89 .net

>>862
それはゲームしかしない人の話では？

865 ：ナイコンさん：2024/04/16(火) 21:15:15.90 .net

>>864
じゃあお前は何に使ってたん？

866 ：ナイコンさん：2024/04/16(火) 21:50:39.30 .net

またこいつか。

情報与えん方がいいよ

867 ：ナイコンさん：2024/04/17(水) 03:26:53.76 .net

俺X68000を買ったら数少ない2スロットに軟派なMIDIとか挿さずに
大容量メモリーボードとコプロセッサボードを装着して24時間365日レイトレーシングを計算させるんだ…(ハリウッド映画的なフラグ

868 ：ナイコンさん：2024/04/17(水) 05:40:20.66 .net

マッハバンド見えまくりのCG画像がお好みか･･

869 ：ナイコンさん：2024/04/17(水) 10:33:51.21 .net

X68に大容量メモリはいらない

870 ：ナイコンさん：2024/04/17(水) 10:52:02.94 .net

>>869
DoGACGAとかやってた人はRAMフル実装が常識だった

871 ：ナイコンさん：2024/04/17(水) 11:04:14.99 .net

フル実装はともかく、でかいソースビルドするとメモリ不足になるから4Mくらいは必要。ゲームもキャシュに使われるんじゃね？コットンとか

872 ：ナイコンさん：2024/04/17(水) 13:22:55.70 .net

> メモリが高いのもあるけど必要とするコンテンツがあまり無い
結局、これが結論なんだよな
RAMが必要な用途もあれば、RAMあれば使うアプリもあるけど、それらは少数派でしかない

873 ：ナイコンさん：2024/04/17(水) 17:35:02.35 .net

移植アケゲー以外はこれといったキラーコンテンツないからね、X68kは
メモリが2Mあればお釣りがくるよ

874 ：ナイコンさん：2024/04/17(水) 18:42:59.23 .net

スパストファイ２って要４ＭＢじゃあなかったっけ？

875 ：ナイコンさん：2024/04/18(木) 16:45:08.96 .net

X68kには4M必須なアプリ（ゲーム含む）がどれぐらいあるんだろね

876 ：ナイコンさん：2024/04/18(木) 20:12:47.24 .net

皆があこがれたUNIX系とかはどうなんよ？
TownsとかはLinuxが結構活発だったんだがな・・

877 ：ナイコンさん：2024/04/18(木) 20:18:16.70 .net

X68でメモリの恩恵を受けるソフトってあるか

878 ：ナイコンさん：2024/04/18(木) 21:46:12.83 .net

>>877
65536色のグラフィックツールだと画像データがでかいのでバックバッファやアンドウが多く使えて快適に
フォトショみたいに沢山レイヤー作れるソフトがなかったのが残念だが

879 ：ナイコンさん：2024/04/18(木) 23:07:46.57 .net

そもそも後期になるとゲームとかほとんど遊んでなかった
んでパソコ通とか音楽とかその辺やりだすと俺の場合はファイラーにmint使ってたけど
zipをサブフォルダの様に扱うのにRAMDISCの設定が事実上必須だった（tempフォルダは
HDD上でも使えたけどさすがに遅い）

2MBでRAMDISC確保して、その上でパソコ通やったりﾀﾞｳｿした音楽やCG楽しむのは
さすがに苦痛。2MBじゃやっとれんわ

880 ：ナイコンさん：2024/04/19(金) 00:51:41.87 .net

ｎ>>87
彩は複数レイヤー作れたけど沢山がどのレベルなのか分からないので何とも言い難し

881 ：ナイコンさん：2024/04/19(金) 09:56:41.81 .net

大半のユーザーは2Mで十分だった

882 ：ナイコンさん：2024/04/19(金) 10:59:58.37 .net

>>880
X68000版は線画レイヤーと着色レイヤーだけじゃなかったっけ？

883 ：ナイコンさん：2024/04/19(金) 13:20:39.35 .net

Linuxがメモリ増設しただけの初代X68kでも使えれば、海外でのX68kの評価は変わってたかもな

884 ：ナイコンさん：2024/04/19(金) 14:37:52.31 .net

LinuxはMMU前提だからなー

885 ：ナイコンさん：2024/04/19(金) 19:51:32.31 .net

MINIXってのもあったな。
X68000に移植されたかどうかは知らんけど

886 ：893：2024/04/19(金) 19:52:41.77 .net

(98版買ったけど結構楽しめた)

887 ：ナイコンさん：2024/04/20(土) 00:10:57.95 .net

>>882
最初の頃はそうだったけど、後で追加された覚えが

検索したら当時の思い出描いてた人が居られますね
http://tanehp.ec-net.jp/heppoko-lab/sai/sai_his/sai_his.html

888 ：ナイコンさん：2024/04/20(土) 11:01:30.32 .net

>>877
うろ覚えだけどGNUが移植されてたと思う。
（他機ユーザだったんで違ってたらｽﾏﾝ）

蛇足：
メモリは多くて困るもんじゃないので、『メモリが多くてもメリットない』というのは
増設メモリ買わなかった層でもソフトが動くようにソフトメーカが努力した結果じゃない？

889 ：ナイコンさん：2024/04/20(土) 13:17:50.62 .net

今も昔もメモリはあればあるだけ良いのは常識レベルのことだけど
X68kのアプリはメモリがあっても使わないソフトが多かったから２M以上積んでもRAMディスクにするとかディスクキャッシュにするとかしないと
体感できるような恩恵がなかったよね

890 ：ナイコンさん：2024/04/20(土) 14:20:58.27 .net

読解力

891 ：ナイコンさん：2024/04/20(土) 17:28:12.43 .net

人や時代によって表現したい物は変わるだろうし
リソースに合わした結果だろうよ

892 ：ナイコンさん：2024/04/20(土) 20:34:05.26 .net

時代によるとは言え、x68kは変わらなすぎだったな

893 ：ナイコンさん：2024/04/20(土) 21:05:35.84 .net

商用ならユーザーの多いスペックに合わせないとアカンしなぁ
フリーソフト系なら好き勝手だろ

894 ：ナイコンさん：2024/04/21(日) 09:52:12.46 .net

スレ見て思ったけどX68kに足りなかったのはMMU？

80386(ノーウェイト 8MHz相当)のTownsと比較として。
88VA比はVA触ったことないのでわからない。

895 ：ナイコンさん：2024/04/21(日) 10:47:35.52 .net

80386(ノーウェイト 8MHz相当)？？？

896 ：ナイコンさん：2024/04/21(日) 11:25:09.56 .net

X68000にはMMUもNDPも足りなかった
順当に010や020にアップグレードしてればまだしも変化を拒んだせいで何もかも足りないポンコツのままおわってる

897 ：ナイコンさん：2024/04/21(日) 13:02:09.99 .net

X68kはメモリ増設してもバンクメモリでなかったんだから
アプリはメモリがあれば使う作りにしておくべきだったんだよ