OSASKスレッド Part12
TownsOSというかTownsSHELLはWindows3.1/MacOS9的な協調型マルチタスクな上に標準搭載メモリだと空き領域が非常に厳しくハードリソースの分配管理も不十分
本人に聞かないとわからないが後者的要素を持つ前者だと思う TownsOSそのものはDOSに毛が生えただけ
基本シングルタスクだしGUIもシェルとかアプリが自前でやってた(ライブラリのサポートはあった) あれDOS-SHELLみたいなシェルだったんだ・・・
てっきりWin3.xレベルのウインドウシステムだと思っていた 一応Win3.1レベルには達していると思うが
TownsSHELL非対応の通常アプリを通常起動すると丸ごと終了してしまうという 3.1もそうだった。
エンハンストモードはDOS窓使えたので多少マシだったが。
じゃあ初期のOSASKはTownsOS(Win3.1)に対するOSASK(Win95)辺りを目指してたのかな？
プリエンティブマルチタスクだしウインドウのデザインもよく似てるし
そう考えるとNOWSMART-OSも方向性は似てるね >>351
TOWNS-OSの最初のバージョンは洒落たアナログ時計の奴で、只のアイコンランチャー
次からは純正アプリとGUIを統一したMacのファインダー的なメニュー
V2.1でマルチウインドウに一新して、サイドワークという常駐ミニアプリが可能になって、
EINの中の人辺りが協調型マルチタスクの実験しててそれがシェルアプリに進化したんだけど、
いろいろお約束があってアプリ作るのは難しかったと思う。
んで、件の奴は、それとは別の流れの統合環境アプリだね。
前者はCCIというC言語インタプリタを積んでいるし、後者はF-BASIC386で書かれているから
機能追加する気があるならOSASKと大差ない手間で出来るんじゃないかと思うんだ。
初めて書いたプログラムがTownsGearのBASICだった
F-BASIC買う金なくてTownsOSに入ってたから。 GUIのOSを使えるものにするには
他人資本を入れなきゃダメ。
終了〜〜 Lemmy OS 18MBって凄いなあ。
でも確かOSASKのブラウザは100KB位じゃなきゃダメとか言ってたよな？
本当に作れたのだろうか？そんなの。 ・HTML1.0
・img未対応
・TCP/IPは別
くらいならどうにかなるかもしれん。
w3mみたいなの？ と、w3mからかきこんでみるZZ ttp://blogs.yahoo.co.jp/def_int/archive/2010/05/30
こんな画面どこが楽しいのさ？
っていうかiswebの廃止もろに被ってるなあ、うーん。 スレチだけど一時期OSASKと対比されていたMenuetOSは未だ開発が続いていて実用的な機能も満載な感じになってきたね 僕たんが来ないとちっともスレが伸びないじゃん<(｀^´)>←ﾌﾟﾝﾌﾟﾝ Windowsでもやたらと起動の早いのって出てなかったっけ。
PC向けOSではなかったのかもしれない。
記憶曖昧で申し訳ないけど。
OSASK、起動速度が売りなのにそこでもより凄いのが出ると、そりゃね。
でも、そもそも素人でもOS作り可という点で希望の光だったわけだから、
今後もK氏には皆に夢を与える存在であって欲しいな。 いやいや、何年も前から目をつけていたんだから、アドバンテージはあった筈なのに、なんで抜かれたのかって話。
例えば、windows互換なんて絶対無理だって言ってた当時のアンチに、今のwineを持っていったら絶対黙ったと思うんだよな。 BIOSが16ビットモードでしか使えないと言うことで、
色々ぐぐってたらEFIまで誘導された。
結論：MSX3まだ？ 青木君まだ院入試受からないの？もうすぐ40歳でしょ ソープで童卒を考えています。
都内で、２００００円から３００００円でイチャイチャエッチッチできるお店をご存じないですか？
出来れば、お風呂でのプレイはなく、ベッドだけで済ませたいのですが…。 Windowsはでかすぎるといいつつ、OSASK計画がうまくいけば98やFMのアプリも動くようになる
みたいな事を言っていた時の構想って具体的にはどんなものだったんだろう？
OSASKのソフトとしてのエミュレータ（キラーアプリ）だというのは否定されていたから、
もっとカーネルに関わった所にあったとは想像できる。
ただ、それがマイクロカーネルでいうOSパーソナリティなのか、
ハイパーバイザーでいうゲストOS用の準仮想化ドライバなのか、
どうもハッキリしないんだけど、その辺が読み取れる資料ってなにかあるだろうか？ よくわかんないよね
Wikiとか隅々まで読めばかいてあるのかもしれないが
たしか
・エミュを作りやすいOS
・マイクロカーネルじゃない（パーソナリティー≒エミュじゃない）
でもエミュを作りやすいOSってのがよくわからない
複数のエミュ（アプリ毎に対応エミュを起動？）を実行して既存プログラムが全部動くようにしたいって読み取れたけど具体的な実装の特徴とかはわからない お前が言うとおり少し探せば書いてあることなのにわざわざそんなこと書いて楽しい？ そこまで努力するほどの興味がないから
ただ人にケチつける書き込みだけして楽しい？ 興味ないならわざわざ煽らないで黙って出ていけばいいんじゃない？ 「そこまで努力するほど」って読めない？
まったく興味無いわけじゃないよ、だから見てるんだし
あと煽ってるつもりはないんだがどの辺りが煽りに見えるんだ
仮に煽られてると感じても「探せば書いてあること」なら具体的に提示すりゃいいだけじゃね？
それともやっぱりその辺りはあいまいなままで、それを突かれたのにイラっときたの？ >>388
沈黙しちゃったね。
自分で提示しないなら何でそんなことを言うんだろう？
個人的にはあいまいだったとはどうも想像できなくて、
要は有力な候補案がボツってそのままgdgdになったんじゃないかって気がする。
まあなんの根拠もないので、なにか否定できる証拠が提示されればむしろ歓迎なんだけど。
とりあえず別件を調べてて見かけたのが、カーネルレスって発言。
その意味の説明はどっかでみたようなみなかったような感じで思い出せないんだけど、
これはなにかヒントにならないかな？ HP他を精査する気もないし
そもそもほとんど出来てると言っていたVer5も陽の目を見ないまま御大が別路線に舵を切ったからね
エミュレーターOS（詳細不明）
→色々な環境上で動作するランタイム（kabaやefgやblike）
→実行時に個々の環境用のバイナリを生成するコンパイラみたいな感じ？
ちなみに最新の方針は、今はなきTAOのELATEに似てる 実行時生成ってなんか起動が重そうな気がするんだよな。
OSなんだからインストール時生成でよくない？ GOって長期的な展望としては何の為に作ったんだろう？
事実上のスタイル強制で既存コードを流用させる気がないのなら、ああいうフルセットじゃなくて
askaのフロントエンドとしてCもどきなプリプロセッサを追加しても良かったような？
そこから発展させて、エミュレータOS技術とやらで最適化とかをすれば
あわよくばclangとLLVMのポジションに滑り込めてないか？
結局あれは実用本位というよりも、手っ取り早く「規格準拠処理系有」の文字が欲しかった
という話なんだろうか？ 久しぶりにosaskのことを思い出してどれくらい開発が進んだか調べてみたら
エディタとインタープリタが揃ったんですね。
OSがあってエディタがあってコンパイラ（インタープリタ）があれば
ハッカーのおもちゃになりうるのでそこから発展していく可能性がありますね。
かつてのlinuxがそうだったように。
数年前このスレを見た時は国籍のことをとやかく言う人で溢れていて
目も当てられぬ状態でしたが、技術の世界は国籍は関係ないですよ。
技術がしっかりしていれば、受け入れられるものです。
作者の方には頑張って欲しいですね。
アプリケーション開発者達のコミニュティーも出来たのでしょうか？
linuxのように発展することを祈っています。
x86を自分のコードで動かすというのはプログラミングに興味のある人間なら
誰もが憧れることだと思います。
個人的考えを長々とすいませんでした。 >>393
「数年前」から進展した事ってなんだろう？
なにか見つけたなら教えて。
エディタとコンパイラ・インタプリタなら１０年近く前からOSASKに存在していた気がするんだけど、
それって夢だろうか？ １０年前から追いかけてるならそのくらい見つけられるだろ？素人か？ OSASK本体は4.6から何も前進してないじゃん
はりぼてとかefgとかOSASK以外のモノは色々あったけど いや、少しずつでも動いている場合、見続けていると目の錯覚でわからなくて、
タマに見る人のほうが違いが認識できることがあるかもしれないじゃないか。
そういえば最近巷でよく見るバージョンインフレ定期リリース方式って、OSASKがはじめたものなんだろうか？
っていうか、忙しくなってそれが維持できなくなったという時、その間隔を広げる
つまり隔月刊とか季刊とか年刊に移行じゃなくて、やめてしまったのはなんだろう？
てっきり突発的な事情ですぐ復帰できる目算があるんだと楽観視していたんだけど、
もしかして関係者の認識は休刊、つまり事実上の廃刊だったのだろうか？ >>400
wikiに限らずosask.net全体が時々アクセスできなくなってるようだ
結構、言語処理系に行くっていうのが、はまりポイントで、
確か、Rubyのまつもとゆきひろさんか誰かがおっしゃっていたんですが、
「エンジニアっていうのはだいたいOSを作るか、
言語処理系を作るかに分かれる」らしいんです。
私はどっちにも足をつっこんでしまった感じで、
これは泥沼なんじゃないのかなとも思いますね(笑 OSASKって、もう作り始めて10年くらいになるのかな？ >>588
／）
／／／）
／,.=ﾞ''"／
／ i f ,.r='"-‐'つ＿＿＿_ こまけぇこたぁいいんだよ！！
/ / _,.-‐'~／⌒ ⌒＼
／ ,i ,二ﾆ⊃（ ●）. （●）＼
/ ﾉ ilﾞフ::::::⌒（__人__）⌒::::: ＼
,ｲ｢ﾄ､ ,!,!| |r┬-| |
/ iﾄヾヽ_/ｨ"＼ `ー'´ ／ OSASK公式ページは完全消滅してしまったのかな
…というか家からアクセスすると不正なIPとして登録されとる！一度も書き込んだ事ないのに >>407
普通に見れるぞ
たまにCSS来なかったりするが そういえばosask.comってなんだったんだろうな結局
MLでフィッシングかと思ってビックリしてたら、まるで内輪の人間みたいな紹介で更にビックリだったような？
まあ大方メール等水面下でやり取りしたって位なんだろうけど、Lみたいに結構誤解してる人居るよね。
ただ、元々サークルというか仮想会社の社員がコアメンバーとして居るので、その辺で非常に不透明な所があるんだよな。
っていうか、それらの件もあって、OSASKは会社の製品名だとは思われても、個人管理のものだとは誰も思っていなかったと思う。
開発メンバーにとってはOSはコードネームで呼ばれてて、わざわざOSASKといえばコミニュティかアプリだってこともあるしね。
逆に言えば、あの時MacOS(iOS)のdarwin的な、コードネームより上位の実装群名を（それこそはりぼてでも良かった気がする）
推奨しておけば、その後のヒビ割れはかなり防げたんじゃないかな？
バージョンが機能を表していれば数字で代用できるんだけど（でもOS_9はあんまりだよ）
歯抜けがみっともないのか最近は流行らないね。 -‐''''"´￣｀`ヽ､ ＿＿＿_
/ ＿ ヽ ／／´ __,,＞､
/ ￣￣ { /::/ ／￣:::::::::::::::＼
l _ｨﾆﾆｱ二二二ﾆヽ､j._ /::::l／::::::::::::::::::::::::::::::::l
| 0Lj／-‐-ﾚノ ﾉ＿ヽ:::｀ヽ l:::::::::::／l／lノノ/_イ:::::l
ﾚ:r､/ ｲﾟﾃ ﾋﾟﾄ｀|::| l:::::::::/ rtﾃ､ .ｨtq l::::::|
l:lﾍ '" ,j '"/ﾉ |::lﾍ!j ´ ,j !;:::/
ヽヽ､ r‐-, /' ﾚﾘｰ ､ ,...., lﾉ/
lヽ､ ￣ ／ ｀ヽ､lヽ ､ ￣ ／´
＿,r┴‐-｀v´-‐j-､＿＿ , -‐-､_r┴─'ｰ‐ﾁﾄ ヘルス！！
／￣/:.:.:.:|￣￣｀T￣´|:.:.:.:l´ ｀ヽ / ヽ￣`ー-‐'´`''''⌒ヽ
／ ,':.:.:.:.:.l l l:.:.:.l ＼ ＿r‐､-､-､ｒ, ､ ',
|:.:.:.:.:.:.! ! !:.:.l ,. -‐ゝ/// 〉 〉 〉 〉 〉 ! ',
l:.:.:.:.:.:.ｌ | l:.:.:l ／ 人〈〈〈〈 ' ' ' /っ l l
l:.:.:.:.:.:.! ! l:.:.:.ﾄ/ / ```´-ｧ‐'''" / l
､＿＿/:.:.:.:.:.:ｌ | |:.:.:ヽﾍ l /／ / _ ｨノ
/:.:.:.:.:.:.:! l |:.:.:.:.:l `ｰヽ､＿ノ´l､＿＿＿＿__/lﾆ二」
＿___l:.:.:.:.:.:.:.| l |:.:.:.:.:! |＿ （ ( ) ）_〕| l
l`ー‐‐'匸二l￣￣l二フｰｲ / ￣ `‐‐'´ ヽ | 開発環境は有り物を借りてくるのが正解なのに自分で作れると無駄に意地を張った結果がこれ
サイズ縮小とかアホな方向に迷走していたのも対抗意識からだったな
個人的感情が先に立って大局で見れなくなった時点で詰んでたんだよ。 と、偉そうに評論するだけのお前は何様なんだよwwwwww 有りモノ借りるのも大変だぞ＞開発環境
クロス開発ならともかくセルフ開発を実現する場合は「開発環境をビルドするための」もろもろが必要だから
libcやPOSIX系コールや各種UNIX系ツールが当たり前に動かないとビルドできないし
そういうの全てを構築するのと独自でコンパイラ・アセンブラ・リンカを作るのとどっちが大変かはわからないけど どうせ同じく手間がかかるんなら
結局自分で作っちゃった方が自分の目的により合った物になる
って事なんだろうな
サイズ縮小はあれはあれで重要なテーマだぞ
昔NECが必要に迫られてV810を大幅に改良したV850を作った話とか知らんの？
結局V810はあまり使われず(PC-FXとかTiPOとか有名な採用例はあるけれど)、
コード効率が大幅に改善されたV850の方は今でも現役で使われてるほどだ。
Windowsなんかを見て効率の悪さに我慢できなくなったのは無理も無い話だし
そもそものOSASKの発端が「効率を良くすればもっとよく動く筈だ→エミュレーションOS」
という発想だったのを忘れちゃいけない(ちゃんと初代の頃からK氏ははっきりそう言ってるぞ)。 コード効率の良いハードを作るのと
ハードに合わせて効率化するというスタンスでははたして同じといえるかどうか
むしろ古い（効率の悪い）ハードでもまだまだ頑張れるというのが後者だ
エミュOSというよりはマゾOSとでも呼んだほうがしっくり来るな 第二世代OSASKの説明によると(いや第一世代からそう言ってたか)
K氏は「効率の悪いマシンでマゾる」のでは無く
「本当はこんなに効率が良かったマシンの本来の効率を引き出す」という
とらえ方をしていたみたいだけどな。 OSASKが迷走してるかに感じてOSASK批判してる人って
要するにアウトプットが自分の欲しいものと異なるのが不満なだけなんだろうな
確かに相互互換環境とやらは自分なんかも欲しい(そもそも自分もOSASKに興味を持ったのが
TownsOSのアプリなんかをPC-98でも実行したいというものだし)が
あくまでOSASKとはよりよい実行効率を求めるもの(互換環境はその結果もたらされるはずの物の一つに過ぎない)
とはK氏自身が最初から言ってた事なのだし
自分が欲しい物とK氏が目指してる物が同一の物では無いというのは理解していた
最初から自分が欲しい物そのものズバリを目指してる訳でない人間に
自分の欲しいものとズレがあるぞと文句を言うのは筋違いだと思っているのだが。 その効率というのが足周りの些細な改善でしか無い点に注目したほうがいい
現在のハードでは基本性能が上がりすぎてもはや性能差など体感することさえ不可能だろう
改善の優先順位はアプリのアルゴリズムが先でOSの効率などほとんど関係ないのが実際だ その「現在のハード」ってのは、あくまで「家庭用orオフィス用最新型デスクトップPC(最新Windows用)」限定でしょ。
OSを小さく効率よくできれば、眠ってる過去のハードを再活用できるだけでなく
これから作るハードをもっと小さく作る事だってできる。
OSASKの機能密度でWindowsの規模の物を作ればもっと大きな事だってできる。
そうすればコンピューティングの幅そのものを広げる事だって可能。
そういう観点で効率化を図ってるはずなんだけど。 どうせGCCなんてライセンスアレなんだから、有りモノ（DOSExtender版gpp）で済ませたほうが
エミュレーションOSの最低限のコンセプトを満たせたし、サイズ的にも小さいんじゃなかった？
古いから最適化は甘そうだけど、サイズ優先なら変わらないんじゃね？、誰か比較してみたのかな。
まあ出力コードが気にくわなければインライン使って明示すれば？って話だし。
それにしてもなぜ(国産)旧機種でも対応OSがあればまだまだ使える的なコンセプトを
後ろ向きだとかケチョンケチョンに言われ、一方GCCの可搬化だのCILでJAVAOSっぽいの作るだの、
ちょっと考えればエミレータOSより全然どじょうなPJが通ったんだ未踏って。
エミレータOSって名称の印象が悪かったとしか思えないな。
ハイパーサブシステムとかMinimum-Suite互換レイヤとか、適当に命名してれば違ってたとかない？
あそこで教育OSとか言われて中途半端に拾われてなきゃ、未踏厨に神経削らずに済んだし、
（実行効率命にとって）くだらない移植作業をスケジュールで強制されなければ、
POSIX厨相手にコウリツガーと喧嘩吹っかけてアプリ屋に敬遠されることもなかったような？ ヘテロジニアスコンピューティング標準対応のクラウドOSとかならまだ将来性があったんだがな
中古PCなんてワッパが悪いマシンを使いまわす事自体電気の無駄だし。今やスマホで事足りる
今にして思えば時代錯誤というか後ろ向きなのは結果的には当たっていたわけだ。 電気の無駄ならスイッチ切れって話。
そういうのは２位じゃ駄目とかいうコンピュータの話であって、台数を減らせないPCじゃ変わらない。
むしろこの場合、その中古マシンが最新だった頃の話なので、
その焼鳥マシンを導入せずに型遅れの省電力タイプで充分キビキビ動くだろ？って感じなのさ。 時代錯誤どころか、今のデフレを先取りしていたと言える。
まあいつまでもデフレってわけにはいかないから、需要を創造しないといけないけど、
振り落として難民を出すようなやり方はそれこそチキンレースで先なんてない。 >>422
スイッチを切ればいいのかｗそりゃ画期的だ
一昔前のハイエンド並のことが今ではARMひとつで出来てしまう、CPUの効率以前の問題だよ >>424
ハイエンドの活用を考えなきゃ、それこそ後ろ向きの話でしょうよ。
ハイエンドの需要がなくなって絶滅したら、残ったそれがハイエンドになるだけ。 OSASKの問題は、「ハイエンド」の基準がメガバイトな所なんだよな。
まあ方針の問題であって、設計限界というわけじゃないだろうけど。
それこそ8bitでも頑張れば管理できる訳で、32bitCPU自体が既にもったいない気がするレベル。
エディタアルゴリズムへのLのイチャモンも、技術力の文脈だったから不当だけど、
むしろ故意の設計だとすれば、プロなら別料金が取れるからそれでいいけど、
フリーだとその時になれば、そんな大改造誰がやるんだ捨て捨てって事になって
結局ヘビーユーザーは重くてサポートも切れた奴で我慢するか、慣れない奴に乗り換えるかの、
二択を迫られて、それじゃ元の木阿弥なんだよな、デサインあ。 8bitでLinuxが動いてる
ttp://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit >>426
実用性無視しない限りは故意であの設計はありえん
>>427
動いてると言っていいのか？
結局、誰にとっての実用性かってことだろうな。
OSのおまけとしての実用性は、古いメモ帳のような壁がないことを示せれば充分だろう。
APIのサンプルとしての実用性はソースがあればいいし、
スタンドアロンの漢字変換まで対応している版なんてサンプルでは通常やらない。
まあ小さな設定ファイルを弄る時に実用しているのは間違いないだろう。
そもそもフロッピーでデカいファイル扱う時点で実用的とは言いがたいんだよ。
そこでフラッシュメモリに目をつけたまで良かったんだよね。
問題はFAT12以外のサポートだよな。
フラッシュメモリ用に提唱していたFATのサブセットでも、最大容量はメインメモリ以下だったと思うけど、
あの暫定互換フォーマットも結局実装されたのだろうか？
まあ、半導体メモリが容量でも単価でも円盤と同等になるというのは誤算だったのだろうか？
変換辞書とか、多色化した時点でストレージ容量がもの足りないのは明らかだけど、
なぜ取り外しメディアのような消耗品の変更やアプリの進化に対応できる余裕をもって組まなかったのか
というのは疑問だな、何かに急かされて後回しにしたのか、意図的なネタストックか、
それとも開発している分には本当に必要なかったのだろうか？ 思うにナローな環境を延命させることしか考えてなかったんだろうな。
データ量や精度を落として表面上サクサク動いてるように見せかけてただけで
絶対的なスループットはけっして増えるわけじゃない。
ドライバがなくてGPUの恩恵が受けられないといったあたりから段々とメッキが剥がれていってしまった それはそれで結構なんだけどね、
デバイスの性能は最初から決まってて増えるわけがない、どれだけ引き出せるかの勝負なわけで。
ただ、例えば日本製が優秀だったのは、カタログに載ってないオーバースペックの部分であって、
部品の不良品率を指定したらわざわざ不良品作るのに一番苦労したなんて冗談まである。
実際、未定義命令調べたら32bitのレジスタが隠れてたなんて8bitがあったり、
小惑星探査機なんて満身創痍で本来なら褒められた話じゃないけど、
その手の隠し機能に何度も助けられてとうとう還ってきたわけで、
結局機能なんていくらあってもイザという時に使えなければ宝の持ち腐れで無いのと同じ、
延命させたいならそれこそ実際の性能限界を把握して組んでないというのが解せない。 都市伝説を本気で死んじゃうお子様か？
春だなぁ・・・（笑） 脱原発ってさ、消費税を１００％にしてさ、クリーンエネルギーのインフラ整備を公共事業にしてさ、
みんなで頑張れば簡単じゃねえの？
生活苦の人は集団生活してさ、日常の経費を削減すれば良いだけよね〜？
【貴方にとって早急に人類全てが知るべき情報とは、どんなものですか？】
http://amba.to/GM10kj >>431
宇宙開発みたいな限定的な環境ならそういうこだわりもアリかもしれないけど
そこまでする必要がないほどにハードの基本性能が進化してしまった、
効率追求型OSの需要は右肩下がりになるであろうことは当時でも予測できたはずなんだけどな
もっと他の視点でアピールできていればあるいは違う未来があったかもしれないが。 ＞データ量や精度を落として表面上サクサク動いてるように見せかけてただけで
DAPSとか、CDROMの等速なんてUSBのロースピードの十分の一だというのによくやってたよな。
FDってその更に四分の一で、モデムと勝負できる程度だったのか、改めて考えた事なかったけど。
＞そこまでする必要がないほどにハードの基本性能が進化してしまった、
つまり、全く実感できないほどにソフトのテクニックが退化してしまったと？ たとえばある処理を1秒以内に完了したいとするわな
1.5秒が0.8秒に改善するならものすごく効果的だ
ところが0.015秒が0.008秒に改善しても体感性能はまったく変わらない
基本性能が上がって処理が軽くなると効率化する意味が薄くなるわけだ。
技術的には並列化やらGPGPUやらむしろ進化しているんじゃないか？ >ところが0.015秒が0.008秒に改善しても体感性能はまったく変わらない
仕事量が1.5秒分のままで安定していれば、理論上はそうなるけど、
実際には雑用に追われて蕎麦屋の出前化して、２秒後に処理してたりするんだよね。 そういう細かい最適化の積み重ねで改善に繋がってるんだけど 目に見えない所で誰も手を抜かなければ、とんでもない代物ができたりするんだよな。
イースターエッグに便利機能突っ込んだら、いつの間にかマニュアルに載っちゃってたり。
良くも悪くも右に倣えで、エイプリルフールを妙に凝っちゃったりね。 >>427
MSX用のUnix系OSのUZIXというのが以前からあった UZIXはUNIX V7コンパチのUZIのZ280版のUZI280をZ180に移植したUZI180を更にZ80に移植したものなのかな？
元のUZIってそもそも8080コードだったらしいから、Z800由来のMMUからHD64180由来のMMUに移植した差分を利用して
MMUのないMSXのバンク切り替えで動くように移植したって事なんだろうか？
>>427のAVR版linuxはelksを移植した訳じゃなくて、ARMのエミュレータをAVRで書いて
ARM版のlinuxをAVRで動かしているみたいだね。
すると、AVRのエミュレータを書けばlinuxが動くってことか？
まあエミュレータ書くのに32bitのARMと8bitのAVRでもそれほど違わないような気もしなくもないけど、
回路から全部自作ハードみたいなことを考えた場合は結構違ってきそうだよね。 するってえと8bitCPUで32bitCPUをエミュってるって事？
8bitCPUで仮想16bitCPUをエミュる例(AppleIIのBASIC)とか
32bitCPUで64bitCPUをエミュる例(QEMU他)があるから
不可能な話では無いのか。 4bitの電卓でも数の計算が16までじゃなくて、暗算できないレベルまでできるのと同じじゃないかな？
8bitと言ってもRISCなのでレジスタ一杯あるし、っていうかGCCとかあるんだから、
速度度外視すればそのままコンパイルできたりもするんだろうか？
そういえばASKAってx86以外には対応してたっけ？
色んなCPUに対応できるように拡張すれば、そのまま仮想命令セットになったような気もするんだけど
そういうわけにはいかないものなんだろうか？ 速度はあまり心配してない
世の中には680x0なMacで無理矢理エミュレートしてMacOS Xを立ち上げた人が居るそうだから
起動に一週間かかったとかw
それよりメモリとかそっちが心配
8bitでもMMUあるようなCPUなら何とかなるのかな
MSXでもメモリアドレス空間64MB(そのうち実際に普通のメモリを積めるのは事実上32MB＋α)だし
あとはHDDを繋げて仮想メモリとか？ MMUが無いなら、最悪CPUで転送すればいいわけで、
ただ読み書きするだけなら、MMUなんかなくてもIOマップドメモリで直結すれば充分じゃないかな？
最近はなんでもシリアルだから1bitで済んじゃいそう。 でもEMSとかでなんかそういうのなかったっけ？
クロックの桁が違うから力技でも普通に動くみたいな。
Winにしても当座はそういう小手先の互換でしのいで、時間稼ぎしている間に作り直せばいいって話だったのが、
既存ソフトは当社比のハードルが高いのでもたもたしてたり、焦りすぎて駄作を出したりして、
何も考えずにとりあえず作っただけの技術力もへちまもないメーカーにまでコテンパンにされちゃった感じ。 i286時代のEMSでプロテクトモードメモリとのソフト転送をやるってのはあったと思うが
さすがにプロテクトメモリであってシリアルメモリでは無かったぞw
それでさえ遅い遅い言われてたのにシリアルメモリじゃねえw
せめてバンク切り替えだかDMA転送だか、データバス幅分はきっちり活かせる方式でなければ。 最近の高速シリアル転送は、並列転送だと一本一本の信号のバラつきを揃えるほうが大変、
というような高速通信だからなw >>448
「なんでもシリアル」というのは最近（でもないかもう）の話で、EMSの頃じゃCDROMも無いんじゃないの？
CDROMの体感上の遅さはn倍速みたいなアクセスタイムじゃなくて、主にシークタイムだったんだよね実は。
だからゲームにシーケンシャルに読ませたり、待ち時間を繋ぐ技術があると、その容量が活かせて
なんか全然別の凄いガジェットに思えたんだ。
でも最近のシリアルってそういうデバイスの都合じゃなくて、パラレルの代替なのでその辺は考えられていて、
要はバス幅分だけパラレルの限界よりオーバークロックできれば同じだって理屈なんじゃないかな？ 元々のOSASKの主張ってさ
メインメモリを埋め尽くしてしまうような超巨大プログラムであっても、
ループがなければメモリチェックの時間で終わってしまう筈。
なので、遅いのは処理待ちループに赤信号のように引っかかりまくっているだけで、
それは管理しているOSの性能不足ということで、CPUの処理能力は実は充分なんじゃないか？
って感じだったと思ってるんだけど、違ったかな？
まあ、OSASKのスケジューラがしっかりしていれば今頃はもう完成してる筈だろ！ってつっこみはともかく、
そういう問題って、処理能力が劇的に上がったとしても結果がそれほどには向上しない事を説明するのには
充分だと思ったな。 
