LoginSignup
0
0

【注意喚起】IchigoCake の PC !RESUP! 00 の効果は「デフォルトのリソースへ戻す」ではない

Posted at

被害

IchigoCake を購入してすぐに PC !RESUP! 01 コマンドを試してみた。
CakeRes は持っていないので、EEPROMは接続せずに実行した。
すると、リソースが破壊され、画面の表示がおかしくなった。

PC !RESUP! 01 コマンドは、EEPROMが接続されていない状態でもエラーにならず、適当なリソースへの書き換えを行う!

次に、
PanCake の使い方 - イチゴジャム レシピ
で「PanCake デフォルトのリソースへ戻す」として紹介した PC !RESUP! 00 コマンドを実行した。
しかし、リソースは正常にならない。
結果、購入初手でリソースを破壊し、リソースを使用する処理を使い物にならなくしてしまったのである。

リソースを使わない処理、たとえば

  • 画面の単色塗りつぶし
  • 線分、円、データを指定したスタンプなどの描画
  • 組み込みを除く音楽の再生

などは正常に動作するようである。

これが、リソースを破壊した自分の IchigoCake の PanCake の起動時の画面である。

リソースを破壊した PanCake の起動時の画面

PC !RESUP! 01 を実行すると何が起こるか

PC !RESUP! 00 の前に、まずは PC !RESUP! 01 を試してみよう。
これは、PanCake のリソースを CakeRes内のリソースに切り替えるコマンドである。

ロジックアナライザで PanCake の SDA、SCL、TX、RX を監視した状態で、コマンドを実行する。
すると、以下のような結果が得られた。

PC !RESUP! 01 の実行の様子 (全体)

PC !RESUP! 01 コマンドを受け取ると、

'Starting resource update.
'

と出力し、処理を開始する。

PC !RESUP! 01 の実行の様子 1

進捗状況を表す . を出力しながら、7bitアドレス 0x51 のEEPROMの読み込みを試みている。
今回はEEPROMを接続していないので、失敗する。

PC !RESUP! 01 の実行の様子 2

16回EEPROMの読み込みを試みるごとに . を出力するようである。
これを10回行い、合計160回EEPROMの読み込みを試みる。

PC !RESUP! 01 の実行の様子 2

最後に、

'Completed!
'Please reset your PanCake.

と出力する。

PC !RESUP! 01 の実行の様子 3

PC !RESUP! 00 を実行すると何が起こるか

PC !RESUP! 01 の動作を見たので、次は「PanCake デフォルトのリソースへ戻す」とされていた PC !RESUP! 00 の動作を見てみよう。

PC !RESUP! 00 の動作 (全体)

あれ?さっきと同じ感じだけど、間違えて PC !RESUP! 01 を実行したかな?
いえいえ、これが PC !RESUP! 00 の挙動なのである。
そう、なぜか PC !RESUP! 01 とよく似ているのである。

PC !RESUP! 00 の挙動は、PC !RESUP! 01 の挙動とよく似ている!

PanCake に送信したコマンドは、間違いなく PC !RESUP! 00 である。

PC !RESUP! 00 の動作 1

EEPROMのアドレスが 0x51 から 0x50 になっている点が、PC !RESUP! 01 とは異なる。

PC !RESUP! 00 の動作 2

EEPROMを接続して実行してみる

現在、残念ながら CakeRes の入手は困難なようである。
CakeRes×レトロゲームズは販売終了となっており、その他の種類の CakeRes も発見できていない。

CakeRes×レトロゲームズ (M-13596)
を参照すると、同製品にはEEPROM「S-24CM01CI-J8T1U4」(秋月 I-11170) が使われているようなので、同EEPROMを入手し、接続した上で PC !RESUP! 00 を実行してみた。

実行するのは PC !RESUP! 00 である。01 ではない。

EEPROMを接続して PC !RESUP! 00 を実行

EEPROMを接続していないときは約16秒で実行が終わっていたが、接続した場合は約22秒に伸びた。
EEPROMの読み込みを行う分であると考えられる。

EEPROMを接続して PC !RESUP! 00 を実行 (全体)

アドレス 0x0000 から読み込みが始まっている。

EEPROMを接続して PC !RESUP! 00 を実行 2

次に読み込まれたのはアドレス 0x0100 である。
256バイトずつ読み込んでいると推測できる。

EEPROMを接続して PC !RESUP! 00 を実行 3

最後に読み込まれたのはアドレス 0x9f00 から始まるブロックである。

EEPROMを接続して PC !RESUP! 00 を実行 4

電源を切って入れ直すと、画面は一色になった。

リセット後の画面

EEPROMの初期値の 0xff をパレット内の灰色 (15) と解釈したため、こうなったと考えられる。

PC !RESUP! 00 はEEPROMを接続しても「デフォルトのリソースに戻す」動作はせず、EEPROMの内容に応じてリソースを書き換えていると推測できる!

再びEEPROMを外して実行

画面が灰色一色になった状態で再びEEPROMを外し、PC !RESUP! 00 を実行し、完了後電源を切って入れ直すと、以下の画面になった。

再びEEPROMを外して PC !RESUP! 00 を実行した結果

灰色が残っている部分、最初の画面に似た部分、どっちでもない部分がある。
さらに、灰色で塗られていない部分をよく見ると、同じようなパターンが繰り返されていることがわかる。
ここから、以下のことが推測できる。

  • PC !RESUP! は、EEPROMの内容を固定の位置のバッファに読み込み、それをリソースとして保存する操作を繰り返す。
  • このバッファの一部は他の処理にもよく利用され、他の部分はあまり利用されない。
  • EEPROMを接続せず、読み込みが失敗する場合、バッファの内容が書き変わらないため、リソースのデータが同じパターンの繰り返しとなる。

