09/09/25 21:18:06 .net
>>146 は低レベル
151:ナイコンさん
10/01/28 07:08:07 .net
保守
152:ナイコンさん
10/05/31 21:47:39 .net
保守って何だよ。
せめて上げだろ。
153:ナイコンさん
10/09/08 23:09:16 .net
じゃあ上げ
154:ナイコンさん
10/09/09 10:18:18 .net
はげ
155:ナイコンさん
10/10/09 15:06:10 .net
懐かしいな。うろ覚えだけど…
OS-9/Level2が動く環境は憧れだった。
ニフで63C09版は68K販よりも早いとか聞いて、すげ～と思ったっけ。
作った代表格な人は「ひかる」さんの旦那さん。
ハンドル、なんだったっけ?
>>109
>今ならエミュもあるので皆に触ってもらいたいと思う
エミュが手に入っても、OS-9が手に入らないｗ
156:ナイコンさん
10/10/09 15:43:33 .net
URLﾘﾝｸ(nanno.dip.jp)
157:ナイコンさん
10/10/09 22:21:30 .net
>>155
GIGO氏だろ
158:ナイコンさん
10/10/10 05:15:46 .net
OS-9互換のフリーOSって作れないのかな？
っていうかオープンソース化とかいう話はないものかな？
159:ナイコンさん
10/10/10 09:14:24 .net
悲しいかなもはや需要はないだろう
160:ナイコンさん
10/10/10 09:34:33 .net
一体どこで道を誤ったんだろう？
確かWin95が出てくるまでは一番期待されていたOSではなかっただろうか？
MACがOS9とか言ってきた辺りでなんか勝負できなかったものかな？
161:ナイコンさん
10/10/10 10:46:37 .net
courant
162:ナイコンさん
10/10/10 16:36:21 .net
UNIXライクじゃないUNIX認定の正規OSが普通に使えるのに、今さらOS-9は
ないだろう。組み込み用も使命を終えた感じ。
163:ナイコンさん
10/10/10 19:37:23 .net
モジュラーOSなんてあるか？
164:ナイコンさん
10/10/10 19:51:23 .net
UNIXなんて古臭いOSがしぶとく生き残っているのにOS-9が消える理由が無かったと思うんだけどなあ。
黒船マシンに対応した版を安く出せば支持されたんじゃないの？
165:ナイコンさん
10/10/10 22:21:33 .net
OS-9000高かったもんなあ
166:ナイコンさん
10/10/10 22:31:06 .net
>>164
IBM-PC/8088用に機械語で移植して、
1万円以下でそしてワープロと表計算を付けるくらいでないとインパクトが無いだろ
制限無しで移植するには386まで待たなければならなかったが、それでは遅すぎだよね
167:ナイコンさん
10/10/10 22:32:00 .net
基本部分をタダでもいいから配って、モジュールサポートで金を取る商売とかできなかったものかな？
168:ナイコンさん
10/10/10 22:34:34 .net
>>166
そういえばlevel2をセグメントモデルに移植するとどんな感じになったんだろうか？
169:ナイコンさん
10/10/10 22:35:21 .net
今ならソースコードも落ちてるし、情報も多いから真似て作ればいいんじゃね
170:ナイコンさん
10/10/10 22:37:08 .net
09しかわからんので㍉
171:ナイコンさん
10/10/10 22:40:21 .net
>>168
L2は無理、Levle1でかつ 機能制限して作るのかな。セグメントコントローラを作るかも
OS-9はメモリ効率が良いから、256Kbyteもあれば実用的に使えたんじゃなかろうか
172:ナイコンさん
10/10/10 22:40:39 .net
>>158
>OS-9互換のフリーOSって作れないのかな？
NitrOS-9 てのがある。
残念ながらFMシリーズ用ではないが。
移植は可能だと思うよ。
173:ナイコンさん
10/10/10 22:43:40 .net
>>164
>UNIXなんて古臭いOSがしぶとく生き残っているのにOS-9が消える理由が無かったと思うんだけどなあ。
消えてないってば。
元々組み込み用のOSなんだから、そっちでちゃんと生きてる。
パソコン用のOSとしては、アプリが揃わないので駄目だったのだろ。
OSだけでは何もできんから。
174:ナイコンさん
10/10/10 22:46:10 .net
>>171
単純なMMRにできてセグメントで出来ないのってどの辺なんだろうか？
175:ナイコンさん
10/10/10 22:46:27 .net
>>173 事実上会社も無くなったし、保守の為に人員が残ってるくらで 新規採用は無いでしょ
176:ナイコンさん
10/10/10 22:53:12 .net
>>174
セグメントはシングルタスクの考え方で、64K単位になる。
6809で再配置可能にすればMMRで4K単位で自由配置でき、しかもマルチタスクの保護付き。
8088で働かすには重要なものをどれか切り捨てるしかないだろう
177:ナイコンさん
10/10/10 23:12:11 .net
>>176
あれ？ページじゃなくてバンク単位だったっけ？
だったらオブジェクトコードの方を工夫すればなんとかならないかと思っていたんだけど。
178:ナイコンさん
10/10/10 23:25:47 .net
>>177
例えばシングルユーザーとしてクライアント側ならば出来るとおもう。
MS-DOSでも同じ様にマルチな事ができる、
しかし、8088でそれまでしたいと思った技術者がいなかったって事だと思う。
179:ナイコンさん
10/10/10 23:54:16 .net
>>175
URLﾘﾝｸ(www.radisys.com)
見たら、2008年2月で開発止まってた。orz
OS-9 for 68K が 2006年で V1.3 というのが腑に落ちんが。
OS-9/68000 とは別物なのか？
X68000用でも V2.4 とか出てたと思った。
180:ナイコンさん
10/10/11 00:04:59 .net
OS-9/68000とOS-9000/68000が別にあって、
後にOS-9000をOS-9と統一した、だからOS-9/68Kが重複する。
おそらく、それはOS-9000/68000だと思われる。
181:ナイコンさん
10/10/11 00:10:41 .net
ASM版とC版かな？
182:ナイコンさん
10/10/11 00:21:33 .net
PC-9801用のOS-9ボードがあった、
MC68000拡張カードとOS-9/68K+Cで20万円くらいした。
9801のI/0も使えるし、切替えもできる。
もう少し安い価格ならばパーソナル用途に広まったのにと思う。
183:ナイコンさん
10/10/11 08:27:18 .net
>>172
URLﾘﾝｸ(nitros9.cvs.sourceforge.net)
これか、Level3って何？
…誰か腕自慢居ない？
184:ナイコンさん
10/10/11 15:38:11 .net
>>160
> 一体どこで道を誤ったんだろう？
> 確かWin95が出てくるまでは一番期待されていたOSではなかっただろうか？
商業的: Lotus1-2-3が実行出来なかったから。
思想的: GUI指向で無かったから。
前者はパソコンと言えばスプレッドシートを実行する物の時期に蚊帳の外。
1-2-3はMS-DOSをパンドルしてたし。
その根底にIBM PCが何故成功したのか?があるけど。
後者はOS-9がXerox Altoの影響を受けていなかった事。
MacintoshにしろWindowsにしろ、目指していたのはAltoのパーソナル版だった。
185:ナイコンさん
10/10/11 16:26:03 .net
「8086/8088のセグメントモデルで動作する」
「表面的にはUnixライク」
「モジュール化された」
「リアルタイムOS」
は、ちゃんと実在した。
QNXってヤツ。
メモリー256KB＋FDD2台のPC/XTでCコンパイラが動いて、PC-DOSよりよっぽど速かった。
186:ナイコンさん
10/10/11 17:05:04 .net
>>184
そういえばOS-9の表計算ってなんだっけ？
どちらにしてもGUIだよなあ、TOWNS辺りが採用していれば世界は変わっていた気がするな。
187:ナイコンさん
10/10/11 17:39:45 .net
OS-9/6809の頃は色々ありましたね。
URLﾘﾝｸ(gamdev4.hp.infoseek.co.jp)
188:ナイコンさん
10/10/11 20:42:43 .net
>>186
DynaCalc が表計算。
DynaStar がワードプロセッサ(エディタに毛が生えたようなものだが)
あとデータベースも出てたな。CSG-IMS。
189:ナイコンさん
10/10/11 20:55:24 .net
なんか昔のそういうのすごい貴重そうに感じるな
機能的にはたいしたことないんだろうけど
当時は値段も凄かったはず
190:ナイコンさん
10/10/11 21:10:58 .net
>>186
TOWNSでは勝敗は決していた気がする。
68000発売の翌年にIBMが採用していたらあるいは…
1978年 i8086
1979年 VisiCalc (AppleII)
1980年 OS-9
1980年 MC68000
1981年 IBM PC
1982年 Multiplan
1983年 Lotus 1-2-3
1984年 Macintosh 128k
1987年 X68000
1989年 FM TOWNS
1991年 Windows 3.0
1993年 Windows 3.1
191:ナイコンさん
10/10/11 21:40:19 .net
>>190
いやいや、MSDOSの次になれればまだ挽回できた。
linuxはまだないし。
192:ナイコンさん
10/10/11 23:17:49 .net
MS-DOSの次は、OS/2ってのが既定路線だった。
DOS/Vが出た頃のOS-9は、既に前時代だったな。
MS-DOSにはメチャ不満だったけど、TSRやら、アプリからのコマンドシェル起動でなんとか。
OS/2が出た時に、MS-DOSも実行出来るOS-9000/386があれば違ってたかも。
1985年 Compaq Deskpro 286
1986年 Compaq Deskpro 386
1987年 OS/2 1.0
1987年 OS/2 1.1
1990年 DOS/V
1991年 Windows 3.0
1993年 Windows 3.1
1994年 Windows NT 3.1
193:ナイコンさん
10/10/12 00:10:42 .net
>>192
DOS/VなんてDOSで日本語表示ができるだけの代物なんだから、
平成になった時にばら蒔けてれば全然違ったと思うんだけどなあ。
194:ナイコンさん
10/10/12 03:12:26 .net
日本の場合は、ハードを作るメーカーは電気メーカーで
大型機、オフコンを持っている。
もし、パソコンが高機能になってオフコン市場を削れば
利益が減り社内争いになりハードメーカーとして困る。
だから、この時代ではハードメーカーにとって高性能パソコンは悪と見なされた。
唯一NECは全力でパソコンに注入した。未来がPCにあると感じたのだろう。
NECは日本製CPUの開発にも力を入れ、そして日本一になった。
他のメーカーはパソコンに逃げ腰で構えた、そして、
８ビットをホビー、１６ビットを小企業向けと位置付け、
オフコンの立場を残すことにした。
また、X68k,Townsにしてもホビー専用とし、ビジネスを除外した。
元々モトローラーは6809を切り捨て68000にだけ力を入れた。
しかし、ハードメーカーは高性能な68000は困るから使わない。
そして時代は8086一色になった。
OS-9は6809と68000用のOSとして産まれた、
もし、社会が68000を選んだならOS-9が大きく成長した事だろう。
高性能で扱い易い68000は不運の道を歩むが技術者の支持を得て
長期に渡って組込み用途に使われる事になり、今でも生産されている。
195:ナイコンさん
10/10/12 07:05:42 .net
>>193
そうじゃなくて、「DOS/Vが日本に登場するほどx86が普及していた」と言いたいだけ。
少なくとも、IBM PCが81年に出たあとの10年は、失われた10年だと思う。
あのときOS-9が普及していれば、PCはもっと便利になっていた。
OS-9は優れたOSだった。
今にして思えばFM-8に8088カードがあったのが、将来を予言してたかな。
良いものが普及するとは限らない典型だと思う。
196:ナイコンさん
10/10/12 10:31:00 .net
>>195
価格的にはどうだったの？
197:ナイコンさん
10/10/12 14:03:51 .net
FM-8に8088カードなんかあったっけ？
FM-11でならV20に換装して使ってたけど。
すぐれたOSと言っても組み込み用途がターゲットで
汎用のOSとしてはあまりやる気を感じなかったな。
安くもなかったから、ハードにバンドルする形で
なければ普及なんて無理。
確か富士通で16βだったかの頃にOS-9/86が検討されたけど
バグか何かで見送られたって話じゃなかったっけ？
198:ナイコンさん
10/10/12 22:13:25 .net
>> OS-9/86
富士通パワーで作ってしまえばよかったのに、
16βはCP/M-86ではダメでしょ
199:ナイコンさん
10/10/12 23:58:59 .net
>>196
学生には高かったとしか覚えてないや
>>197
> FM-8に8088カードなんかあったっけ？
あったよ。なにしろFM-7/11の元だから、特徴的なところはFM-8からあったんだよね。
WiKiにも載ってる。URLﾘﾝｸ(ja.wikipedia.org)
200:ナイコンさん
10/10/13 02:57:22 .net
富士通+IBM+microwareでpcdos互換DOS箱付きOS-9000/386を作ってバンドル販売していればどうだろう？
当然コンパックでも動いただろうから、MSの出る幕はあったのだろうか？
201:ナイコンさん
10/10/13 07:07:09 .net
>>200
OS-9000って、仮想記憶あった？
メモリが高価なあの頃、ワープロ・スプレッドシート等を何個も立ち上げられたら便利だったろうなぁ
202:ナイコンさん
10/10/13 07:37:27 .net
っていうか、そもそも表ごときがなんでそんなにメモリ消費するんだろ？
203:ナイコンさん
10/10/13 08:20:33 .net
亀レス
>>156
ありがと、初めてOS-9L2を見た(笑)。←使い方を忘れてる。
昔のFDは保存してるけど、今でもコンバート出来るんだろうか。
>>157
ありがと、そうそうGIGO氏。神様だった。
>>166
> 制限無しで移植するには386まで待たなければならなかったが、それでは遅すぎだよね
ありえないけど、モトローラが32bit化を意識した、先進思想で6809を設計していていたら…。
その後、68009,68109,68209…と、ソフトの蓄積重視でバイナリ互換を実現していたら、あるいは…。
>>159
> 悲しいかなもはや需要はないだろう
今のARMの立ち位置を目指していれば、まだ需要があったかも。
204:ナイコンさん
10/10/13 08:33:23 .net
よくわからないけど、仮想記憶ってDATがメインメモリの無い所を参照したら、RBFに振り替えるってだけじゃダメなの？
205:ナイコンさん
10/10/13 09:05:45 .net
32bit化を意識って、コードは63C09のままで、IOからCPUのどっかの端子をオンにすると、インデックスとスタックレジスタが32bit化する。
…みたいな感じでなんか問題あるだろうか？
206:ナイコンさん
10/10/13 20:35:46 .net
夢見がちにも程があるな、みんな
207:ナイコンさん
10/10/13 20:48:12 .net
空想記憶を意識って、MC68008のコードを半分に削って、内部にMC6809を組み込んで、
IOからCPUのどっかの端子をオンにすると、68008と6809が切り替わる。
…みたいな感じでなんか問題あるだろうか？
208:ナイコンさん
10/10/13 20:57:31 .net
だから68000は単独で仮想記憶出来なかったっつーに
仮想記憶管理用だけのためにもう一個68000を積む必要があった
ハードウェア的にバグってたというより仮想記憶を意識した設計にしなかったための
痛恨のミス
仮想記憶が一CPUで出来るようになったのは68010から
209:ナイコンさん
10/10/13 21:02:34 .net
いや、OS-9のDATって論理アドレス変換でしょ？ 要は。
210:ナイコンさん
10/10/13 21:04:26 .net
OS-9はRTOS用として設計されたから時間的に多大なオーバーヘッドを
必要とする仮想記憶は考慮外だった
211:ナイコンさん
10/10/13 22:33:04 .net
16ビットプログラムカウンタのCPUで、２MBが管理できる時点で、そもそも仮想記憶なんじゃないだろうか？
212:ナイコンさん
10/10/13 22:33:58 .net
おっとMPUだった。
213:ナイコンさん
10/10/13 22:58:17 .net
MMUだろそれ
仮想記憶とは違う
214:ナイコンさん
10/10/13 23:04:57 .net
だって、メモリにマップする以上補助記憶も区別つかないじゃないか。
215:ナイコンさん
10/10/13 23:06:02 .net
仮想記憶を実現する為のハードがMMUです。
216:ナイコンさん
10/10/14 01:17:01 .net
以下、ウロ覚えで書いてるから間違いがあったらご容赦
>>204
ごめん。仮想記憶の話は386や(実在しない)68x09の話。
6809なら仮想アドレス=実アドレスで意味ないし。
>>205
> 32bit化を意識って、コードは63C09のままで、
今のIA-32命令は、32bit命令にプリフィックスが付く可変長命令体系。
結果、命令デコードが大変。Intel vs AMDの性能の優劣も、命令デコードが鍵を握ってるし。
なので、レジスタ指定やらアドレッシングで簡単に32bitを指定出来る命令体系だったら…という話。
実際、6809命令に空きビットがあったかどうかは覚えてないけど。
勿論、x86系みたく力業で命令体系を拡張してもいいけど、それは68系の美学(笑)に反する。
>>208
> 仮想記憶管理用だけのためにもう一個68000を積む必要があった
それ、聞いた事がある。
確か、一命令位の時間差で実行し、先行するMPUが実メモリの無い空間にアクセスしたらそれを検知。
後発MPUには問題なくアクセス出来るように処置する…だった様な。
>>214
> だって、メモリにマップする以上補助記憶も区別つかないじゃないか。
補助記憶装置はメモリ空間に直接マッピング出来ないし。
確かにMPUには区別無いよ。
無いけど、(実メモリが)マッピングされていない空間にアクセスするとMMUから一般例外が発行されるの。
するとMPUと言うかOSが、補助記憶と主記憶とでデータをスワッピングし、アドレスをマッピングしなおして処理を再開。
元の処理に戻ると何事も無かった様に処理を継続出来る。
そんな訳で、DOS窓を何個も実行出来るOS-9/386があったら良かったなと。
(連投します)
217:ナイコンさん
10/10/14 01:33:06 .net
>>216
> そんな訳で、DOS窓を何個も実行出来るOS-9/386があったら良かったなと。
しかし、実際には Windows 2.0時代で既に出来てた。
それは386対応のWindows/386。登場は1990年。
スレチでした
218:ナイコンさん
10/10/14 01:57:20 .net
OS-9/6809の頃、8086のクロックが8MHzであった。
OS-9でマルチタスクで走らせると遅くなる、
完全な時分割だから すごく遅くなる。
急ぎの仕事の時は、PC-9801を3台並べて使った、
データはフロッピーで交換して同時に走らせる、結局これが速い。
OS-9のシリアルポートに複数のPC-9801/MS-DOSを接続して
同時に走らせると快適だろうと思う。
これは当時のunixで普通に使われる方法でした。
時代は流れMINIXが産まれLinuxが育った今、
OS-9の価値を見出す事が出来るのか？
容易にROM化できる特性を活かした組込みしか残って無かった。
219:ナイコンさん
10/10/14 02:01:40 .net
要するに、存在しないアドレスをマップしたら割り込み起こさないとスワップが動かないってこと？
サービスリクエストにメモリマップ覚えさせとけばいいだけじゃない？
220:ナイコンさん
10/10/14 13:53:24 .net
>>216
> > 仮想記憶管理用だけのためにもう一個68000を積む必要があった
> それ、聞いた事がある。
> 確か、一命令位の時間差で実行し、先行するMPUが実メモリの無い空間にアクセスしたらそれを検知。
> 後発MPUには問題なくアクセス出来るように処置する…だった様な。
もう一個68000を積んだ、はその通りだけど「一命令ぐらいの時間差で」は俗説で
実際にはそういう形で動いていたのではなかったようです。
だってそれ無茶でしょ。メモリは書き換えられるものだし、I/Oの処理関連なんか
それで2つのCPUが同期して動く訳が無い。2つのCPUを同じ状態にして動かすぐらい
なら専用のハードウェアを作ったりCPUを設計しなおした方がよっぽど簡単だし早い。
URLﾘﾝｸ(www.st.rim.or.jp)
実際には上のページにあるようにページフォルトが発生した時点でメインのCPUを
止める。それから2つ目のCPUがページのロード、再配置処理を行って再実行でき
るように環境を整える。ここでメインのCPUに処理を切り替えて止めたところから
命令を実行する。そういう形で実装していたそうです。
221:ナイコンさん
10/10/14 20:51:12 .net
・・・サイクルスチール？
222:ナイコンさん
10/10/14 22:50:07 .net
使ってる技術 (バス調停) は同じだけど、サイクルスチールはあくまでも
メモリサイクルを「盗む」もので、>>220 の話とは目的が違うよ。
223:ナイコンさん
10/10/15 00:24:33 .net
>>220
68000を2個搭載して仮想記憶を実現したのは、Apollo社のdomainワークステーションだね。
OSはUnixじゃない・ネットワークはEtherじゃない・標準の開発言語はCじゃなくてPascal
という、今にして思えば変なマシン。
それ以外の68000ベースのUnixマシンは（SUNも含めて）、仮想記憶じゃなかった。
224:ナイコンさん
10/10/15 01:18:27 .net
>>220
そういう実装だったんだ、なるほどねぇ。
>>223
> それ以外の68000ベースのUnixマシンは（SUNも含めて）、仮想記憶じゃなかった。
Version 7 UNIXとOS-9の違いって、なんだろう。
どちらも仮想記憶がなく、16bit CPUで動作した。
Version 7 UNIXが6809にポーティングされてたら、OS-9の立場が無かった?
>>172
> NitrOS-9 てのがある。
GUIもあるのね。CoCoのエミュ上で実行してみたくなった。
他、追って言ったらGCC6809があるのね。
GCCがあるなら、uCLinuxかLinux8086なら6809にポーティング出来たりして。
225:ナイコンさん
10/10/15 01:34:31 .net
unixはCコンパイラで作られて大きい、
そしてハードディスクを前提に設計されている。
OS-9はディスクを必要としない。メモリだけでも動作する。
OS-9用のgccがあるはず、68kのPDSになってる。
226:ナイコンさん
10/10/15 02:01:24 .net
OS-9/68000は銀行のATMに使われた事があるな
227:ナイコンさん
10/10/15 06:48:09 .net
>>225
Version 7 UNIX、つまりXENIXはi8086で動作したんだよ。
8086で動いたなら、6809でも出来そう。ディスクの件抜きで
228:ナイコンさん
10/10/15 10:47:22 .net
64kBのメモリで動くとは思えん
229:ナイコンさん
10/10/15 12:46:19 .net
>>228
PDP-11/20は56ｋBだったよ。
UNIXも最初は小さかったのさ。
230:ナイコンさん
10/10/15 22:47:20 .net
OS-9 Level 1 (64KB) でもCコンパイラが一応動いてたからな。
メインメモリが64KBでも、256KBとか512KBのRAMディスクがあれば
比較的快適だった。
231:ナイコンさん
11/02/14 19:52:30 .net
ヤフオクのMacintosh > OSにOS-9が出品されている不思議
232:ナイコンさん
11/02/14 23:11:24 .net
これのこと?
URLﾘﾝｸ(page2.auctions.yahoo.co.jp)
たしかに MICROWARE って書いてあるけど
動作環境が不明だ…
233:ナイコンさん
11/02/20 23:27:32.42 .net
単に素人がMAC OS9と間違えたんだろ。
234:ナイコンさん
11/09/10 16:52:16.57 .net
age
235:ナイコンさん
11/09/10 19:57:52.29 .net
久々にカキコがあったな。
つい最近、SH用のOS-9があることを知って懐かしかった。
OS-9 for Embedded Systems/SuperH
URLﾘﾝｸ(japan.renesas.com)
236:ナイコンさん
11/09/10 20:37:22.58 .net
SHって日立だよな。
これって68系?(ってほども似てないか)
237:ナイコンさん
11/09/10 21:35:58.46 .net
ＳｕｐｅｒＨは、日立(今はルネサス)のオリジナルだよ。
68系ならARMかな。あれは6502からRISCに進化したものだから。
逆に68kを8bitに退化させたのが、ルネサスのH8
URLﾘﾝｸ(ja.wikipedia.org)
思うんだが、SHでもARMでも、ボードマイコン上でOS-9が走ってたら楽しそう…。
昔を懐かしんでいるだけかな。
238:ナイコンさん
11/09/10 23:56:30.01 .net
SuperHというとセガサターンのSH2が有名だな。
239:ナイコンさん
11/09/11 05:40:46.23 .net
DreamCastもあったぜよ。
OS-9、限定でいいからフリーになんないかな。
240: 【東電 74.4 %】
11/09/11 13:01:16.63 .net
スレチだがNECになってもちゃんと残ってた
URLﾘﾝｸ(resource.renesas.com)
OS-9ってプログラムカウンタ相対が無いと無理じゃないのか？
241:ナイコンさん
11/09/11 13:07:47.49 .net
ポジションインディペンデント、リエントラント
242:ナイコンさん
11/09/11 18:08:32.67 .net
>>237
>68系ならARMかな。あれは6502からRISCに進化したものだから。
え? 馬鹿なの?
243:ナイコンさん
11/09/11 20:56:21.60 .net
>>242
> え? 馬鹿なの?
え? アホなの?
URLﾘﾝｸ(ja.wikipedia.org)アーキテクチャ
命令セットは8ビットCISCである6502を発展させたものであり、典型的なRISCというよりはむしろCISC的で[1]手作業による最適化がしやすい特徴的なアーキテクチャを持つ。
244:ナイコンさん
11/09/11 20:58:18.45 .net
Wikipediaのアホ記述信じてるバカ発見
245:ナイコンさん
11/09/11 21:01:55.04 .net
>>243
>命令セットは8ビットCISCである6502を発展させたものであり、
全然違うだろｗ
>典型的なRISCというよりはむしろCISC的で[1]手作業による最適化がしやすい特徴的なアーキテクチャを持つ。
条件実行だの3オペランドだの変態的なだけだろｗｗ
246:ナイコンさん
11/09/11 21:03:50.70 .net
>>243
>命令セットは8ビットCISCである6502を発展させたものであり、
6502の命令セットのどの辺をどう発展させたかお前の言葉で説明してみ?
247:ナイコンさん
11/09/11 21:06:52.20 .net
同種の馬鹿発見
URLﾘﾝｸ(it.slashdot.jp)
248:ナイコンさん
11/09/11 21:15:25.38 .net
>>243
>え? アホなの?
>URLﾘﾝｸ(ja.wikipedia.org)アーキテクチャ
>命令セットは8ビットCISCである6502を発展させたものであり、典型的なRISCというよりはむしろCISC的で[1]手作業による最適化がしやすい特徴的なアーキテクチャを持つ。
脚注に
>1. ^ 可変長の命令でコード密度を向上させ、多彩なアドレッシングモードを持つことにより命令数を
>削減するなど、CISC的な特徴を低消費電力化に利用している。ただしマイクロプログラムは持たず
>過度の複雑さを避けるなど、RISCの利点も存分に活かしている。
なんて書いてあるけど、これがどんだけトンチンカンなことか理解できる?
249:ナイコンさん
11/09/11 21:15:41.33 .net
>>243
英語版にはそんな記述ないよ。
URLﾘﾝｸ(en.wikipedia.org)
250:ナイコンさん
11/09/11 21:32:01.95 .net
>68系ならARMかな。あれは6502からRISCに進化したものだから。
>逆に68kを8bitに退化させたのが、ルネサスのH8
うわぁ…
251:ナイコンさん
11/09/11 21:33:34.59 .net
URLﾘﾝｸ(www.cqpub.co.jp)
252:ナイコンさん
11/09/11 21:40:04.66 .net
6502採用のPCの後継機種用として開発された最初期のARMに、6502の
エミュレーション機能があったってのは、ARMの命令セットが6502の
それを発展させたものだってのとは全然違う話だよなぁ。
253:ナイコンさん
11/09/11 21:54:54.70 .net
URLﾘﾝｸ(techtarget.itmedia.co.jp)
当時、Acornはモステクノロジーの「6502」というプロセッサをベースにマイコンを作っており
254:ナイコンさん
11/09/11 22:01:44.96 .net
URLﾘﾝｸ(www.tumblr.com)
The spirit of 6502 ?- clean instruction set on economical processor ?- was inherited to Acorn’s RISC Machine, that is currently known as ARM.
The Acorn was a huge 6502 user and also a developer of extender (co-processor) of the 6502; they should have known the 6502 quite deeply.
もっと見たい? んなの、事実なんだからいくらでも出てくるよ。
255:ナイコンさん
11/09/11 22:03:16.20 .net
>>252
NECのV60やV70にはV30のエミュレーションモードがあったらしいけど、アーキテクチャは全然違うよね。それと同じ。
URLﾘﾝｸ(multimedia.cx)
256:ナイコンさん
11/09/11 22:06:00.95 .net
>>243
>命令セットは8ビットCISCである6502を発展させたものであり、
早く根拠出せよ。 ﾁﾝﾁﾝ(AA略
257:ナイコンさん
11/09/11 22:07:53.22 .net
>>256
>>254
258:ナイコンさん
11/09/11 22:10:49.45 .net
>>237
>68系ならARMかな。あれは6502からRISCに進化したものだから。
ARMが6502を進化させたものだと言ってるのも痛いが、6502を68系って言ってるのも痛いな。
マイナス×マイナスでプラスにならなかったのが残念。
259:ナイコンさん
11/09/11 22:20:30.93 .net
>>254
単純な命令セットで安価なプロセッサを実現するという6502の精神を引き継いだ
とは書いてあるね。それで?
>6502からRISCに進化したものだから。
>命令セットは8ビットCISCである6502を発展させたものであり
全然違う話だよね?
260:ナイコンさん
11/09/11 22:26:34.31 .net
>6502からRISCに進化したものだから。
>命令セットは8ビットCISCである6502を発展させたものであり
こんなこと言うと
8080→Z80→Z380
8080→8086→80386→AMD64
6502→65816
6800→6809
フツーコレぐらいの話だよな。
6502→ARM? 共通点探すほうが難しいだろｗ
261:ナイコンさん
11/09/11 22:38:39.62 .net
>>243
お前が6502かARMのどちらか、あるいは両方を知らないことは分かった。
262:ナイコンさん
11/09/11 22:50:12.64 .net
このネタはいつも論争になるな
263:ナイコンさん
11/09/12 02:13:08.70 .net
>>237
おいおい、お前6502とARMのアーキテクチャ知ってて言ってんの?
>>243
6502→1語1～3バイトの可変長
ARM→1語4バイトの固定長
thumb→1語2バイトの固定長
基本的なところで全然違うじゃんよ。何言ってんの?
>>254
出所も分からん全然関係ない話引っ張って来て何言いたいんだよ。
いいから6502からRISCに進化したものがARMって根拠さっさと挙げろや。いくらでも出てくるんだろ?
264:ナイコンさん
11/09/12 19:46:35.40 .net
OS-9スレでARMの話を力強くされても。
265:ナイコンさん
11/09/12 19:50:49.85 .net
だってARMは6502から進化してるんだから、無関係でも無いでしょ
266:ナイコンさん
11/09/12 20:33:15.42 .net
ARM版OS-9もあるみたいだから無関係ではないな。6502は完全にスレ違だが。
267:ナイコンさん
11/09/12 20:37:05.32 .net
OSのスレッドでプロセッサの議論をするのはスレ違いだと思う。
268:ナイコンさん
11/09/12 20:53:10.18 .net
モトローラ社がMC6809を開発中に、マイクロウエア社へBASIC09の開発依頼をした、
マイクロウェア社は、BASIC09の為の環境ソフトとしてOS-9を作った、もちろんアセンブラで記述されている。
BASIC09は構造化されたパスカルに似た構造を持っており、セミコンパイルされる。
OS-9は次にMC68000版を作った、OS-9/68000である。
そして、C言語へ書き直されマルチプラットフォーム化されOS-9000と呼ばれた、
後に全部を含めてOS-9と呼ぶようになった。
ちなみに、Mac OS-9とは完全に別物である。
269:ナイコンさん
11/09/12 20:54:50.09 .net
>>265
俺、このスレの住人はもう少しまともだと思ってたんだが…。
URLﾘﾝｸ(www.ot1.com)
As described earlier, these were for a processor which retained the ethos of the 6502 but in a 32-bit RISC environment,
270:ナイコンさん
11/09/12 21:19:24.59 .net
Wikipedia酷いな。
ARMアーキテクチャ - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
> 命令セットは8ビットCISCである6502を発展させたものであり、
> ARMの設計は、1983年にエイコーン・コンピュータによって開始された。その開発は
> モステクノロジー 6502の延長とも言えるものであり、当時6502に基づいた一連の
> コンピューターを製造していたエイコーンにとっては、同じ要領でプログラムできる
> チップは大きな強みになるはずであった。
> ARMのインストラクション・セットは6502のコンセプトに沿っているが、
MOS 6502 - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
> なおARM (Acorn RISC Machine) は、6502の延長として設計されており、6502との
> 共通点が見られる。
271:ナイコンさん
11/09/12 22:59:37.76 .net
>>268
Macの方はMacOS 9だよ。MicrowareがAppleを訴えたけど、
負けたんだったか、引っ込めたんだったな。
272:ナイコンさん
11/09/12 23:11:18.00 .net
確か負けたんだよ。
MACのほうはあくまでOSの9番目以上の意味はないとか、じゃなかったかな。
386とか486なんかとおんなじ扱いだったと思う。
273:ナイコンさん
11/09/12 23:19:48.54 .net
>>271
ちょびっと書いてあるな
URLﾘﾝｸ(en.wikipedia.org)
274:ナイコンさん
11/09/13 00:54:42.52 .net
アップルの他人の権利を踏みにじるやり方だけは許せないよなあ。
275:ナイコンさん
11/09/13 00:58:18.78 .net
>>270
うぃきなんて参考程度で信用出来ない
必ず他の方法で裏とらないととんだ恥をかく事になる
なんてたって無責任な素人のマメ知識自慢でしか無いからな
276:ナイコンさん
11/09/13 20:37:21.57 .net
自分もARMは6502の何か(インストラクションセット的に)を受け継いでるものと
ぼんやり思ってたけど違うんだね。まあそうとわかっているなら詳しい人は
Wikipedia修正してくれてもいいのに、とかは思う。Wikipediaなんか絶対使わない
ってんならお願いはできないけど
277:ナイコンさん
11/09/13 21:18:22.25 .net
CPUとOSの関係: ARM版Windowsは「買い」か Posted by 横山哲也 ( 2011年01月11日 )
URLﾘﾝｸ(www.computerworld.jp)
> 余談: そもそもARMはモステクノロジー6502アーキテクチャの流れをくむプロセッサである。
↑プロのライターっぽい人がこーゆーおかしなこと書いちゃうのも、Wikipedia辺りのデタラメ記述に
遠因があんのかな?
278:ナイコンさん
11/09/13 21:32:37.24 .net
> アーキテクチャの流れをくむ
この表現であれば、間違いではない。 正しいとは言わないが
279:ナイコンさん
11/09/13 21:36:42.68 .net
6502を積んだ機種の後継機用に開発されただけであり、アーキテクチャ上の繋がりとかはない。
280:ナイコンさん
11/09/13 21:39:29.75 .net
余談: そもそもPowerPCはモトローラ68kアーキテクチャの流れをくむプロセッサである。
こういうことも間違いではないことになるなｗ
281:ナイコンさん
11/09/13 22:27:33.79 .net
ケツの拭きが甘かったのかアナルが痒くなってきた。
早く西本棟にもウォシュレット導入してくれ
282:ナイコンさん
11/09/13 22:29:07.16 .net
だめ
283:ナイコンさん
11/09/13 23:06:04.33 .net
>>280
ならんだろ。Powerに68kエミュレーション機能を付けて1chip化した
もんでしょ。Powerと68kには何のつながりもないし。
284:ナイコンさん
11/09/13 23:27:08.29 .net
x86アーキテクチャ
4004→8008→8080→8085と進化した8bitアーキテクチャ。
それを受け継ぎ、命令セット互換性を保ちつつ16bitに拡張した8086。
その8086に、マルチタスクやデータの完璧さや安全性の為にプロテクトモードを導入した80286。
さらに286を32bitに拡張した80386により、現在のx86アーキテクチャは完成した。
その後、順当に486,Pentiumと32bit CISCプロセッサとして進化した。
しかし、Pentium→PentiumPro時に内部をダイナミックに変更し、RISC構造を導入した。
これが現在のCoreプロセッサに繋がる原型の誕生である。
だが、内部が幾らダイナミックに進化しようと、AMDが互換プロセッサを作ろうと、
8085から始まったx86アーキテクチャである事には変わりない。
これに何か異論があるか?
285:ナイコンさん
11/09/13 23:28:31.64 .net
結局、x86アーキテクチャなぞソフトから見たアーキテクチャでしかない。
もし仮に、インテルが8085から途中の16/32bit CISCを伏せたまま一気にPentiumProを発表したら、
それはアーキテクチャを継承していないと言えるのか?
順次発表したら継承で、飛び越して発表していたら継承ではないと強弁するのか?
おまえらの言っていることは、これと同じ論理だよ。
286:ナイコンさん
11/09/13 23:38:26.71 .net
8086は8085を受け継いでいない
287:ナイコンさん
11/09/13 23:41:49.27 .net
8086は8085の完全互換です。
288:ナイコンさん
11/09/13 23:42:23.69 .net
>8085から始まったx86アーキテクチャである事には変わりない。
異論あるよ
289:ナイコンさん
11/09/13 23:44:11.83 .net
>>287
ピンアサインから違うのに完全互換なワケない
290:ナイコンさん
11/09/13 23:46:25.82 .net
ソースコードレベルで互換。
6800と6809も そう
291:ナイコンさん
11/09/13 23:48:59.58 .net
>>284
>4004→8008→8080→8085と進化した8bitアーキテクチャ。
>それを受け継ぎ、命令セット互換性を保ちつつ16bitに拡張した8086。
8085は組み込み用の性質が強いから外して。
292:ナイコンさん
11/09/13 23:55:21.46 .net
>>290
>6800と6809も そう
昔からよく言われるが間違い
293:ナイコンさん
11/09/13 23:56:32.41 .net
>>285
>順次発表したら継承で、飛び越して発表していたら継承ではないと強弁するのか?
>
>おまえらの言っていることは、これと同じ論理だよ。
ちょっと何言ってるかわかりませんね
294:ナイコンさん
11/09/14 00:19:46.49 .net
>>284
>その後、順当に486,Pentiumと32bit CISCプロセッサとして進化した。
Pentiumの頃にはCISCとRISCのいいとこどりのCRISCとか言ってた筈。
295:ナイコンさん
11/09/14 00:31:40.55 .net
>>284
>4004→8008→8080→8085と進化した8bitアーキテクチャ。
4004が8bitアーキテクチャ?
296:ナイコンさん
11/09/14 00:36:44.42 .net
>>284
>4004→8008→8080→8085と進化した8bitアーキテクチャ。
>それを受け継ぎ、命令セット互換性を保ちつつ16bitに拡張した8086。
命令セットに互換性はない。
8080から8086へのソースコードレベルでのコンバートがし易いよう考慮されてるだけ。
297:ナイコンさん
11/09/14 00:38:59.20 .net
>>284
>さらに286を32bitに拡張した80386により、現在のx86アーキテクチャは完成した。
完成していないから386以降もドンドン命令が追加され続けてるわけですが。
298:ナイコンさん
11/09/14 00:49:17.52 .net
>>284
>これに何か異論があるか?
8085をx86と呼ぶのはおかしいと思う
299:ナイコンさん
11/09/14 00:50:24.39 .net
>>292
なにがどう間違い？
300:ナイコンさん
11/09/14 00:50:53.75 .net
>>284
>その後、順当に486,Pentiumと32bit CISCプロセッサとして進化した。
スーパースケーラが導入され、外部データバスが64bit化されたPentiumを
単純に"32bit CISCプロセッサ"と言い切って良いかは疑問。
301:ナイコンさん
11/09/14 00:50:56.67 .net
>>284
4004は8ビットじゃないよ。
最初から最後まで間違ってんじゃんｗ
302:ナイコンさん
11/09/14 00:52:51.16 .net
>>299
6800のABA(A=A+B)のような命令が、6809には相当するものがなかった筈。
303:ナイコンさん
11/09/14 00:56:49.14 .net
>>284
>データの完璧さ
意味不明
304:ナイコンさん
11/09/14 01:00:50.72 .net
>>284
>さらに286を32bitに拡張した80386により、現在のx86アーキテクチャは完成した。
フツー16bitと32bitと並べて"x86アーキテクチャ"なんて言いません。
"386"とか、"x86-32"とか、"IA32"とか、分かるよう表記を区別します。
305:ナイコンさん
11/09/14 01:05:19.23 .net
>>284
>それを受け継ぎ、命令セット互換性を保ちつつ16bitに拡張した8086。
命令セットは大幅に強化されてるし、メモリ空間も広くなってるし、数値演算
コプロセッサの使用も考慮されてるしで↑みたいな単純な話じゃないですね。
306:ナイコンさん
11/09/14 01:05:24.52 .net
必死な奴らw
307:ナイコンさん
11/09/14 01:10:33.12 .net
>>285-305
ざっと読んだが、肝心の「順次発表したら継承で、飛び越して発表していたら継承ではないと強弁するのか?」への反論は無いのか?
308:ナイコンさん
11/09/14 01:12:07.45 .net
>>284
>これに何か異論があるか?
挑発的なこと書いちゃったらいくらかツッコミ入れられるのも仕方ないよね
309:ナイコンさん
11/09/14 01:13:17.01 .net
>>307
>肝心の「順次発表したら継承で、飛び越して発表していたら継承ではないと強弁するのか?」への反論は無いのか?
意味分からんのだけどそれ誰の主張?
310:ナイコンさん
11/09/14 01:14:35.72 .net
8085→PentiumProの過程と、6502→ARM1への過程との本質的な違いは何か?
311:ナイコンさん
11/09/14 01:15:39.02 .net
時間はたっぷりあるから、一晩でも二晩でも考えてなw
312:ナイコンさん
11/09/14 01:16:22.91 .net
>>307
>ざっと読んだが、肝心の「順次発表したら継承で、飛び越して発表していたら継承ではないと強弁するのか?」への反論は無いのか?
>>284と>>285が繋がってるって誰も分かってないんじゃないの?
つーか>>285で何言いたいのか俺も分からん。
313:ナイコンさん
11/09/14 01:18:51.58 .net
>>285
>結局、x86アーキテクチャなぞソフトから見たアーキテクチャでしかない。
ソフトから見てx86互換のCrusoeをx86アーキテクチャという人はいないんじゃない?
314: 【東電 64.9 %】
11/09/14 01:19:25.46 .net
x86はDISCでいいだろ
315:ナイコンさん
11/09/14 01:30:48.74 .net
>>285
>もし仮に、インテルが8085から途中の16/32bit CISCを伏せたまま一気にPentiumProを発表したら、
>それはアーキテクチャを継承していないと言えるのか?
8085とPentiumProは、レジスタの構成やフラグの並びなど似たようなところは結構あるよ。
アセンブラのニモニックも共通なのがあるし。
6502とARMは、そうではないね。
316: 【東電 64.9 %】
11/09/14 01:31:50.67 .net
intelがVLIWでx86命令セットの実行エンジンを実装したら
x86アーキテクチャと言ってしまいそうな気がする
317:ナイコンさん
11/09/14 01:53:03.43 .net
>>285
>順次発表したら継承で、飛び越して発表していたら継承ではないと強弁するのか?
何言いたいのか分からん。
6502の何がARMに継承されてるのか説明してみ?
8080→IA32のフラグレジスタみたいな分かり易い例がいいわ。
URLﾘﾝｸ(www.st.rim.or.jp)
URLﾘﾝｸ(www.kollewin.com)
318:ナイコンさん
11/09/14 01:59:08.21 .net
6502レジスタ(含フラグ)
URLﾘﾝｸ(www.st.rim.or.jp)
ARMレジスタ
URLﾘﾝｸ(www.botskool.com)
ARMフラグ
URLﾘﾝｸ(www.botskool.com)
まあ、これ見るだけでも違うってわかるよね。
319:ナイコンさん
11/09/14 03:23:42.43 .net
>>307
>順次発表したら継承で、
4004→8008→8080→8085→8086→80286→80386→486→Pentium→PentiumPro ってコト?
>飛び越して発表していたら継承ではないと強弁するのか?
6502→ARM ってコト?
6502からARMに何がどう継承してるの? まずそれを主張すれ。
320:ナイコンさん
11/09/14 03:25:49.81 .net
>>311
>時間はたっぷりあるから、一晩でも二晩でも考えてなw
このヒトまず自分の主張が相手に自分の意図した通りに伝わってるかどうか気にした方いいと思うよ。
321:ナイコンさん
11/09/14 03:51:19.93 .net
>>284-285みたいなこと書いちゃう人だから馬鹿かコミュ障なんじゃないかと…
322:ナイコンさん
11/09/14 06:09:16.66 .net
>6502からARMに何がどう継承してるの? まずそれを主張すれ。
1. 外部からの入力に応じて内部が変化するところ
2. クロックに同期して動作するところ
3. 電気で動作するところ
4. 原料
323:ナイコンさん
11/09/14 10:30:57.66 .net
>>322
>1. 外部からの入力に応じて内部が変化するところ
6502には確かに外部からの入力を内部に反映させる~S.O.(Set Overflow)という入力信号が
存在するが、ARMには同等のものは存在しないのでは?
>2. クロックに同期して動作するところ
SYNCとRDYでシングル命令実行できる6502は、必ずしも「クロックに同期して動作する」とは
言えないのでは?
>3. 電気で動作するところ
>4. 原料
半導体製品として実現された6502に対し、アーキテクチャのライセンスを販売するARMは、
実際の実装は自由であり、上記の主張は必ずしもそうだとは言い切れないのでは?
324:ナイコンさん
11/09/14 20:53:01.16 .net
だれかWikiを書き換えてやれよ
明らかに間違っているだろ
325:ナイコンさん
11/09/14 22:02:12.98 .net
>>284
>>285
おい、なんか返事しろよ
326:ナイコンさん
11/09/14 22:05:12.69 .net
>>307
>肝心の「順次発表したら継承で、飛び越して発表していたら継承ではないと強弁するのか?」への反論は無いのか?
それ以前に、「飛び越して発表したけど継承ですよ」の主張が見当たらんのだが。
327:ナイコンさん
11/09/14 22:38:23.53 .net
えらくスレ違いで盛り上がってるなw
328:ナイコンさん
11/09/15 00:10:47.52 .net
みんな元OS-9ユーザーだったかと思うと頭が痛い
329:ナイコンさん
11/09/15 10:42:19.71 .net
Airユーザーもいるだろ
330:ナイコンさん
11/09/15 14:58:12.55 .net
Air って何? 検索したけど Ubiquiti ?とかいう会社のサイトしか見つからなかった
Microware と何か関係あるのかな
ちなみに自分は、Basic-09 ぐらいしか知らない万年初心者なので、すみません
331:ナイコンさん
11/09/15 15:04:22.90 .net
AirギターのAir。つまり見せかけOS-9ユーザー。
332:ナイコンさん
11/09/15 17:00:09.79 .net
>>330
333:330
11/09/15 18:30:31.54 .net
なるほど、そういう言い回しがあるんですかw
面白い勉強をさせてもらいました。Thx
ちなみに恥を拡げるような質問だけど、割れ(不正)品ユーザの意味も含む?
それとも、OS-9L2まで購入しながらBasic09もろくに使いこなせなかった
自分のような「とりあえず持ってましたー／w」ユーザの意味かな?
334:ナイコンさん
11/09/15 19:25:46.99 .net
うちの犬（＝柴犬）の得意技が「Airお手」だったりする。
335:ナイコンさん
11/09/15 20:10:17.71 .net
>>333
まったくOS-9を持っていない、使ったことのない人。
336:ナイコンさん
11/09/15 22:47:35.96 .net
X6のOS-9 68000はCで書かれているらしくとても遅かった
FM-11のOS-9の方がストレス無く使えた
期待して買ったのにとてもshockだった印象が残っている
アセンブラで書かれたOS-9 68000がほしい
そもそもHumanみたいなクソOSやSX-Windowなんか開発して付けるくらいなら
OS-9を付けて欲しかった
337:ナイコンさん
11/09/15 23:59:12.36 .net
>>336
残念だが、X68000用のOS-9はアセンブラで書かれている。
338:ナイコンさん
11/09/16 00:00:48.25 .net
Cだろ
339:ナイコンさん
11/09/16 00:01:35.17 .net
アセンブラは6809版
340:ナイコンさん
11/09/16 00:07:36.86 .net
>>302 >>299
ソース互換だからいいんだよ。
っていうか、アセンブラが頑張ってただけだよ。
この手の命令の場合はスタックにプッシュして、スタック間接
アドレッシング＋オートインクリメントとかで実現したと思う。
バイト数は食うは遅くなるはで、その場しのぎならいいけど、
通常はソース書き直すはめになる。
8085→8086の変換の方が効率はよかったな。
341:ナイコンさん
11/09/16 00:12:03.85 .net
>>338 >>339
このスレの住人のくせに何間違って覚えてんだよ。
6809と680x0版のOS-9に限ってアセンブラで書かれている。
もちろんカーネル部分のみね。
680x0版のコマンドは確かにCで書かれたものが多かったかもしれん。
6809版はコマンド類も全部アセンブラ。
342:ナイコンさん
11/09/16 05:07:29.71 .net
MC68Kはクロック当りのIPC値が低いのでカーネルをアセンブラで書いても遅いのではないかと。
開発言語の問題ではなく、そもそもMIPS値が出ない。
MC68K採用した他のOSでも同時にマルチプロセスを起動すれは極端に遅くなります。
FM11は今風に言えばデュアルコアであった為にストレス無くOS9が動いた可能性が大きい。
だからこそUNIX-WSメーカーはRISCへ移行したのです。MACやNEWS等の国内を含め。
正確なベンチマークテストと計算オーダーの見積もりが出来なかった所が最後までMC68Kを過信したのです。
343:ナイコンさん
11/09/16 05:29:12.45 .net
ただ、遅いとはいえ、身近なUNIX環境としての評価は高く、価値はあった。
マルチプロセス、ウインドウという環境は当時Windowsすら無い時代にあっては貴重な体験です。
ウインドウとシェル環境は、当時一般的なエントリーPC環境には無く、ハイエンドWS環境なのですから。
344:ナイコンさん
11/09/16 06:44:38.14 .net
>FM11は今風に言えばデュアルコアであった為にストレス無くOS9が動いた可能性が大きい。
345:ナイコンさん
11/09/16 06:53:09.52 .net
今風に言えばデュアルコア・・・
346:ナイコンさん
11/09/16 06:55:11.27 .net
FM-7も今風に言えばデュアルコアだったのか
347:ナイコンさん
11/09/16 06:59:27.82 .net
NEWSの大抵の機種も今風に言えばデュアルコアですね
348:ナイコンさん
11/09/16 06:59:34.11 .net
Q. FM-8の場合はどうなのでしょう？
A. はい。今風に言えばデュアルコアになります。
349:ナイコンさん
11/09/16 07:23:06.55 .net
いくらなんでも8bit CPU2つ並べが内部32bit CPUより速いという（へ）理屈はねーよ
メインで動くのは1つなんだぜ
＞今風に言えばデュアルコア・・・
350:ナイコンさん
11/09/16 07:55:58.84 .net
今風に言えばHyper-Threading Technologyの方が近いカモなｗ
351:ナイコンさん
11/09/16 11:53:52.71 .net
横レスですが…、FMシリーズの演算メイン+画像サブを無理にたとえるなら
むしろ Cell Broadband Engine とか Fusion Processor みたいな
ヘテロ結合(だっけ？)を引合いに出すほうが適切なのでは?
>>349
>いくらなんでも8bit CPU2つ並べが内部32bit CPUより速い
元の「今風に言えば～」は速度の話じゃないと思うから、レスの要点がずれてるかも
そもそも >>344-350 の流れは無意味というかスレのムダ使いのような…
ここは大人しか集まらない場所なんだし、書いてて虚しくないかなぁ?
(つうか、面白いと思ってるのが不思議)
352:ナイコンさん
11/09/16 12:01:07.07 .net
え? 面白いよ?
353:351
11/09/16 12:04:15.26 .net
これでも見て気分転換してください ＞ OS-9:愛好家の皆さん
URLﾘﾝｸ(stat.ameba.jp)
354:ナイコンさん
11/09/16 12:11:27.85 .net
>>342-343みたいなトンチンカンな書き込みに、
>MC68Kはクロック当りのIPC値が低いのでカーネルをアセンブラで書いても遅いのではないかと。
「クロック当りのIPC値」? 馬から落ちて落馬した、みたいな言い方だなﾜﾛﾀ
「カーネルをアセンブラで書いても遅い」? 当時のコンパイラが吐くコードの品質知ってて言ってんの?
等といちいち突っ込んでもツマランし、いいんでないの。
355:ナイコンさん
11/09/16 12:37:00.25 .net
>>342
>MC68K採用した他のOSでも同時にマルチプロセスを起動すれは極端に遅くなります。
>FM11は今風に言えばデュアルコアであった為にストレス無くOS9が動いた可能性が大きい。
>だからこそUNIX-WSメーカーはRISCへ移行したのです。MACやNEWS等の国内を含め。
OS-9がRTOSって知ってる? RTOSとUNIXは性質が違うって分かってる?
356:ナイコンさん
11/09/16 12:52:27.10 .net
342=343=351か
からかわれるのが不満なら下らないこと書くなよ。
357:ナイコンさん
11/09/16 13:03:29.72 .net
>>342
>FM11は今風に言えばデュアルコアであった為にストレス無くOS9が動いた可能性が大きい。
>>351
>むしろ Cell Broadband Engine とか Fusion Processor みたいな
>ヘテロ結合(だっけ？)を引合いに出すほうが適切なのでは?
プロセッサがどうこう言う前にバスの概念理解した方いいぞ
358:ナイコンさん
11/09/16 13:06:12.70 .net
6809の話題が盛んな頃、クロックの位相を反転させて同一バスにMPUを二つぶら下げる
なんて話はよく耳にしたけど、実際そういう実装した製品て何かあったのカナ。
359:351
11/09/16 13:43:22.19 .net
>>356
なんでも自演決め付けするのが、この板の一部の人(?)の悪いクセですね
>>342-343 さんとは別人ですよ。
前回、自分がカキコしたのは >>330 その前は >>232
自分は「陰湿な揚げ足取り」とか「大人気ない叩きあい」とかを長々と続けて
(時には「下ネタ」で流れを潰しにかかったりw)そういう雰囲気が嫌いなだけです。
他の人の書き込みが間違ってると思ったら、簡潔にそれを指摘すればいいだけだし
思い違い・勘違いのレスの中から、貴重なウンチクや昔の業界話を拾えるかも
しれないし、そう思うからこそこの板に常駐してるわけで…
他の板にならって、無理に斜に構えたレスや、殺伐感を演出したりする必要は
まったくないと思う
360:ナイコンさん
11/09/16 13:52:44.65 .net
>>359
で、バスの概念は理解できたかな?
361:351
11/09/16 13:53:11.94 .net
>>357
それもわかってるつもり(一応は?)。そもそも >>342 がバスとかの話を抜きにして
ざっくりとデュアルコアにたとえて、さらに別の人がハイパースレッドとか
言い出したから、それを言うならヘテロのほうがまだ良いんじゃないのかな?と思っただけ。
つうか、このレベルで言い争うのはやっぱ不毛だなぁ
(皆さん必死になりすぎだと思う、マジで血圧によくない、自分も含む)
362:ナイコンさん
11/09/16 13:56:19.10 .net
>>359
>他の人の書き込みが間違ってると思ったら、簡潔にそれを指摘すればいいだけだし
>>342-343の書き込みに対して「簡潔にそれを指摘」って無理な話だろ。言ってることほぼデタラメなんだから。
363:ナイコンさん
11/09/16 13:59:26.95 .net
>>361
>それを言うならヘテロのほうがまだ良いんじゃないのかな?と思っただけ。
「思い違い・勘違いのレスの中から、貴重なウンチクや昔の業界話を拾えるかも
しれないし、そう思うからこそこの板に常駐してる」人が何故技術的に出鱈目な
話をするの?
364:351
11/09/16 14:10:04.99 .net
ていうか発端は >>336 だよね? 自分は貧乏学生だったので FM-11もX68Kも買えず
単なる推測でしかないんだけど、>>336 氏が「遅く感じた」のは、OS-9の独特の
テキスト・タイリング式(?)マルチウィンドウを、FM-11はテキストVRAMで実行して
いっぽうX68Kのほうは、ビットマップ上にテキストも展開するからかも、とか思った。
(この話題もいつも荒れる種らしいので、あまり深く追及はしないw)
365:ナイコンさん
11/09/16 14:46:38.61 .net
>>364
>ていうか発端は >>336 だよね?
ここまで横道に逸れてんのは>>342-343と>>351の所為だろ。
366:ナイコンさん
11/09/16 14:59:08.47 .net
>>364
責任転換失敗！！
カコワルーイよ
367:ナイコンさん
11/09/16 20:47:04.14 .net
>>351
「Airお手」じゃないじゃん！
368:ナイコンさん
11/09/17 11:43:06.67 .net
os9/6809とos9/68000は同じであるが、違ってもいる
両方ともにアセンブラで記述されている。os9000はCコンパイラ
6809が64kbyteのメモリー空間、68000が16Mbyteのメモリー空間で大きく違う。
os9/68000の動きがモッタリして遅い、これは感覚的であって処理速度とは違う。
要因がひとつでなく多くの組合せでなっているのだとおもう
os9/68000の設計方針が違ってきている、
unixを大いに意識してunixからの移植が出来るように配慮される
また、モジュールチェックのCRCも厳密になったり、
ファイルサイズも２倍以上になっている。
軽快なos9/6809をそのままの形で68000へ移植するのもおもしろうである
369:ナイコンさん
11/09/17 11:45:10.63 .net
シャープx68000の話はまた別である、
全体がそれほど速くないしWindowシステムも違う。
os9が優位性を発揮できるのはLANの複数のPCを束ねてﾃﾞｰﾀｰﾍﾞｰｽｻｰﾊﾞｰとして使うときです。
4台くらいのパソコンをLAN接続しデータを共有すること。
当時として格安で実現できた。
当時はBBSホストとして使われるくらいであった。
370:ナイコンさん
11/09/17 12:24:49.10 .net
68ｋ版は単にWindowシステムだからだろ
371:ナイコンさん
11/09/17 19:49:16.48 .net
>>368 >>369
結局何の説明にもなってないじゃん。
372:ナイコンさん
11/09/17 19:59:24.71 .net
>>358
英国Dragon Data社の陽の目を見なかったマシン Dragon Beta(128) が、
同一バスに2つのMC68B09Eをつなげていた。
一方の68B09はDMA専用として動作していた。68B44を使えば済むのにね。
(将来的には何か他の用途に使うつもりもあったのかもしれんが)
なので、量産機ではそういう変な構成のは無いと思う。
373:ナイコンさん
11/09/18 02:23:21.44 .net
>>372
> (将来的には何か他の用途に使うつもりもあったのかもしれんが)
デュアルプロセッサ対応のOS-9があったら、面白かっただろうに。
374:ナイコンさん
11/09/18 07:55:31.29 .net
>「クロック当りのIPC値」? 馬から落ちて落馬した、みたいな言い方だなﾜﾛﾀ
そうですよ。モトローラは元々半導体屋であってCPUアーキテクトではない。68Kの同じ間違いを
MC88Kでも踏んだ。歴史が証明しているでしょう。
ゲーム基盤は古くはロジックICで組まれていたのです。それがマイコン時代となりロジック置き換え市場を狙って
6809が企画設計されたのです。16bit世代ではミニコンの設計をそのまま借用したからこそ設計に優位性が現われた。
しかし会社としてCPUアーキテクトではないのでそれ以上ではないのです。
MC88Kでも同じ間違いをし、ミニコンのデータゼネラルは88Kを採用したが故に同じように経営危機に陥りました。
SPARC/POWER他のマシンは自社設計です。ゲーム機ですらRISC一色でした。PSはSONYのNEWS関係者が関わっている事もMIPSの要因でしょう。
375:ナイコンさん
11/09/18 08:15:14.24 .net
筋金入りのCPUアーキテクトは、IntelやARMではないでしょうか。
SMPよりは、場合によっては非対称型の方が有効です。今でも有効です。例えばFPUは形を変えた非対称SMPです。
I/O部分に割り当てる事は昔から汎用機で行なわれていたし、今の携帯はSH+ARMのASMPも存在する。
SMPはOMRONのRUNA等がありましたが。
376:ナイコンさん
11/09/18 08:31:22.40 .net
>「カーネルをアセンブラで書いても遅い」? 当時のコンパイラが吐くコードの品質知ってて言ってんの?
Cコンパイラの出来不出来言うなら、当時UNIXはC(BCPL)で書かれていたし、
私の知っているOSはBCPLで書かれている事を知っています。
むしろMC68KはCなどの高級言語に向いた設計のはずです。X68KもCコンパイラが用意されていたはずです。
いち早くコンパイラが用意された事とMC68Kであった事は無関係ではない。
膨大なカーネルソースを呼んだ事有る人なら判りますが、C言語で記述する事は必ずしもデメリットではない。
それよりMIPS/Mhzの比があまりにも低いので、そのような小手先のテクニックは意味が無いといっているのです。
MC68K-8Mhz=0.125,今のRISCなら1Mhz/MIPSなのでこの値が1なのです。
377:ナイコンさん
11/09/18 08:40:51.62 .net
何を言いたいかというと、MC68Kでは0.125ですから、仮にクロックアップしても
37.5MIPSにしかならない。RISCなら軽く300MIPS出るのです。
MC68Kのような設計でオーバークロックがどれほど無意味か計算すれば直ぐ予想可能なのです。
当時Celeronでカジュアルなオーバークロックが流行ったのは、Celeron(P6アーキテクチャ)自体が内部RISCだったからです。
だからこそクロックアップに対して性能が追従するのです。
ついでに言えばX68Kの5年間維持する宣言は駄目です。互換性に言い換えるべきでした。
5年という期間をムーアの法則に従い考えてください。横軸は年ですが縦軸は対数(LOG)です。
ムーアの法則のグラフは直線で性能を直接指示するものではありませんが、スケールがLOGなので、
たった五年というスパンで取り返しの付かない性能格差を生じる可能性が高かった。
378:ナイコンさん
11/09/18 13:17:42.87 .net
>>374
>>「クロック当りのIPC値」? 馬から落ちて落馬した、みたいな言い方だなﾜﾛﾀ
>
>そうですよ。モトローラは元々半導体屋であってCPUアーキテクトではない。68Kの同じ間違いを
分かってねぇなぁ。アホか。
クロック当りのIPC値
↓
クロック当りのInstructions Per Clock値
↓
クロック当りのクロックあたり命令実行数値
って笑われてんだろ。
379:ナイコンさん
11/09/18 13:43:15.84 .net
>>374
>モトローラは元々半導体屋であって
社名の通りカーラジオ屋だろ。
CPUアーキテクトではない。
インテルもCPUアーキテクトじゃなくてメモリ屋な。
380:ナイコンさん
11/09/18 14:02:04.82 .net
>>374
>そうですよ。モトローラは元々半導体屋であってCPUアーキテクトではない。68Kの同じ間違いを
>MC88Kでも踏んだ。歴史が証明しているでしょう。
ソフトウェアから見たアーキテクチャが重要ではないことはインテルが証明してるな。
68kが終了した原因は、モトローラ自身が適切なアップグレードパスを用意せず、88kに切り替えようとしたことだろう。
88kの失敗の原因は、コスト高と市場投入のタイミングだろう。68kとは随分状況も違うと思うが。
381:ナイコンさん
11/09/18 14:50:14.26 .net
>>374
>そうですよ。モトローラは元々半導体屋であってCPUアーキテクトではない。68Kの同じ間違いを
>MC88Kでも踏んだ。歴史が証明しているでしょう。
88kのアーキテクチャ上の欠点て何? 具体的に指摘してみ?
>>375
>SMPはOMRONのRUNA等がありましたが。
LUNAな。マルチプロセッサ構成を前提にデザインされた88kの優位さが前面に出てた機種だったな。
382:ナイコンさん
11/09/18 15:12:02.68 .net
>>377
>何を言いたいかというと、MC68Kでは0.125ですから、仮にクロックアップしても
>37.5MIPSにしかならない。RISCなら軽く300MIPS出るのです。
>MC68Kのような設計でオーバークロックがどれほど無意味か計算すれば直ぐ予想可能なのです。
インテルみたいに見た目68kで内部RISCのプロセッサ用意できれば良かったねってだけの話じゃん
>当時Celeronでカジュアルなオーバークロックが流行ったのは、Celeron(P6アーキテクチャ)自体が内部RISCだったからです。
>だからこそクロックアップに対して性能が追従するのです。
上位製品と同じ技術で製造してたから低く設定されたクロックに対してマージンが大きかったってだけの話じゃん。
内部RISCって意味分かって言ってる?
383:ナイコンさん
11/09/18 15:15:48.08 .net
>>376
>Cコンパイラの出来不出来言うなら、当時UNIXはC(BCPL)で書かれていたし、
UNIXは当初アセンブリ言語で書かれ、後にCに書き直された筈で、BCPLで実装された時期はないと思う。
384:ナイコンさん
11/09/18 15:20:16.15 .net
>>375
>SMPよりは、場合によっては非対称型の方が有効です。今でも有効です。例えばFPUは形を変えた非対称SMPです。
いまどきは87命令よかSSEが使われてるけど?
385:ナイコンさん
11/09/18 15:22:56.10 .net
>>376
>MC68K-8Mhz=0.125,今のRISCなら1Mhz/MIPSなのでこの値が1なのです。
今どきのプロセッサだとマルチコアだのハイパースレディングだのの技術で平気で1切ってるよ。
386:ナイコンさん
11/09/18 22:15:46.99 .net
>>377
>ついでに言えばX68Kの5年間維持する宣言は駄目です。互換性に言い換えるべきでした。
>5年という期間をムーアの法則に従い考えてください。横軸は年ですが縦軸は対数(LOG)です。
>ムーアの法則のグラフは直線で性能を直接指示するものではありませんが、スケールがLOGなので、
>たった五年というスパンで取り返しの付かない性能格差を生じる可能性が高かった。
ライバル機と思われるPC98も、X68030出た時点で一部のユーザーがDOSエクステンダを使って
32bitアプリを動かしてるとかそんな状況じゃなかったっけ? 「取り返しの付かない性能格差」って何?
387:ナイコンさん
11/09/18 22:26:20.46 .net
>>377
>何を言いたいかというと、MC68Kでは0.125ですから、仮にクロックアップしても
>37.5MIPSにしかならない。RISCなら軽く300MIPS出るのです。
>MC68Kのような設計でオーバークロックがどれほど無意味か計算すれば直ぐ予想可能なのです。
68kシリーズ最初の68000と、高速化のためにいろいろ細工されてる後継プロセッサじゃ
クロック当たりの命令実行数も結構違う筈だけどな。
URLﾘﾝｸ(en.wikipedia.org)
>Motorola 68000 1 MIPS at 8 MHz(Not Dhrystone) 0.1 0.1 1979
>Motorola 68020 4 MIPS at 20 MHz 0.2 0.2 1984
>Motorola 68030 11 MIPS at 33 MHz 0.3 0.3 1987
>Motorola 68040 44 MIPS at 40 MHz 1.1 1.1 1990
>Motorola 68060 88 MIPS at 66 MHz 1.33 1.33 1994
388:ナイコンさん
11/09/18 22:48:20.86 .net
>>376
68000が8MHzで動いてた頃って他に大したライバルプロセッサもなかったじゃん。何言ってんの?
389:ナイコンさん
11/09/18 23:27:36.77 .net
342=343=368=369=374=375=376=377
いい加減なことばかり書いて荒らすな。
390:ナイコンさん
11/09/19 02:15:32.16 .net
猫に小判、DOSにメモリと当時言われていた。。。68000は、80386が出現するまではインテルの比較の対象ではなかったよ。。。
MSがWindowsを商用的に投入したのは386の普及を待ってからの話。
391:ナイコンさん
11/09/19 02:23:43.27 .net
結局、ＧＵＩ、そこまで行かなくてもグラフィクスをＰＣで扱おうとしたら、68000しかなかった。
86じゃ一度に素直に扱えるメモリが６４Ｋバイトで１ドット２５６色で８千ドット（９０×９０の矩形程度）の広さしかなかった。
初代マックが最初からフルグラフィクス（白黒だけど）だったのは68000を採用したからとも言える。。。
Windows95が出現するまでの日本におけるマックの黄金時代というのは68Kが一度に扱えるメモリが16MB以上あった事に由来する。。。
まあ、アップルはあぽんと言われるとおり、そのメモリを８Ｍｂしか使わないように設計して自分で自分の首をしめたのだがモトローラのせいではない。
このあたり、スティーブ・ジョブスがＰＣのことをよく知らなかったって説明になると思うな。
392:ナイコンさん
11/09/19 02:39:24.44 .net
>グラフィクスをＰＣで扱おうとしたら、68000しかなかった。
98が出てまもなくしたらカノープスがグラフィックボード出してたけどね
86のセグメントなんてプログラムを作る縛りにはならないよ
>スティーブ・ジョブスがＰＣのことをよく知らなかった
君もネ
393:ナイコンさん
11/09/19 02:59:32.71 .net
>>391
>まあ、アップルはあぽんと言われるとおり、そのメモリを８Ｍｂしか使わないように設計して自分で自分の首をしめたのだがモトローラのせいではない。
OSだかToolboxだかでアドレスレジスタの上の方使ってたって件? 16MBじゃなかったっけ?
>このあたり、スティーブ・ジョブスがＰＣのことをよく知らなかったって説明になると思うな。
あいつがコード書いたり細かい仕様決めてた訳じゃないだろ。
394:ナイコンさん
11/09/19 03:23:03.90 .net
>>392
>98が出てまもなくしたらカノープスがグラフィックボード出してたけどね
PC-9801出たのが1982年の終わりの方で、カノープスの創業がその次の年だけど
そんなもん出してたっけ?
社歴見てもそれらしいの載ってないな。
URLﾘﾝｸ(pro.grassvalley.jp)
サピエンスがフレームバッファ出してたのも80年代後半だな。
URLﾘﾝｸ(www.sp3.com)
395:ナイコンさん
11/09/19 04:11:03.39 .net
>>394
1993 グラフィックアクセラレータボード「Power Windowシリーズ」
396:ナイコンさん
11/09/19 04:27:27.49 .net
>>395
「98が出てまもなくしたら」
397:ナイコンさん
11/09/19 04:36:36.92 .net
>>392
>>グラフィクスをＰＣで扱おうとしたら、68000しかなかった。
>98が出てまもなくしたらカノープスがグラフィックボード出してたけどね
>86のセグメントなんてプログラムを作る縛りにはならないよ
「86のセグメントなんて～」ということは、そのカノープスのグラフィックボードは
8086のメモリ空間にグラフィックメモリを配置していたという理解で良い?
解像度と色数どんだけあったか知らんけど、メモリ空間圧迫しすぎじゃね?
どの道行き詰る構造だろ。
398:ナイコンさん
11/09/19 04:41:54.57 .net
そろそろスレ違いの書き込みやめませんか。
ここはOS-9のスレなんで。
399:ナイコンさん
11/09/19 04:42:57.56 .net
そーいやPC-98XAとかのハイレゾ機って、1120x750x16色のグラフィック載ってたけど、
どーゆー構造だったんだろ?
PC-9801と同じ構造だったら1プレーン100KB超えるし正気の設計者なら4プレーンとか
並べて配置しないよな。バンク切り替えでもしてたんだろーか?
400:ナイコンさん
11/09/19 04:44:29.11 .net
>>398
たまたま話題が少し横道に逸れてるだけ。OS-9の話題がないだけ。
401:ナイコンさん
11/09/19 04:56:53.31 .net
いい加減すぎるな。
>>390
> 68000は、80386が出現するまではインテルの比較の対象ではなかったよ。。。
これは正しい。
> MSがWindowsを商用的に投入したのは386の普及を待ってからの話。
これは間違い。最初にWindowsを商用的に投入したのは1985のWindows1.0から。
>>391
> 結局、ＧＵＩ、そこまで行かなくてもグラフィクスをＰＣで扱おうとしたら、68000しかなかった。
1981 CGA 640x200 2色, 320x200 4色
1981 FM-8 640×200 8色
1982 FM11 640x400 8/16色 2画面
1984 EGA 640x350 64色中16色
1984 Macintosh128k 512x384 2色
Mac128k登場以前から、我等6809に8086でMac128kのグラフィクスを超えるPCはゴロゴロしていた。
よって、「グラフィクスなら68000しかなかった」の主張は間違っている。
86のセグメントも同様、256色が無い時代にセグメントの壁が問題との指摘も待ちがっている。
初代マックであるMac128kがGUI指向だったのは、Lisaを受け継いだだけ。
そのLisaも、Altoの影響を受けただけで、68kだったから…の主張は間違っている。
> まあ、アップルはあぽんと言われるとおり、そのメモリを８Ｍｂしか使わないように設計して
別に珍しい設計ではない。
WindowsNT、当初は半々のアプリ2GB、カーネル2GBの設計だった。
いつからか知らないけど、現在のWindowsXPでは3GBと1GBに変更された。
IBM PC、現在ではメインメモリは640kBって事になっているが、これは後から拡張された結果。
当初は512kBであり、グラフィックスメモリのギリギリまで拡張したから半端な640kBになった。
さらに遡れば、FM-8はRAMが32kB、ROMが32kB。
歴史的に半分半分にする設計は珍しくない。
402:ナイコンさん
11/09/19 05:02:20.07 .net
>>401
> 歴史的に半分半分にする設計は珍しくない。
余談だが、珍しい設計はFM-11/16/FMR。
実メモリをどの位詰めたかしらないが、FM-11ではグラフィックスをサブCPUに任せた関係で、
8088のメインメモリ領域は900kBを超えていた。
(確か)FM-16ではダイレクトパスが搭載されたため、メインメモリは700kB超に制限を受けた覚えがある。
これはそのままFMRに受け継がれたが、FM-11/16/FMRは半々でない珍しい設計だった。
403:ナイコンさん
11/09/19 05:06:45.73 .net
>>397>>399
おまえら、VGAの構造を知らんのか?
404:ナイコンさん
11/09/19 05:08:21.81 .net
>>401
>IBM PC、現在ではメインメモリは640kBって事になっているが、これは後から拡張された結果。
>当初は512kBであり、グラフィックスメモリのギリギリまで拡張したから半端な640kBになった。
最初のIBM PCは上限が256KB
405:ナイコンさん
11/09/19 05:09:08.82 .net
>>403
VGAの話なんてしてないし
406:ナイコンさん
11/09/19 05:10:05.39 .net
少なくともPC-98の話題は横道どころじゃないな。
407:ナイコンさん
11/09/19 05:15:05.77 .net
>少なくともPC-98の話題は横道どころじゃないな。
こいつか。
392 ：ナイコンさん：2011/09/19(月) 02:39:24.44
>グラフィクスをＰＣで扱おうとしたら、68000しかなかった。
98が出てまもなくしたらカノープスがグラフィックボード出してたけどね
86のセグメントなんてプログラムを作る縛りにはならないよ
>スティーブ・ジョブスがＰＣのことをよく知らなかった
君もネ
408:ナイコンさん
11/09/19 05:18:08.22 .net
>>401
>> 結局、ＧＵＩ、そこまで行かなくてもグラフィクスをＰＣで扱おうとしたら、68000しかなかった。
> 1981 CGA 640x200 2色, 320x200 4色
> 1981 FM-8 640×200 8色
> 1982 FM11 640x400 8/16色 2画面
> 1984 EGA 640x350 64色中16色
> 1984 Macintosh128k 512x384 2色
>Mac128k登場以前から、我等6809に8086でMac128kのグラフィクスを超えるPCはゴロゴロしていた。
>よって、「グラフィクスなら68000しかなかった」の主張は間違っている。
GUI前提なら間違いでもないだろ。
409:ナイコンさん
11/09/19 05:31:05.85 .net
>>404
> 最初のIBM PCは上限が256KB
それは実装されていたメモリの話し。512kBはアーキテクチャの話し。
>>406
> 少なくともPC-98の話題は横道どころじゃないな。
PC-98はIBM PCのパクリだし。
410:ナイコンさん
11/09/19 05:41:18.62 .net
>>409
>512kBはアーキテクチャの話し。
IBM PCのパクリであるPC-98が初代から最大640KBだったことを考えると嘘くさい話だな。
URLﾘﾝｸ(oldnewstudio.jp)
411:ナイコンさん
11/09/19 06:20:26.93 .net
>>410 ggrks
412:ナイコンさん
11/09/19 09:30:15.72 .net
そういや、今出てきた各機種ともオプションボードで OS-9/68000 を使えたな。
IBM-PC AT 68020カード：OS-9/68020
PC-9801 68000カード：OS-9/68000
FM-11 68000カードまたは68008カード：OS-9/68000
FM-16β 68000カード：OS-9/68000
FMR-50/60/70 68020カード：OS-9/68020
413:ナイコンさん
11/09/19 09:53:26.69 .net
やっぱり98信者が僻んでるだけだったか
どこででも顕示欲を発揮するよな
414:ナイコンさん
11/09/19 10:11:24.83 .net
URLﾘﾝｸ(www1.axfc.net)
当時のOS-9/68000の広告、１９８７年頃
415:ナイコンさん
11/09/19 12:06:07.96 .net
>>391
またお前か。よくもいい加減なことばかり書けるな。
68000のアドレスバスは24bitだったため、最大16MBのメモリしか
扱えない。当時のToolboxは上位1bitをハンドルのロックのON/OFFに
割り当てていたので最大8MBになった。つまり8MBは古い68000と
互換性を取るためのものだ。
Mac、というかLisaが68000を採用したのはQuickDrawを開発した
ビル・アトキンソンが各種CPUをテストした結果68000しか無理と
判断したため。各種CPUの中にはリニアで24bit以上のメモリ空間を
扱えるものもあった。
ジョブズがいた頃のMacは512KB。
416:ナイコンさん
11/09/19 15:05:09.04 .net
で、今OS-9使っている奴っているのか
過去にしても怪しいよな
417:ナイコンさん
11/09/19 15:15:01.60 .net
>>415
>68000のアドレスバスは24bitだったため、最大16MBのメモリしか
>扱えない。
アドレスレジスタは32ビットあるから上位8ビットはなんかに使ってたとして、
>当時のToolboxは上位1bitをハンドルのロックのON/OFFに
>割り当てていたので最大8MBになった。つまり8MBは古い68000と
>互換性を取るためのものだ。
更に1ビットをハンドルのロックに使ってたから8MBしか使えなかったという理解で合ってる?
上位8ビットは何に使ってたの?
418:ナイコンさん
11/09/19 16:52:28.18 .net
>>415
>68000のアドレスバスは24bitだったため、最大16MBのメモリしか
>扱えない。当時のToolboxは上位1bitをハンドルのロックのON/OFFに
>割り当てていたので最大8MBになった。つまり8MBは古い68000と
>互換性を取るためのものだ。
ホントかぁ? Wikipediaには違うこと書いてあるがまだ納得する内容なんだが。
URLﾘﾝｸ(en.wikipedia.org)
419:ナイコンさん
11/09/20 00:07:28.16 .net
>>410
わりぃ、俺もいい加減だった(汗
>>401
> これは後から拡張された結果。当初は512kBであり、
記憶違いで、最初から640kBが正解。
お詫びにIBM PC(IBM5150)のマニュアルを示すよ。
これが今や伝説になっている「回路図とBIOSソースが記載されていた」マニュアル。
URLﾘﾝｸ(maben.homeip.net)
420:ナイコンさん
11/09/20 02:34:01.83 .net
>>419
マニュアル見られない
しっかりしてくれよ
421:ナイコンさん
11/09/20 06:16:59.01 .net
回線が細いからな。
IBM PC/XT(IBM5160)のマニュアル
URLﾘﾝｸ(www.retroarchive.org)
422:ナイコンさん
11/09/20 10:02:05.53 .net
>>417
上位8bitは使われていたんだったかな？System GlobalにLo3Bytesというのが
あって、中身は0xffffffffffff。これでマスクするように推奨されていたので
上位8bitはシステムで使っていたのかもしれない。handleのlock/unlockも
この8bitの中でやってたのだったかも。
古い開発本には詳しく書いてあったような気もするが、今さら探すのも面倒なので
ここまで。
423:ナイコンさん
11/09/20 10:10:39.40 .net
そういえば68000と68010は奇数アドレスにfetchするとアドレス・エラー例外を
発生するんだったな。通常はコンパイラが偶数アドレスに置くようになってるけど
構造体でアライメントをバイト整列にしてしまうと、たちまちエラー。
初期のMacでバス・エラーで落ちる原因の多くがアドレス・エラー例外だった。
424:ナイコンさん
11/09/20 10:26:41.11 .net
>>422
間違えたLo3Bytesは0xffffffだった。0xffffffffffffじゃ48bitだな。
425:ナイコンさん
11/09/20 23:40:45.50 .net
あれってアドレスとデータのレジスタ互換のために32Bitになってるだけじゃなかった?
だから上位8Bitは何が入ってても実際のアドレスには影響しなかったと思ったけど。
でも一部のソフト(OS)では逆手にとってなんかに使ってたって聞いたことがあるような。
426:ナイコンさん
11/09/21 00:12:52.57 .net
>あれってアドレスとデータのレジスタ互換のために32Bitになってるだけじゃなかった?
違うよ。
427:ナイコンさん
11/09/21 00:21:09.93 .net
68000版はBASIC09使えるの？
428:ナイコンさん
11/09/21 00:28:52.52 .net
>>427
>>414
429:ナイコンさん
11/09/21 00:48:10.01 .net
OS-9/68000をOSKと呼び、BASIC09も同時に移植された。
BASIC09
URLﾘﾝｸ(www1.axfc.net)
430:ナイコンさん
11/09/21 02:46:54.05 .net
>>409
OS-9の話の横道どころじゃないな、って意味なんだけど？
431:ナイコンさん
11/09/21 03:14:26.24 .net
OS-9の動作プラットホームにPC-98があったなら仕方がない
432:ナイコンさん
11/09/21 21:38:36.61 .net
>>431
あった「なら」ね。機種比較に出されてるだけでOS比較で出されてないよな。
とりあえずOS-9 for PC-98が存在するなら出典書いてくれ。
少なくともここまでに記述されていない。
433:432
11/09/21 21:40:08.89 .net
おっと書き忘れ。ググっても出てこないんで、出典ヨロ>>431
434:ナイコンさん
11/09/21 21:50:24.87 .net
>>433
>>412
435:ナイコンさん
11/09/21 22:47:04.11 .net
PC-98にSmall-Talkがあったのは聞いたことある
持ってた人は誰もいないだろな
ところでX68000にもNIFTYでSmall-Talkの実行ファイルがあったけどあれは何だったんだろう？
436:ナイコンさん
11/09/22 00:21:22.24 .net
SmallTalk/V？ mac用なら会社で買ったな。まだ残ってる。
437:ナイコンさん
11/09/22 09:49:18.38 .net
テキストベースのLittle SmalltalkやGNU Smalltalkもあるのでなんとも
438:ナイコンさん
11/09/23 01:15:19.41 .net
>>434
むむむ。"PC-9801 OS-9"で検索しても
それっぽいのが見当たらないと思ってたら、
WikipediaのOS-9項目にあったのか。
PC-98に68000ボードがでてたとは…。
これはあきらかに私の調査不足だな…失礼した。
439:ナイコンさん
11/09/23 01:31:06.89 .net
OS-9 for PC-9801
URLﾘﾝｸ(www1.axfc.net)
440:ナイコンさん
11/09/23 02:54:02.97 .net
>>439
懐かしいなぁ、FMR版がとっても欲しかった。
モチ、会社の金で。未遂に終わったけどw
あと、今でもOS-9を扱っているのね。
URLﾘﾝｸ(www.forks.co.jp)
441:ナイコンさん
11/09/23 04:51:13.24 .net
>>440
この会社まだあったのね。
442:ナイコンさん
11/09/23 12:28:57.23 .net
Forksか。広告で見ただけど、あったね。
443:ナイコンさん
11/09/24 22:08:50.86 .net
>>429
Ver.2.0からMW-BASICに改名した。
なんか、モトローラと商標の関係でもめたらしい。
444:ナイコンさん
11/10/03 23:40:37.75 .net
すまんが、FM-11の68000カードのメインメモリってどうアクセスしてたか教えてくれ。
445:ナイコンさん
11/10/04 02:12:09.96 .net
共有メモリ、アドレスはシラン
446:ナイコンさん
11/10/24 22:12:45.61 .net
OS-9スレで6502の話を力強くされても。
447:ナイコンさん
11/10/24 22:18:46.41 .net
OS-9
448:ナイコンさん
11/10/26 01:56:51.10 .net
>>446
どれが?
449:ナイコンさん
11/10/29 15:43:22.59 .net
もしや >>446はMacが6502で動いていると思っていたのではあるまいか
450:ナイコンさん
11/10/29 17:44:25.23 .net
もともと Macintosh用の Microware OS-9/68000 が出てたそうだから(ややこしい)
やはり Apple が Microware と訴訟和解・遠慮して、MacOS8 の次は
MacOSX にスキップすべきだったと思うなぁ
>>449 の説にも一理あると感じたけど、アンカが >>446 向けなのは変じゃない?
とにかく >>266 によると ARM用の OS-9 も出てるらしいので
まぁARMの話題は許すとしても、ここまでの流れで 6502 と ARM は
ほとんど無関係という結論だそうなので、6502 はスレ違いでFAかと
451:ナイコンさん
11/10/29 19:03:33.76 .net
>>450
> とにかく >>266 によると ARM用の OS-9 も出てるらしいので
おもわず6502用のOS-9が無いか、ググってしまったw
ところで、ColorComputerをFPGA上に再現している人が居るんだな。
URLﾘﾝｸ(8littlebits.wordpress.com)
この上でNOS9走らせたら面白そうだとオモタ
452:ナイコンさん
11/10/29 19:24:23.77 .net
>>450
ARMが6502を参考に開発されたのは有名な話
453:ナイコンさん
11/10/29 19:37:47.48 .net
>>450
$7E JMP >>242 ; ロングジャンプして、ここまでの流れを復習せよ
以下、無限ループw
454:ナイコンさん
11/10/29 22:11:54.28 .net
HALT
455:ナイコンさん
11/10/30 00:04:23.13 .net
よくも悪くも今音楽やってる人はビートルズの影響を受けてるわけだけど
じゃぁビートルズの進化かというと別だろ。237のおかしいのはそこ。
456:ナイコンさん
11/10/30 00:18:50.14 .net
>>270
>Wikipedia酷いな。
>MOS 6502 - Wikipedia
>URLﾘﾝｸ(ja.wikipedia.org)
>> なおARM (Acorn RISC Machine) は、6502の延長として設計されており、6502との
>> 共通点が見られる。
書き換わってたｗ
URLﾘﾝｸ(ja.wikipedia.org)
> なお、ARM (Acorn RISC Machine) の設計は6502を参考に行われたとされることが
> あるが、ARMが6502を参考にしたのはアーキテクチャではなく、シンプルで扱い易い
> CPUというコンセプトであり、ARMと6502のアーキテクチャ自体は大きく異なっている。
> また、ARMの命令セットを設計したSophie Wilsonは、6502とARMにはほとんど共通点が
> ないと述べている[1]。
457:ナイコンさん
11/10/30 10:03:46.38 .net
>453
jmp だったけ？
bra じゃなかった？
昔のことなので記憶が…
458:ナイコンさん
11/10/30 10:44:16.21 .net
>>454
隊長!! HALT命令が効きません!! CPUが暴走してます!!
459:ナイコンさん
11/10/30 11:12:13.01 .net
>>457
$20 BRA ; ±7bit で相対分岐
$16 LBRA ; 16bit で相対分岐
$0E JMP <$nn ; ダイレクト・アドレッシングで絶対分岐
$6E JMP ea ; インデックス等のEffectiveAddressで絶対分岐
$7E JMP $nnnn ; エクステンドで絶対分岐
ポジションインディペンデント強制のOS-9だとJMPは禁止かも
460:ナイコンさん
11/10/31 10:28:08.75 .net
ポジションインディペンデント、マルチタスク、リエントラント対応は必須。
461:ナイコンさん
11/10/31 23:45:48.78 .net
>>459
LBRAは片方向だけなの?
462:ナイコンさん
11/11/01 01:16:38.66 .net
最初は±15bitって書こうとしたけど、どうせ6809のアドレスは$FFFFを
超えると0に回り込むから、16bitと書いたほうがいいかなと思って(深い意味なし)
463:ナイコンさん
11/11/01 23:21:43.14 .net
>>456
いいことじゃないか。編集してくれた人ありがとう
464:ナイコンさん
11/11/01 23:37:55.83 .net
ARMの項目はまだおかしい。
ARMアーキテクチャ - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
> 命令セットはRISCでありながらもコード密度を重視した設計になっており、
> 手作業による最適化がしやすい特徴的なアーキテクチャを持つ。
465:ナイコンさん
11/11/02 01:06:56.04 .net
ARM って、現行の (Cortex-A9とかの) ～v7までは
User, System, Supervisor, Abort, Undefined, Interupt, FastInterrupt の７つも
例外モードがあって、そのうち５つでは R13,R14,SR(ステータス)が個別裏レジに切替で
さらにFastInterrupt時はR8～R12も裏レジ切替という、異様に裏が多い特殊な複雑さは
なんでかなぁと思ってたけど、もともと25年前の Acorn の要求仕様のためらしい
で、先週発表された 64bit ARM (v8)の新仕様では、ばっさり切替えて４段の例外
(特権Lv)に整理するとのこと。state 切替で、32bit モードになってる時は
Thumb (2バイト命令)も含めて、従来との完全互換を保つため、やはりごちゃごちゃの
ままみたいだけど、64bit state に切替えると、えらくすっきりする印象
URLﾘﾝｸ(pc.watch.impress.co.jp)
32bit版OSはそのまま動くことを保証って書いてあるから OS-9/ARM もたぶんOKだと思うけど
どうせなら OS-9/ARM-64 みたいなのが出たら、OS-9/PowerPC なみに面白いかも
466:ナイコンさん
11/11/03 22:18:43.57 .net
OS-9って今のVer.っていくつ?
まだVer.UPしてるの?
467:ナイコンさん
11/11/03 23:03:28.05 .net
OS-9のバージョンは上がってないんじゃね？
モジュールは更新されてるかもしれないが。
468:ナイコンさん
11/11/26 01:33:02.93 .net
古いけど、こっちにも貼っておくか
URLﾘﾝｸ(www.icdia.co.uk)
469:ナイコンさん
11/12/06 22:56:04.55 .net
拾い上げ
470:ナイコンさん
11/12/11 17:56:44.78 .net
>>468
CDIがどうこうって書いてあるから、6809じゃなくってOSKの方だろ。
471:ほたて
12/02/09 18:41:43.45 .net
>>467
OS-9/x86 V4.9というのを聞いたことがある（３、４年前?）から
V5.?はあるだろう。その位のバージョンでOS-9/ARMもあったはず
今見ると、ラディシス本社のサイトにOS-9はproductとして残ってるけど
アジアの代理店はフリーステーションというQNXの会社になってる。
日本ラディシスは取り扱わなくなったようだ
472:ＦＭファン
12/07/07 20:35:04.28 .net
OS-9のクローン「NitrOS9」のレベル２（6309版）が
COCO3のエミュレータ「VCC」で動きました。
VCCを起動すると、ROMのBASICが起動します。
HDDモジュール(DLL）を読み込み「NitrOS9.vhd」を設定します。
このvhdは0から255に分割されています。dir 255がNitrOS-9。
「dos 254」と入力後「dir」で、BASIC記述のプログラムが表示。
「load "link"」「run」で、boot disk?を聞いてくるので「255」
と入力。 VCCのconfigのCPU項目を「6309」に設定。
「dos 255」の入力で「NitrOS9 level II 6309版」が起動します。
NitrOS9起動時「time?」などは聞かず（DOS/V設定が反映）/DD:と
表示します。 /d0 /h0が可能ですが、そのまま /DD:dir cmds
などと入力すれば表示します。 dir -e と「-]が必要（68000版同様）
BASIC09は「6309」対応になっています。
vhdファイルは以下のサイトから入手（NitrOS9.vhd、BOOT-FD、OS-9 L-II）
が可能です。
URLﾘﾝｸ(goyim.dyndns.org:8080)
NitrOS9.vhdは132.480KBあります。download時は、ZIPファイルです。
473:ＦＭファン
12/07/08 21:00:33.07 .net
OS-9000（のちにOS-9と改名）X86版のCD-ROM（サンプル）をInstall
しようとしたら、以前の「パスワード」が無効となっていました。
何とかWINDOWS上で動くバージョンがないものか、探していたところ
ありました。以下のサイトから入手出来ます。24MB弱(zip)です。
batファイルを起動すると、選択画面が表示されます。 「2」を選択。
ネットワークも可能で、インターフェース（NE-2000など）を設定します。
URLﾘﾝｸ(lsw.ee.hm.edu)
動きましたら、ご報告を、かきこ、お願いします。ver.4.9です。
474:ＦＭファン
12/07/08 22:22:56.90 .net
<追加>
「２」入力後、画面表示で、入力待ちになったら「ｑ」を入れます。
OS-9/X86のプロンプトが表示されたら「xb」と入力、グラフィックモード
となります。マウスが、この表示画面内のみ有効です。マウスの右ボタン
をクリックすると「menu」が表示します。 この画面を終了するには
「ctrl＋alt」で、異なるマウス・ポインターが表示され、終了が可能と
なります。
475:ＦＭファン
12/07/08 22:37:35.10 .net
<追加>
グラフィックの出来は、すばらしいです。
サンプル（アナログ時計、カレンダーなど）ｘ８６版はスピードも速いです。
ネットワークは、この起動パソコンに対して、ネットワークから「ログイン」
出来て、マルチ・ユーザーが可能な様です。 （未確認）
476:ＦＭファン
12/07/08 23:58:05.24 .net
ＯＳ－９／Ｘ８６を、みんなで便利に使えるように、「知恵」を
出し合いましょう。 わたしも、時間が休日以外にないので、今
から、少し休憩です。 /d0、/md0、/cd0、/r0、などのFORMATや
設定方法、ネットワークの設定、ログインのUSER・DATA設定方法
いろいろ、解らない点が多いです。 FILE MANAGERに説明があり
ます。 １０人位で、考えれば、何とか、なりそうですが。
477:ナイコンさん
12/07/09 01:30:30.96 .net
ライセンス上問題が無いのか？
478:ナイコンさん
12/07/09 01:42:13.12 .net
付記
OS-9/x86は、無償ソフトか？
Radisys/Microwareの不利益になることをOS-9ファンは普通望まないだろう。
（いまだ、OS-9/X68000で遊んでるが、きちんと購入してる）
「使いたいから」とかは理由にならない。
正規のライセンシーを得てやるのであれば気にしないが、
こういうことをやることを、きちんと開発・販売元が認めているのだろうか？
479:ＦＭファン
12/07/09 07:30:56.61 .net
ＯＳ－９／Ｘ８６ですが、ＤＯＷＮＬＯＡＤサイトを、よくご覧になり
ましたか？ 公表されているサイトですし、グラフィックスでは「商用
使用は禁止」の表示があります。ライセンス。フォルダーに詳しい記述
がありますので、お読み下さい。 気になるなら、使わなければいいで
しょう。
480:ＦＭファン
12/07/09 07:54:13.00 .net
ＯＳ－９／Ｘ８６の画面に「ＤＥＭＯ ＳＯＦＴＷＡＲＥ」の表示、ＧＮＵ
ライセンスの説明があります。ソースコードの案内もあります。
481:ＦＭファン
12/07/09 08:22:43.07 .net
ＯＳ－９／Ｘ８６について、以下のサイトに、設定の詳しい説明が
あります。
URLﾘﾝｸ(lsw.ee.hm.edu)
482:ＦＭファン
12/07/09 13:41:40.60 .net
<MICROWAREとのかかわり>
1976-77年頃、米国のコンピュータショウで「RT-68」と「A/BASIC」を
購入。RT-68はMIKBUG互換のACIA用マルチタスク・モニター（ソース付）
A/BASICは6800用のカセット版。（割り込み、マルチタスク記述可能）
これが基礎でOS-9が完成？ A/BASICのOS-9版1.6:1がOS-9（L1、L2）で
使えています。
1981年頃OS-9（L1）のソースコードをマイクロボード社より購入($100）
友人と解析して、秋葉で売っていたＩ／Ｏラボ池上研究所のCPU＋FDC
ボードに移植。移植前は、SS-50バスにGIMIX製#58FDC＋8インチで起動。
当時は、8インチFDDでしたが現在 3.5インチで動いています。
その後、FM-11など使用。25年ほどブランク。XM7で楽しんでいます。
483:ナイコンさん
12/07/09 16:36:47.70 .net
>>482
わーお！
そういう経緯で OS-9 が生まれたというのは初耳です。
いろんな過去があるのですね。
私は FM-11 からの新参ものなので興味深いお話です。
しかし、FM-11 を手放してすでに 20 年？。
使い方を思い出すのに精一杯です。
そういう意味では、情報交換には期待しています。
ただ、こちらから出せる情報がほとんどないのが心苦しいです。
がんばってください。応援しています。