-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 のソースコードのコメントを増やす

　　まぁ、あんまりやりすぎないように