Mercurial > hg > Events > OSC2019
view poster/os9/os9.ind @ 18:1fc9d0bd924f default tip
update
author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Sat, 20 Apr 2019 18:06:35 +0900 |
parents | 7fd82a802a66 |
children |
line wrap: on
line source
-title: OS9 -author: 河野真治 --OS-9 の特徴 Microware 社によりMotorola のMC6809用に作られた 8bit OS。 Module と言う単位をメモリ上にどこに配置しても良い Time sharing を採用した並列実行(concurrent) (平行(parallel)ではない) Unix like なshell とpipe Unified file system ( Device descriptor, Device driver) Floppy disk 128k 階層型ファイルシステム Basic09 というPascal likeな言語を持つ。 --MC6809 <center><img src="6809.gig"></center> --Level 1/2 level 1 ROM上のOS9 p1 kernel で動作する。 level 1 MMUで2Mbyteのメモリを使える -- Module 87CD から始まり、CRC24 で検証されたコードとデータの固まり Relocatable entry point とモードフラグ ROMに常駐できる 8bitなのでメモリ空間は64k(16bit addressing) 8080/6809 は 8bit CPUというよりは、8bit busな16bit CPU --何をするか Emulator 上で OS-9 を動かそう。 できれば Level 2 --なんで? 昔、自作のに乗っけれなかった。せっかく5万円も出して買ったのに。 残念ながらハードはもうないけど、Emulator なら? 20年前に「年取ったらやろう」と思っていたが、そろそろやるべき。 --level 2 アドレス変換に対応し、512kメモリを使用できる。 ユーザ空間とシステム空間を別にできる 8k単位で16task*64k分を512kから自由に割り振れる TLB base ではなく、変換機構をメモリで実装する方式 --kernel構成 OS9p1 system callと割り込み処理 Module 発見と管理 OS9p2 メモリ管理 Task管理 Signal --kernel構成2 IOMan SCF/RBFと device driver とdescriptor の登録 SCF sequencial file io manager RBF randome block file io manager file system管理 --Runtime module init boot用初期データ sysgo clockとShellの起動 Clock timer 割り込み 日付計算 --Runtime module 2 Shell Device descriptor D0 Term Device driver PTY PDisk --nitros9 OS9 をdisassemble したものらしい Tandy Coco 上で動いていたらしい ライセンス的にはだめかも 大目に見られてる? --Emulator sbc09というアセンブラEmulator上に実装して動作させた Java版を作った人がいるらしい Unix上のOS9 emulator があるが動作せず osnineという途中まで作られたものがあった level 2 まで動かす? --利点と欠点 初期の8bit用のUnix like OS 8bitのOSでMMUを持つものとしては唯一 (M/PMもあったが) comapct で信頼できるmodule構成 CRCの意味は不明 メモリ領域はmodule構成ではない --利点と欠点 2 PICのせいもあり、比較的低速 real-time scheduling を持ってない プロセス間通信は貧弱 (signal のみ) 68K用などは現在も生きてる製品 --level 2 sbc09 を mmu 対応にして level 2 まで動かした。 nitros9 という「まだメンテされている(〜2014)」ソースに対応した。 Coco (tandy color computer) 0xfe00-0xffff は MMU による影響を受けない ROM切り替えで、2MBのfull ramとして使える --vrbf 仮想RBF (random block filer manager ) Unix 上のファイルを Emulator 側からos9のファイルシステムとして見せる os9はopen されたファイルを path descriptor というioman が管理するデータ構造で実装する。それに対応する 構造体を vrbf 内で用意する。256個と決まっているので固定配列で良い。そこに FILE *を置けばよい。 os9はディレクトリを普通のファイルとして開いてしまうので、os9のディレクトリ構造を作って返す。 fmemopen というメモリ上のバッファを FILE* として開く機能を使う --vrbf 続き dir -e はファイルの属性を持つ特別なsector (file descriptor)を getstat のundocumented commandを 使ってアクセスするので、それを返す必要がある。 os9は current directory をLSN( 24bit logical sector number)で持つが、面倒なので、current directory 名を256個のFIFOっで管理。 同じ名前は再利用。 path descriptor でcurrent directoryを管理してくれれば良いのだが、そうでなくて、LSN。しかも、path descriptor と別。なので、 別に管理する必要がある。 --level2 での割り込み 時分割処理に必要な clock module は割り込みを行う。 割り込み時には、どのmmuにいるかわからない。なので、 os9にentry割り込みルーチンを登録する os9 が割り込み後mmuを設定してentry割り込みルーチンを呼び出す engry割り込みルーチンで、serviceタスクを SSvcIRQに登録して jmp [D.XIRQ] すると iret してくれる os9 側が暇な時に、serviceタスクをsystem mode で呼び出す service は処理の後、task 切り替えをする用に jmp [>D.Clock] する --level2 のoverhead vrbf はサービスするprocessとは別なシステムメモリ空間にいるので、データは copy sysetm callを使う必要がある。 vrbf のC側からはos9のsystem callを呼べないので、mmu を一時的に作って、それを使ってアクセス。mmuの情報はprocess descriptor 上にある。 call するプロセスのレジスタはsystem spaceにコピーされていて、そこに値を書き込むと返される。 hook がたくさんあり、indirect jump ばっかりが増える。 Coco ではIOは全部のプロセスに見えてしまってる。特に保護されてない。 --module 間のlink os9 のlinkは、system に登録されるだけ。同じメモリ空間に登録されるとは限らない。 同じ空間に登録されれば、module にアクセスできる。 module に付属している固定メモリはある malloc されたものは自由に取り扱えるが、どこにあるかはprocess毎に異なる --OS-9 上のソフト BASIC09 FORTH BASIC GAME09 --Micro C mohta氏と手塚氏の作った 6809 用の整数Cコンパイラ。構造体がある。 かなり動いているんですが... --さらに qemu で TLB base で動かす interpreter base の Emualtor ではなく、compile base にする nitros-9 のソースコードのコメントを増やす まぁ、あんまりやりすぎないように