アカウント名:
パスワード:
ゲームマシンとしての側面もあるが、多くのプログラマを育てた機種という側面もある。私もそのひとり。 とはいえ、今になってプログラミング環境まで忠実に再現したとて、そこに魅力を見いだせるかと言うと……。
実機は今も棚に飾ってある。人生の一部というほど思い入れのあるマシンだけど、自分にはそれだけでいいかなぁ。
スペック的にはUNIX動いてX-Window動いたんだろうけど そういう使い方している話はあまり聞こえてこなくて どこまでも高性能な「マニアックなホビーパソコン」でしたねぇ まあスプライトなんてゲーム以外に使わないでしょうから
68000にはMMUがないですし、X68030もMMUなしの68EC030を載せてるのでUNIXは無理ですよ。X68kで X Window System が動くOSとしてはMINIXとかNetBSD/x68kがありましたが、MMU有りのCPUへのCPU交換が必須でした。(MINIXは元が16bitのIBM PC用なので、移植版は素のX68000でも動きましたが、Xまでは動かせられなかった。)
他にはOS/9もありましたが、X68000用のOSとしては「MS-DOSをそのまんま68000に移植した」ような仕様の Human68k を使うのが基本ですね。「MS-DOSの感覚で12MBのメモリをリニアに使えるプラットフォーム」ってのは、プログラマにとっては手軽で良かったです。16bitでMS-DOSだと、64kB超のメモリが必要になると、セグメントの壁のせいで面倒が多い…
正 OS-9誤 OS/9
X68000はご指摘の通りMemory Management Unit(MMU)がなかったので、OS-9 for X68000はLEVELⅠで、仮想記憶は使えませんでした。
MC68000のニモニックはC言語との親和性も高くて覚えやすかったし、メモリ空間の壁もなくて楽でしたねえ。
#奇数アドレスの壁から目をそらしながら
当時としてはレジスタが潤沢に使えるのが楽だった。データレジスタだけでも8本あったし、最上位bitの扱いが違うだけのアドレスレジスタも8本。
アセンブリ言語を学習するにはとてもいい環境だったと思う。バイトオーダーで発狂しなくて済むし。
同じころ学校ではZ80のマイコンボードでの実習があったけど、レジスタ少なくて面倒くさかった。
68000のアセンブラを知るまでは、C言語ってなんかすごい変換をするコンパイラって印象でしたが、
68000のアセンブラを知ると、「C言語は高級アセンブラ」という言葉を体感できましたね。特に、X68000のCコンパイラVer1は、良くも悪くも教科書通りの実装って感じで、最適化も弱くて、C言語で書いたコードとアセンブリ出力がほぼ一対一対応したりするし。あれでC言語への理解が深まりました。
68000のポストインクリメント/プリデクリメント命令が上手く使われるように「*++p」と「*--p」を良く使ったりとか。gccは最適化がすごく強力だったけど、それでも、ループにDBRA (1引いて-1じゃなかったらジャンプする、という減算と条件ジャンプを同時に行う高速な命令)を使うために、「do {…} while (--i != -1);」とするってのもあった。DBRAの意味そのままのC言語コードなら、DBRAにしてくれる。
68000が良かった点としてエンディアンとかの知識が無くともそのまま読めるのも良かったんですよね。後になってリトルエンディアンの存在を知って、「面倒だ」って印象しか無かった。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
ゲームマシン? (スコア:0)
ゲームマシンとしての側面もあるが、多くのプログラマを育てた機種という側面もある。私もそのひとり。
とはいえ、今になってプログラミング環境まで忠実に再現したとて、そこに魅力を見いだせるかと言うと……。
実機は今も棚に飾ってある。人生の一部というほど思い入れのあるマシンだけど、自分にはそれだけでいいかなぁ。
Re: (スコア:0)
スペック的にはUNIX動いてX-Window動いたんだろうけど
そういう使い方している話はあまり聞こえてこなくて
どこまでも高性能な「マニアックなホビーパソコン」でしたねぇ
まあスプライトなんてゲーム以外に使わないでしょうから
Re: (スコア:2)
68000にはMMUがないですし、X68030もMMUなしの68EC030を載せてるのでUNIXは無理ですよ。
X68kで X Window System が動くOSとしてはMINIXとかNetBSD/x68kがありましたが、MMU有りのCPUへのCPU交換が必須でした。
(MINIXは元が16bitのIBM PC用なので、移植版は素のX68000でも動きましたが、Xまでは動かせられなかった。)
他にはOS/9もありましたが、
X68000用のOSとしては「MS-DOSをそのまんま68000に移植した」ような仕様の Human68k を使うのが基本ですね。
「MS-DOSの感覚で12MBのメモリをリニアに使えるプラットフォーム」ってのは、プログラマにとっては手軽で良かったです。
16bitでMS-DOSだと、64kB超のメモリが必要になると、セグメントの壁のせいで面倒が多い…
Re: (スコア:0)
正 OS-9
誤 OS/9
X68000はご指摘の通りMemory Management Unit(MMU)がなかったので、
OS-9 for X68000はLEVELⅠで、仮想記憶は使えませんでした。
MC68000のニモニックはC言語との親和性も高くて覚えやすかったし、
メモリ空間の壁もなくて楽でしたねえ。
#奇数アドレスの壁から目をそらしながら
Re: ゲームマシン? (スコア:0)
当時としてはレジスタが潤沢に使えるのが楽だった。
データレジスタだけでも8本あったし、最上位bitの扱いが違うだけのアドレスレジスタも8本。
アセンブリ言語を学習するにはとてもいい環境だったと思う。
バイトオーダーで発狂しなくて済むし。
同じころ学校ではZ80のマイコンボードでの実習があったけど、レジスタ少なくて面倒くさかった。
Re: ゲームマシン? (スコア:1)
68000のアセンブラを知るまでは、C言語ってなんかすごい変換をするコンパイラって印象でしたが、
68000のアセンブラを知ると、「C言語は高級アセンブラ」という言葉を体感できましたね。
特に、X68000のCコンパイラVer1は、良くも悪くも教科書通りの実装って感じで、最適化も弱くて、
C言語で書いたコードとアセンブリ出力がほぼ一対一対応したりするし。
あれでC言語への理解が深まりました。
68000のポストインクリメント/プリデクリメント命令が上手く使われるように「*++p」と「*--p」を良く使ったりとか。
gccは最適化がすごく強力だったけど、それでも、ループにDBRA (1引いて-1じゃなかったらジャンプする、という減算と条件ジャンプを同時に行う高速な命令)を使うために、「do {…} while (--i != -1);」とするってのもあった。DBRAの意味そのままのC言語コードなら、DBRAにしてくれる。
Re: (スコア:0)
68000が良かった点としてエンディアンとかの知識が無くともそのまま読めるのも良かったんですよね。
後になってリトルエンディアンの存在を知って、「面倒だ」って印象しか無かった。