FENIX Programmer's Manual


FENIX Ver0.2 Copyright (C) 1991-1998 S.Uchida

fsh   Ver0.2 Copyright (C) 1991-1998 S.Uchida

★　オブジェクト

１．オブジェクトとは何か

ＦＥＮＩＸが直接実行可能なプログラムは、4000H 〜 FFFFH で動作するバイナリ形式のプログラムです。

ＦＥＮＩＸは、プログラムをオブジェクトという形で管理します。 オブジェクトとは、メモリ上に存在するプログラム・データの単位のことです。 ディスクで言えばファイルに相当し、ファイルと同様に名前をつけて管理されています。 最大１６個のオブジェクトを持つことができますが、その内の１つはシェルですので、ユーザーが利用できるのは１５個です。

オブジェクトには以下の３つのタイプがあります。

bin ... 直接実行可能なバイナリプログラム
dat ... 単なるデータ
txt ... テキスト

ＭＺ−２５００は８ＫＢ単位でメモリが分割され、自由にマッピングを行うことができますが、オブジェクトはこのメモリブロック（ＭＢ）を単位として構成されます。 どんな小さなオブジェクトでも、最低１ＭＢ・８Ｋバイトを占めることになります。

各オブジェクトは複数のＭＢを持つことができますが、それらのＭＢにアクセスする際にその実際のＭＢ番号を知る必要はありません。 ＦＥＮＩＸは各オブジェクトに対してローカルなＭＢ番号を与えます。

例えば、６個のＭＢを持つオブジェクトがあった場合、それらには実際のＭＢ番号とは関係なく、０〜５というＭＢ番号が与えられます。 これをローカルＭＢ（ＬＭＢ）と呼びます。 このＬＭＢを用いてマッピングなどを行います。

さらに、ＥＭＭを装着している場合、ＥＭＭ上にＬＭＢを確保することができます。 ＥＭＭは６４０Ｋバイトありますから、６４０／８＝８０ブロック使用可能です。 （実際はＲＡＭディスクとしても使用することからこれより少なくなります）

これに伴い、以下のようにＭＢ番号が拡張されます。

００Ｈ〜０ＦＨ　　メインＲＡＭ（標準）
１０Ｈ〜１ＦＨ　　メインＲＡＭ（拡張）

２０Ｈ〜２７Ｈ　　ＶＲＡＭ（標準）
２８Ｈ〜２ＦＨ　　ＶＲＡＭ（拡張）

３０Ｈ〜７ＦＨ　　ＥＭＭ

　注：これはＬＭＢと実ＭＢの対応を表すために内部で使われる番号です。
　　　ＰＣＧやＲＭＷなどはＬＭＢとして確保されないためこのようにしています。

しかしＥＭＭ上にＬＭＢがあると、メモリ上にマッピングすることができません。 そこで、ＥＭＭ上のＬＭＢをマッピングする必要が生じた場合にはメモリスワップを行います。

本体内のＭＢの内容と、マッピングするＥＭＭ内のＭＢの内容とを交換し、その本体内のＭＢを新たにそのオブジェクトのＬＭＢとします。 ＬＭＢは実ＭＢ番号とは無関係なので全く支障はありません。 また、交換に使用する本体内のＭＢの選択はＬＲＵ(Least Recently Used)リストを用いて行っています。

メモリスワップは自動的に行われます。 従ってユーザーは基本的に気にする必要はないのですが、注意しなければならないことがあります。

メモリスワップが生じると、本体内のメモリの内容が変化します。 そのためメモリマッピングは必ずＦＥＮＩＸのファンクションを用いなければならないのですが、割り込み、エラー処理などで強制的にマッピングの変更が行われる場合があります。 この場合、実ＭＢ番号を用いたマッピングが行われますが、その内容は保証されません。

従って、エラー処理などでシステムによってマッピングされるＭＢは、ＦＥＮＩＸのファンクションによってスワップ不可にしておかなければなりません。 ただし、システムが使用しているＭＢはＦＥＮＩＸの管理外ですのでスワップされず、気にする必要はありません。

なお、１つのオブジェクトの最大サイズは５１２ＫＢです。

２．オブジェクトの種類

ＦＥＮＩＸの最大の特徴は、走らせるプログラムは必ずオブジェクトとして取り込まないといけないというところにあります。

通常ユーザーはシェルからプログラムを起動しますが、それには２つの場合があります。

  1. 既にメモリ上にあるオブジェクトを起動する。
  2. ディスク上のファイルから起動する。
