おちゃめくらぶ掲示板 - 1659321896

1110：御茶目菜子：2012/06/25(月) 22:20:29: プチコンでマルチタスクOSを作る
なんだかプチコンでOSもどきを作るのが流行っているみたいなので私も試しに作ってみたにょ。
名付けて「Petitcom OS」にょ。（また、ストレートなネーミング・・・）
http://ww5.tiki.ne.jp/~ochame/petitcom/image/Petitcom_OS.jpg
http://www.youtube.com/watch?v=_zzCVJQwKsY
（ちなみにこの動画ではアプリの起動、ウインドウのドラッグ、アプリの実行、アプリを
無敵モードにしてアプリ動作中のウインドウのドラッグの様子を記録している）

とりあえず、一晩で作ったということでまだ機能は最低限しかないにょ。
現時点でできることとはアプリケーションの起動（ただし、現在の対応アプリは横スクロール
ゲーム「CAVE」のみ）、終了、ウインドウのドラッグのみにょ。（通常版の「CAVE」は
プチコン講座の第7回のサンプルプログラムとして公開しているのでそれを参照）
ウインドウはGRPで描画されているので1ドット単位で自由に移動することができるにょ。
一応マルチタスクに対応しているためアプリ動作中でもウインドウを自由に動かすことは
可能になっているにょ。
現時点ではアプリが1つのみということでマルチウインドウには対応していないものの
重ね合った部分をバッファに入れておけばマルチウインドウに対応させるのは簡単にょ。

マルチタスクに対応させるためにはアプリ側の対応も必要になってくるにょ。
これがシングルタスクならばタスク終了スイッチさえ用意すれば簡単に実現できるけど
マルチタスク対応にするならばアプリ実行中に一定のタイミングでOS側に処理を移し、
そして再びそのアプリの続きの処理を実行するように作る必要があるにょ。（アプリの方で
OSに移す処理を忘れたらアプリでCPUが占有されるためWin9xでは頻繁に見られたフリーズ
状態になってしまう）
このPetitcom OSでは1/60秒単位でアプリとOSを切り替えているためアプリを3つ同時実行
させる場合には1つ平均180fpsで動作させる必要があるにょ。
それより遅い場合は処理落ちをしてしまうので、いくら高速なプチコンとはいえ現実的に
考えるとバックグラウンドに回ったアプリは自動停止させる方が無難かもしれないにょ。
自動停止したら困るアプリもあるから「デフォでは停止」にしてバックグラウンドに回った
時も動作し続けるアプリも作れるようにした方がいいかもしれないにょ。

　《　3本のアプリをマルチタスク動作させる場合　》
　　　アプリ→アプリ→アプリ→OS
　　　↑--- この間が1/60秒 ---↑

ただ、問題となるのはmkIIでもGRPが4面しかないということにょ。
表示用、表示バッファ用、記録用で3面必要になるためウインドウの重ね合わせのバッファ
用にはGRPが1面しか余ってないにょ。
つまり、マルチウインドウに対応といってもウインドウは1つしか開けないことになるにょ。
もっとも1つのGRPが256x192なので128x96のウインドウならば4つまで確保できるものの
それを越えるサイズが1つでもあったらその時点で1つ分しかバッファが確保できなくなって
しまうためにょ。
記録用のGRPを諦めてウインドウのバッファ用に回せば2～8つのウインドウを開くことが
できるものの保存するデータが大きくなるからMEM$ではかなり細切れ保存が必要になるし
唯一余っているSPUだけどこれも32バイト単位でしか読み書きできないため使い勝手を
考えると厳しいにょ。

このPetitcom OSで難点となるのはマルチタスク対応アプリを作るのが非常に難しいと
いう点にょ。
まず、ローカル変数が使えず、すべてグローバル変数となるBASICでは変数名やラベル名の
のバッティングを避けることができないにょ。
それはアプリ名（8文字）＋変数名という長い変数名を用いれば何とか解決可能だし、
このOS用の簡易言語＋コンパイラを作り変数名の管理はすべてOS側で行うという方法もある
（この方法だとHSPのAWAIT命令のようなものを用意すればOSへの処理の受け渡しとアプリ内
でのウエイト処理を手軽に行えるようになる）のだけどやはり最大の問題となるのはGRP面の
少なさにょ。
すべてのアプリでGRP面1つを共用しているためCAVEのようなGCOPYを使ったスクロールゲームを
作る場合には一部の領域を常時占有してしまうことになるにょ。
これが128x96以下のサイズであれば使用していない領域を使用すればいいだけの話だけど
このCAVEはウインドウサイズが160x120であるためその時点で残り横幅が96もしくは縦幅が
72というのが他のアプリで使用できる最大サイズとなってしまうにょ。
これが常時占有しない（常に画面全体を新規描画する）アプリであれば問題ないのだけど
CAVEのようなアプリが1つでもあったらその時点でGRPの面数の関係でマルチタスクで
動作させるのが難しくなってくるにょ。（ちなみに1/60秒単位でアプリとOSを切り替える
ためにアプリ内でVSYNCやWAIT命令を使用するのは不可でOSの動作用にVSYNC 1を使って
いるのみ）

というわけで、即興で作ったものの何か画期的な方法が思い浮かばない限りは先に進む
ことができないためこれで一端開発終了とするにょ（笑）
まぁ思いつきで作っただけだから問題はないけどね。
思いつきといえばレイヤー対応のお絵かきソフトも結局GRPの面数不足で開発凍結状態と
なっているにょ。
GRPが8面あればこのPetitcom OSも表示用、記録用を除いても6面余るためアプリ1つあたり
アプリ動作用で1面、ウインドウの表示バッファ用で1面の合計2面分使ってもアプリ3つを
同時に動かすことができるためようやくマルチタスクOSの意味が出てくるにょ。
現状でもウインドウの最大サイズを128x96に制限すれば4つ以上のアプリを同時に動かす
ことは可能だし、フル画面専用にすれば重ね合わせ処理用のバッファが要らなくなるため
2つ以上のアプリを同時に動かすことは可能なので何かを妥協すれば現状のGRP4面であっても
マルチウインドウ対応に作れないわけではないけどね。