このとき、未フォーマット状態ではなく(アプリケーションからは 未フォーマットと認識されない)、かつ壊れたファイルの存在する状態に なります。
上記のようなカートリッジRAMに対してデータの記録を実行すると、BUP_Write() 関数内で停止してしまいます。
比較のため、他のアプリケーション(SBLの同名の関数を同手順で呼び出して作成 した)のデータ記録処理を動作させてみたのですが、正常に実行されていました。 BUP_Write()関数の内部処理等で、ライブラリによる差異があるのでしょうか。
バックアップデータが壊れているということは、バックアップデータに
含まれている、データのサイズ情報なども変わっている可能性があります。
バックアップのRead/Write時にそのバッファをオーバしてしまうような事態が
起こり得ます。
それがシステムの使用している重要な領域であったりした場合
ことによってはハングアップすることも考えられます。
そもそも確かにユーザの使い方によっては、この様な状態になる事は充分 考えられますが、こうなるともうアプリケーション側では手出しの出来ない 状態となってしまいます。
4096バイトの連続したデータの場合、作成基準にある使用量の式で
計算した場合、使用量は(4096+32)/64=65ブロックとなるはずですが、
実際バックアップRAMに書き込んで"BUP_Dir"や"BUP_Stat"で調べてみると
使用ブロック量は72ブロックとなります。
また、バックアップデータ管理画面の方では、計算式通り65ブロックとして
表示されます。この相違は何故起こるのでしょうか。
1つのバックアップデータで、本体内蔵バックアップRAMを容量限界まで
使用しても構わないのでしょうか。
それとも、モラルとしてある程度の容量は空けておかなくてはならないので
しょうか。
バックアップRAMへのアクセスを行う場合、Bup_Statで取得された構造体BupStat に示されるブロック単位で書き込みが可能かどうかを確認し、参照して行って ください。
Developer's Information STN-9 で説明している「消費量[ブロック]」は、
'ユーザ'に使用量を通知する為の便宜的な値です。
という計算式を用います。
この計算式は、本体 BOOT-ROM のバックアップ管理画面で表示される消費量 の計算式と同一で、本体・カートリッジ・FDの全てに共通です。 厳密な意味の消費量とは異なる為、残り容量のチェック等には 使用できません。
また、ライブラリ関数での「block」はデバイス毎にサイズが異なり、 次のようになっています。
| 総ブロック数 totalblock | 1ブロックの容量 blocksize (バイト単位) | |
|---|---|---|
| 本体内蔵RAM（現行） | 512 | 64 |
| パワーメモリー（旧型） | 1024 | 512 |
| パワーメモリー（新型） | 2048 | 256 |
もしもコメントの内容を日本語で記述する場合は、'言語種類'には、 BUP_JAPANESE を指定してください。
その他の言語の場合は、次のうちのどれかを使用してください。
| BUP_ENGLISH | :英語 |
| BUP_FRANCAIS | :フランス語 |
| BUP_DEUTSCH | :ドイツ語 |
| BUP_ESPANOL | :スペイン語 |
| BUP_ITALIANO | :イタリア語 |
※ファイル名・コメント情報に使用できる文字については、 「バックアップ作成基準」を御参照ください。
BUP_Init( addr, workbuff, conf)
Uint32 *addr :ライブラリ展開領域
Uint32 workbuff[2078] :ライブラリワーク領域
BupConfig conf[3] :接続デバイス情報
conf[0] 内蔵RAM
conf[1] カートリッジRAM
conf[2] FDD(現在は使用不可)