２は従来のＯＳでおなじみの方法ですが、実際はＦＥＮＩＸにはファイルを直接実行する能力がないので、以下の方法で起動しています。
　　　実行するファイルをオブジェクトとしてロード
　→　オブジェクトを起動する。
　→　実行が終わったらオブジェクトを消去する。

こうして従来のＯＳと同様に動いているように見せかけているのです。

本来オブジェクトは、実行が終わったからといって自然に消去されるものではありません。 つまりＦＥＮＩＸ上で動くプログラムは全て、広い意味で「常駐」すると言えるのです。

このことを利用することによって、オブジェクトを単なるプログラムにとどまらせず、様々な機能を持たせることが可能となります。 以下は、それに関する用語説明です。

ａ．常駐オブジェクト

元々オブジェクトは常駐するものですが、ファイルから起動するとシェルに消されてしまいます。 ですがプログラムによっては、勝手に消されては困るという場合があるでしょう。

そこで、オブジェクトが自分自身の書き込み許可を取り消すことによって（オブジェクト管理テーブルの説明を参照して下さい）ファイルから起動した場合でもシェルに消去されずに済みます。

こうすることで自ら常駐するオブジェクトを常駐オブジェクトと名付けます。

ｂ．ゾンビオブジェクト

常駐オブジェクトを消去するには、書き込み許可を出して消せばいいわけですが、ユーザーとしては勝手に常駐したオブジェクトですから勝手に消えてほしいものです。 そこで、常駐オブジェクトが自ら書き込み許可を復活し、自分自身を消去することができます。

この、自分自身を消去した状態というのは、FXC .KILLOBJ を実行してもメモリマッピングが変更されるわけではない、というところから可能な状態です。

しかしこれは、オブジェクトとして死んでしまった（メモリも解放されている）プログラムが動いている危険な状態です。

この状態をゾンビオブジェクトと名付けます。ゾンビオブジェクトは速やかに呼び出されたシステムに帰り、迷わず成仏しなければなりません。

ｃ．ＴＳＲオブジェクト

常駐オブジェクトを更に進化させたものとして、いわゆるＴＳＲがあります。 単に常駐するだけではなく、常駐することによって何らかの機能を果たすものです。

ＦＥＮＩＸでは以下の種類のＴＳＲをサポートしています。

・ソフトウェア割り込み

別のオブジェクトからエントリアドレスを呼び出すことによって処理を起動します。 ＳＶＣやＦＸＣのようなものだと思えばいいでしょう。 最大１６個のエントリを管理することができます。

・０．１秒タイマ割り込み

ＭＺ−２５００のＩＯＣＳでは０．１秒毎に処理を起動することができる割り込み機能が備わっています。 これを管理しています。最大７個のエントリが使用可能です。

・ハードウェア割り込み

ハードウェアの割り込み源によって生じる本来の割り込みです。 別の処理を行っている場合でも割り込み要求が来れば起動されますので、この割り込みを用いたＴＳＲを作成するにはかなりの知識が必要です。

以下の７個の割り込み源をサポートしています。

ＰＩＯと優音以外はＩＯＣＳが使用していますので、不用意に使用するとシステム自体が動かなくなってしまいます。

ＴＳＲオブジェクトは専用のＦＸＣを用いて登録して使用します。 詳しくは Technical manual を参照して下さい。

★　統一ファイルアクセス

OBJ,BTX.BSD,BRD の４つの形式のファイルを、２５６バイト単位での入出力によって統一的にアクセス可能としています。

元々異なる管理方式で扱われているファイルを統一的に扱うために多少制限があります。 OBJ,BTX は特に注意が必要です。

OBJ,BTX はその管理方式の都合上、セーブ時にセーブサイズを指定しなければなりません。そして、書き込み時にもＥＯＦチェックが必要です。 さらにオープンした時点で既にファイルが作成されているので、ｃｌｏｓｅ／ｋｉｌｌファンクションを用いてｋｉｌｌすることができません。
（管理テーブルの構成を見てもらえばわかりますが、OBJ,BTX のアクセスにはデバイス名とレコード番号に関する情報しかありません。ファイル名の情報がないのでｋｉｌｌできないのです）

このように制限が多いので、OBJ,BTX は統一アクセスによる書き込みは不得手です。

