OS9

河野真治

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

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

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