■ このスレッドは過去ログ倉庫に格納されています
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/
- 797 :ナイコンさん:2024/03/26(火) 05:47:01.62 .net
- 可変スプライト→可変サイズスプライト
当時のゲーム基板は大体乗ってたから、デカキャラでもスプライトが1枚で済んだ
- 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
- ま、まぁおかげでキレイに表示できてるので……
(グラフィック2面の1つを背景、1つにキャラクタ描画というのは 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の限界1MBの事だろう
- 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バイトの大きさのファイルでも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はメモリ2M以上はあってもあんまり恩恵なかったなぁ
特にゲームが
- 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 I/F(&まれに音源)で拡張スロットふさがる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
- スパストファイ2って要4MBじゃあなかったっけ?
- 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
- n>>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のアプリはメモリがあっても使わないソフトが多かったから2M以上積んでも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にアップグレードしてればまだしも変化を拒んだせいで何もかも足りないポンコツのままおわってる
総レス数 1003
226 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200