BSD,BRD に関してはＩＯＣＳに操作ファンクションがあり、ＬＵを用いてアクセスできますが、OBJ,BTX に関してはそういったものはありません。 そこで、ＦＥＮＩＸ内部でＬＵを用意しています。 ＩＯＣＳで用いられるＬＵは０〜１２７なので、１２８以上をＦＥＮＩＸのＬＵとしています。この番号は固定で、１２８〜１４３の１６個が使用可能です。

ＦＥＮＩＸ上でファイルを扱う場合、ユーザーはＬＵを指定する必要はありません。 ファンクションの説明を見てもらえばわかりますが、ＬＵはＦＥＮＩＸによって与えられます。

オブジェクトもこの統一アクセスを用いて作成することができます。 インタフェイスが全く同じなのでファイルと同様に扱えます。

★　メモリ管理の詳細

１．オブジェクトのメモリマッピングモード

オブジェクトのＬＭＢはメインＲＡＭ、ＶＲＡＭ、ＥＭＭの３種類から確保可能なわけですが、実際にマッピングを行う際には特定の種類のメモリでないと都合が悪い場合があります。

例えばＶＲＡＭ上にプログラムを乗せても走りませんし、逆に単なるデータであればメインＲＡＭにしかマッピングできないというのでは非効率的です。 ＶＲＡＭが余っているのに、単なるデータがメインＲＡＭ上にあるために別のプログラムを動かすことができないというのでは困るでしょう。

そのため、ＬＭＢ単位でどの種類のメモリにマッピングすることができるかを設定することができます。 これがマッピングモードというもので、以下の３＋１種類があります。

モード０　main のみ　　　　　　（ main,EMM,VRAM ）
モード１　main 優先 VRAM も可　（ main,VRAM,EMM ）
モード２　VRAM 優先 main も可　（ VRAM,main,EMM ）

モード３　VRAM 優先 main も可　（ EMM,VRAM,main ）

括弧内は確保されるメモリ種別の優先順位を表しています。 必ずしも目的の種類のメモリが確保されるとは限らないのですが、マッピングする際にメモリ種別が合わなければスワップしますのでアプリケーション側で配慮する必要はありません。

プログラムがあるＬＭＢは当然モード０で確保しなければなりません。

モード３は FXC .GETMB でのみ使われるモードです。 マッピング可能メモリはモード２と同じなのですが、確保する際には極力メインＲＡＭを避けるように設定されています。

これは統一アクセスを用いる際に有効です。 統一アクセスではオブジェクトを読み書きする場合にマッピングを行いませんから、あらかじめメインＲＡＭを避けて確保することによってスワップによるタイムロスを避けることができます。

２．統一アクセス時に設定されるモード

統一アクセスによってオブジェクトを書き込む時には、オープン時に指定するタイプに応じて自動的にＬＭＢが追加される際のマッピングモードが選択されます。 （System call manual の FXC .U_OPEN を参照）
bin ... モード０
dat ... モード１
txt ... モード３

これはそのオブジェクト自身のタイプとは無関係です。 従って、既に存在するオブジェクトをそのタイプと別のタイプでオープンすることでオブジェクトの一部のＬＭＢを異なるモードにすることができます。

３．共有メモリ管理

通常のＭＢとは別に、ＦＥＮＩＸは共有メモリというものを管理しています。 これは、コモンエリア上のスタック領域の空き部分のことです。 コモンエリアは常にマッピングされていることが保証されるため、割り込み処理などのために利用するのに最適です。

Ver0.2 では、ＴＳＲ処理ルーチンをスタック上に置いてあるため、現在 1A80H〜1F??H の１Ｋバイト強の領域が利用可能です。

★　シェルの指定方法

ＦＥＮＩＸではデフォルトで fsh がシェルとして立ち上がるようになっていますが、起動するシェルをユーザーが指定することも可能です。

そのためには、ＦＥＮＩＸがあるディレクトリ（通常ルートディレクトリ）に .fenix というＢＳＤファイルを作成します。

例えば 

fsh00
/bin/shell01

という２行が .fenix に書かれているとすると、ＦＥＮＩＸを起動した時には１行目に書かれている fsh00 というファイルをシェルとしてロードします。 起動時にファンクションキーの２番（Ｆ２）を押しておくと、２行目の /bin/shell01 をシェルとしてロードします。 .fenix のｎ行目がファンクションキーｎ番に対応して、シェルが決定されます。

つまり、