EEPROMを書き換え、ダメ押しの検証

以下のIchigoJamのプログラムにより、以下のようにEEPROMを書き換える。
書き換える際は、EEPROMをIchigoJam側に接続する。

  • 7bitアドレス 0x50 (PC !RESUP! 00 で参照される) には、0x01 0x23 0x45 0x67 を繰り返すパターンを書き込む。
  • 7bitアドレス 0x51 (PC !RESUP! 01 で参照される) には、0x89 0xAB 0xCD 0xEF を繰り返すパターンを書き込む。

※IchigoJamはjig.jpの登録商標です。

10 ' EEPROM S-24CM01C ライト
20 FOR I=0 TO 1
30 FOR K=0 TO #FF
40 POKE #700+K,#01+#22*(K%4)+#88*I
50 NEXT
60 FOR J=0 TO #9F
70 [0]=J
80 IF I2CW(#50+I,#800,2,#700,#100) THEN PRINT " WRITE ERROR":END
90 CLT
100 IF I2CR(#50+I,#800,0)=0 THEN GOTO 120
110 IF TICK()>=60 THEN PRINT " TIMEOUT":END
120 IF J%16=15 THEN PRINT J/16;
130 NEXT
140 NEXT
150 PRINT " DONE!"

このプログラムは、CC0 1.0 でライセンスする。

書き換えたEEPROMを再びPanCakeに接続し、まずは PC !RESUP! 01 を実行する。
完了後電源を入れ直すと、予想通り、パレットの8~fに対応する青や緑系の色が現れた。

書き換えたEEPROMで PC !RESUP! 01 を実行した結果

次に、PC !RESUP! 00 を実行する。
完了後電源を入れ直すと、パレットの0~7に対応する赤系の色が現れた。

書き換えたEEPROMで PC !RESUP! 00 を実行した結果

これで、PC !RESUP! 01 だけでなく、PC !RESUP! 00 も、EEPROM内のデータを読み込み、それに従ってリソースを書き換えていることが確定する。

PC !RESUP! 00 は、「PanCake デフォルトのリソースへ戻す」のではなく、リソースをEEPROM内のデータに従って書き換える!
PC !RESUP! 01 との違いは、参照するEEPROMのアドレスの違いだけと推測できる!

ちなみに、00 と 01 以外はどうなる?

いくつかのパラメータ xx について PC !RESUP! xx を実行した所、以下のアドレスのEEPROMの読み込みが行われた。

パラメータ EEPROMの7bitアドレス
02 0x50
03 0x51
04 0x50
05 0x51
10 0x50
80 0x50
FE 0x50
FF 0x51

パラメータの最下位ビットが 0 であれば7bitアドレス 0x50 を、1 であれば7bitアドレス 0x51 を参照すると推測できる。

PanCake C のバージョンを確認する

ここで、今回検証に使用してきたIchigoCake (PanCake C) のバージョンを確認する。
PanCake C には 1.2.0 と 1.2.1 があり、1.2.0 ではスプライト番号が小さい方が上に重なるはずである。
そこで、以下のプログラムでスプライトの表示を試してみる。

10 ' スプライト テスト
20 ?"PC SPRITE START 10"
30 ?"PC SPRITE USER FD 00 1111111111111111111111111111111111111111111111111111111111111111"
40 ?"PC SPRITE USER FE 00 2222222222222222222222222222222222222222222222222222222222222222"
50 ?"PC SPRITE CREATE 00 FD"
60 ?"PC SPRITE CREATE 01 FE"
70 ?"PC SPRITE MOVE 00 1E 0E"
80 ?"PC SPRITE MOVE 01 22 12"

このプログラムは、CC0 1.0 でライセンスする。

スプライト番号 00 で白い四角を、スプライト番号 01 で赤い四角を表示する。
実行結果は以下のようになった。

スプライト表示によるバージョンの判別

赤い四角が白い四角より上に描画されているので、バージョン 1.2.1 であると推測できる。

結論

PanCake C (IchigoCake) の PC !RESUP! 00 の効果が「PanCake デフォルトのリソースへ戻す」であるとするイチゴジャム レシピの記述は誤りである。
PC !RESUP! 00 の実際の効果は、PC !RESUP! 01 と同様に、EEPROM内のデータに基づいてリソースを書き換えることである。
PC !RESUP! 01PC !RESUP! 00 の違いは、参照するEEPROMのアドレスの違いだけであると推測できる。

PC !RESUP! 00 で参照される領域に PanCake のデフォルトのリソースに似たリソースが格納されているタイプの CakeRes を使用した場合は PC !RESUP! 00 によりリソースをデフォルトのものに似たものに切り替えることができる可能性があるが、これには以下の問題がある。

  • 本物のデフォルトのリソースに戻すことはできない。たとえば、起動時の画面に書かれているバージョン情報が破壊される(実際のバージョンと合わなくなる)可能性がある。
  • あくまで CakeRes に格納されているデータに基づいてリソースを書き換えているため、使用した作成物の公開が不可であるタイプの CakeRes を使用した場合はリソースを使用した作成物の公開が不可になると考えられる。
  • 使用した作成物の公開が不可であるタイプの CakeRes 由来のリソースであっても、デフォルトのリソースであると誤認してしまい、リソースを使用した作成物を誤って公開してしまうリスクが生じる。

最後に、大事なことなのでもう一度。

PC !RESUP! 00 で、リソースをデフォルトのものに戻すことはできない!
PC !RESUP! 01 も、リソースをCakeRes (EEPROM) 内のデータに従って書き換える!
PC !RESUP! xx は、CakeRes (EEPROM) を接続せずに実行してもエラーにはならず、リソースを適当に書き換える!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0