☆ .fenix がある場合

☆ .fenix がない場合

カレントディレクトリから fsh をロードする。 ないと暴走しますので、"ＦＥＮＩＸ" と同じディレクトリに必ず "fsh" をおいて下さい。

その他、

も fsh がロードされます。

★　エラー処理

ＦＥＮＩＸでは通常、エラー処理はシェルの処理ルーチンへとジャンプします。 シェルはエラーメッセージを表示し、入力待ち状態に戻ります。

アプリケーション側でエラートラップしても構いません。 シェルは１コマンド実行するごとにエラー処理を初期化しますので、処理アドレスやマッピングデータを元に戻さなければならないということはありません。 ただし、エラーマッピングはＦＥＮＩＸを介さずに行われますので、マッピングするＬＭＢはスワップ不可にしておくのを忘れないようにして下さい。

ＦＥＮＩＸで生じるエラーは、ＩＯＣＳのものを除けば現在２つだけです。 エラーコードは７１〜を使用しています。

71Permission denied.
オブジェクトのアクセス許可がありません。
ｒ：読み出し許可、ｗ：書き込み許可、ｘ：実行許可の３つがあります。

72Object full.
オブジェクトが一杯で新規オープンできません。
これらのエラーは FXC .ERRMSG で表示されます。

このファンクションでは７３〜はユーザー用になっていますが、シェルのエラー処理では７３〜をシェルのエラーコードとして使用しています。

シェルのエラー処理でユーザーのエラーメッセージを表示したい場合は、エラーコード１２７を発生させてください。
（ LD A,127 ，DE にメッセージへのポインタを入れ、JP 00ACH ）

ただしエラーマッピング後にメッセージがメモリ上にないといけませんので、メッセージはコモンエリアに転送しておいた方がいいでしょう。

シェルで生じるエラーは以下の通りです。

73Too many arguments.
コマンドの引数が多すぎます。
少ない場合は、普通そのコマンドの使用法が簡単に表示されます。

74Ambiguous.
ワイルドカードで指定されたファイル／ディレクトリが特定できません。

75No match.
ワイルドカードにマッチするファイルがありません。

76Not shell script.
実行しようとしたｔｘｔオブジェクトがシェルスクリプトではありません。（最初の文字が # ではない）
シェルのエラーコードは今後増加するかもしれません。

★　外部コマンド

シェルが外部コマンドに渡すパラメータは以下のようになっています。
A 　オブジェクトＩＤ
DE　引数へのポインタ（コモンエリアの BUF2）
引数はシェルによって解釈されたワードリストです。 各ワードは 00 を分割コードとして構成されています。 そしてワードリストの先頭にはワードの数が格納されています。 第１ワードはコマンド名です。

例 

　 save fsh EMM:　　と入力した場合

　 03 73 61 76 65 00 66 73 68 00 45 4D 4D 3A 00 00
　　　 s  a  v  e     f  s  h     E  M  M  :
　 ↑             ↑          ↑             ↑ ↑
ワード数        区切り      区切り       エンドコード
最終ワードの次には２つの 00 が格納されます。

シェルのメタキャラクタなどは解釈済みですが、ワイルドカードは展開されない場合があります。 それは複数のファイルにマッチする場合、及びマッチするファイルがない場合です。

例えば "f*" にマッチするファイルが "fsh" だけの場合、"fsh" と展開されます。 しかし "fsh0","fsh1" などの複数のファイルにマッチすると、ワイルドカードのままワードリストを構成します。

ＵＮＩＸであればファイルリストが展開されますが、ＭＺの場合２５６バイトのバッファを用いていますので無理です。 しかしその代わりにワイルドカードの展開をカーネルのファンクションにしています。 アプリケーションはなるべくワイルドカードに対応するようにしてください。

また、マッチするファイルがない場合、その処理をアプリケーション側で行うことができるように、ワイルドカードのまま渡すようになっています。

★　内部管理テーブルの構成

ＦＥＮＩＸ内部で使用されている各種管理領域のフォーマットを示します。 これらは全てＦＸＣのファンクションで参照可能です。

ＬＲＵリスト管理テーブル ( 2 byte * 32 )

双方向リスト構造を形成しています。 メインＲＡＭとＶＲＡＭでは、別々のリストが形成されています。

１つのＭＢあたりに２バイトが割り当てられています。

+0 ... bit0〜5　リストの前のＭＢ
bit7　スワップ許可（１で禁止）
+1 ... bit0〜5　リストの次のＭＢ
また、ＭＢ００に対するテーブルの位置に対して、
-4 ... メインＲＡＭのＬＲＵ
-3 ... メインＲＡＭのＭＲＵ
-2 ... ＶＲＡＭのＬＲＵ
-1 ... ＶＲＡＭのＭＲＵ
が格納されています。

メモリ管理テーブル ( 2 byte * 128 )

　オブジェクトが持つＬＭＢを、いもづる式に管理しています。 　１つのＭＢあたりに２バイトが割り当てられています。
+0 ... bit0〜6　次のＬＭＢのＭＢ番号（最後のＭＢならば０）
bit7　使用中なら１、未使用なら０
+1 ... bit 7,6　00 ; 通常ＲＡＭ（オブジェクトが所有）
　01 ; 未装着
　10 ; カーネルが所有
　11 ; ＩＯＣＳ等が使用（ＦＥＮＩＸの管理外）
bit 5,4　01 ; main のみ
　10 ; VRAM / main
　11 ; main / VRAM
bit0〜3　そのＭＢを所有するオブジェクトのＩＤ
オブジェクトの先頭ＭＢはオブジェクト管理テーブルに記述されています。

２バイト目のデータは、そのＭＢがフリー（１バイト目の bit 7 = 0）の場合は不定となります。（正確に言うと解放される前の値を保持している）

bit 5,4 はオブジェクトのＬＭＢとしてマッピングするときのモードを示しています。

ファイル・オブジェクトアクセス管理テーブル ( 12 byte * 16 )

ファイルとオブジェクトは同じテーブルを利用しています。 １６個分の領域が確保されていて、+0 の bit 7 を調べれば使用中かどうか判ります。 ＦＥＮＩＸ Ver0.0 との互換性はありません。

ファイル（OBJ,BTX）の場合

+0 ... bit 7　　　1 でテーブル使用中
bit 6　　　0 （ファイルである）
bit 2　　　1 で read 可能
bit 1　　　1 で write 可能
bit 0　　　1 で EOF
+1 ... 未使用
+2 〜 +7 ... デバイス名(max 3byte)＋チャンネル＋":"＋00H
+8 , +9 ... 次にアクセスされるレコード
+10 ,+11 ... 最終レコード（読み出し用）
　オブジェクトの場合
+0 ... bit 7　　　1 でテーブル使用中
bit 6　　　1 （オブジェクトである）
bit 2　　　1 で read 可能
bit 1　　　1 で write 可能
bit 0　　　1 で EOF
+1 ... オブジェクトＩＤ
+2 ... オープンモード（ＬＭＢ確保時のモード）
　　0 ... main のみ（bin）
　　1 ... main/VRAM（dat）
　　3 ... VRAM/main（txt）
+3 〜 +5 ... 未使用
+6 ... オープン時の +8 の値
+7 ... オープン時の +9 の値
+8 ... 次にアクセスするＬＭＢ
+9 ... 次にアクセスするブロック
+10 ... 最終ＬＭＢ（読み出し用）
+11 ... 最終ブロック（読み出し用）
オブジェクトの場合のブロックとは、256byte単位のものです。 １つのＬＭＢに 0 〜 31 の３２ブロックがあります。

オブジェクト管理テーブル

ファイルの管理情報に似せてあります。
+ 0 ... タイプ （ 0...未使用 , 1...bin , 2...dat , 3...txt ）
+ 1 〜 +17 ... 名前 （End code 00H）
+18 ... 属性　bit 0　　　exec permission
　　　bit 1　　　write permission
　　　bit 2　　　read permission （それぞれ１で禁止）
　　　bit 3　　　1...オープン中
+19 ... 先頭ＭＢ番号（0FFH...確保されていない）
+20 ， +21 ... サイズ（+20...LMB , +21...block）
+22 ， +23 ... 先頭アドレス
+24 ， +25 ... 実行アドレス
+26 〜 +31 ... 実行時マッピング（バンク２〜７にマップするＭＢ番号）
サイズは統一アクセスによって書き込まれるものです。 FXC .GETMB や FXC .RELMB では変化しません。

実行時マッピングは正確には FXC .EXECOBJ に渡されるデータです。 フォーマットは FXC .EXECOBJ の説明を参照して下さい。

ＴＳＲ管理テーブル

タイプによってかなり異なったものになっています。 オブジェクトＩＤ＝ 0FFH であればそのテーブルは未使用です。 マッピングデータは全て実ＭＢで格納されています。 コールアドレスとは、オブジェクトの呼び出しアドレスのことです。

・ソフトウェア割り込み（１６個）

+ 0　オブジェクトＩＤ
+ 1 〜 + 6　マップ
+ 7,+ 8　コールアドレス

・０．１秒タイマ（７個）

+ 0　オブジェクトＩＤ
+ 1 〜 + 6　マップ
+ 7,+ 8　コールアドレス
+ 9,+10　コモンエリアタイマテーブルのアドレス

・ＰＩＯ

+ 0　オブジェクトＩＤ
+ 1 〜 + 6　Ａポート処理時マップ
+ 7,+ 8　Ａポート処理時コールアドレス
+ 9 〜 +14　Ｂポート処理時マップ
+15,+16　Ｂポート処理時コールアドレス

・ＳＩＯ

+ 0　オブジェクトＩＤ
+ 1 〜 + 6　ｃｈ．Ｂトランスミッタバッファエンプティ処理時マップ
+ 7,+ 8　ｃｈ．Ｂトランスミッタバッファエンプティ処理時コールアドレス
+ 9 〜 +14　ｃｈ．Ｂ外部／ステータス割り込み処理時マップ
+15,+16　ｃｈ．Ｂ外部／ステータス割り込み処理時コールアドレス
+17 〜 +22　ｃｈ．Ｂ受信キャラクタアベイラブル処理時マップ
+23,+24　ｃｈ．Ｂ受信キャラクタアベイラブル処理時コールアドレス
+25 〜 +30　ｃｈ．Ｂ特殊受信状態処理時マップ
+31,+32　ｃｈ．Ｂ特殊受信状態処理時コールアドレス
+33 〜 +38　ｃｈ．Ａトランスミッタバッファエンプティ処理時マップ
+39,+40　ｃｈ．Ａトランスミッタバッファエンプティ処理時コールアドレス
+41 〜 +46　ｃｈ．Ａ外部／ステータス割り込み処理時マップ
+47,+48　ｃｈ．Ａ外部／ステータス割り込み処理時コールアドレス
+49 〜 +54　ｃｈ．Ａ受信キャラクタアベイラブル処理時マップ
+55,+56　ｃｈ．Ａ受信キャラクタアベイラブル処理時コールアドレス
+57 〜 +62　ｃｈ．Ａ特殊受信状態処理時マップ
+63,+64　ｃｈ．Ａ特殊受信状態処理時コールアドレス

・ＶＢＬＡＮＫ，８２５３，プリンタ，ＲＴＣ，優音（５つとも構造は同じ）

+ 0　オブジェクトＩＤ
+ 1 〜 + 6　マップ
+ 7,+ 8　コールアドレス

これを見ればわかるように、同一割り込み源から複数の割り込みが生じる場合でも各割り込みに対して異なるマッピングを行うことが可能です。 .TSRON では、オブジェクト管理テーブルのマッピングデータを実ＭＢに変換してこのテーブルに登録します。

そのため、例えばＳＩＯの場合、８個の割り込みのマップデータ全てが同一のものとして登録されます。 しかし、一度登録した後 .TSRTAD を用いてマップデータを書き換えることにより、処理に応じたマッピングが可能となります。

・ローカルテーブル番号

ひとつのオブジェクトが Sft や Tim のテーブルを複数使用する場合、例えばソフト割り込みを３個確保した場合、それらには確保した順に０〜２の番号がつけられます。 ＬＭＢ同様、ひとつのオブジェクトについてローカルな番号ですのでこれをローカルテーブル番号と呼びます。

・ＴＳＲ管理テーブル番号

ＴＳＲ管理テーブル内では Sft は１６個、Tim は７個のテーブルが用意されています。 それぞれ０〜１５、０〜６の番号がつけられていて、これらはオブジェクトによらずシステムに対してグローバルな番号です。 これをＴＳＲ管理テーブル番号と呼びます。

共有メモリ管理テーブル

全１６個の領域を登録することが可能です。 一つの領域は以下の５バイトで構成されています。
+0 オーナーオブジェクトＩＤ
+1〜+2 領域開始アドレス
+3〜+4 領域終了アドレス
オーナーオブジェクトＩＤは .KILLOBJ でしか使われていません。

☆注意

FENIXのメインページに戻る