メモリマップ

BASIC 0.9.9-RC6、正式版では BASIC 1.0.0 より

POKE・PEEK・COPY などのコマンドを用いて仮想メモリへの参照・書き込みが可能になっています。

このページでは仮想メモリの詳細な説明を記載しています。

 

IchigoJam BASIC 0.9.9-RC11 に限り、メモリマップの構成が異なります。
IchigoJam BASIC 0.9.9-RC12 で戻されています。古いベータ版なので、0.9.9-RC11 は考慮していません。

 

RISC-V プロセッサの IchigoJam では一部メモリマップに違いがある事が分かっています。

現在のところ #1003 キーバッファ は別アドレスである事が分かっていて、その後のバッファも異なっている可能性があります。

 

IchigoCake BASIC は配列・プログラム領域が拡大されています。そのため、メモリマップが異なります。


仮想メモリのメモリマップ

アクセスできる仮想メモリのメモリマップは下のとおりです。

アドレスは 16 進数表記で記載していますが、10 進数表記でも正常に動作します。
1 つのアドレスで扱える値は 0〜255・#00〜#FF です。

 

IchigoJam BASIC(除 IchigoCake BASIC)

アドレス 内容
0#000 〜 0#7FF キャラクターパターン
0#800 〜 0#8CB 配列
0#8CC ~ 0#8FF 変数
0#900 〜 0#BFF 画面のキャラクター
0#C00 〜 #1001 (#FFF) プログラム
#1002 キー状態
#1003 〜 #1081 キーバッファ・受信バッファ(1.3b2 のみ #1003 ~ #1041)
#1082 ~ #1149 ラインバッファ(1.3.0・1.3b3 以降。1.3b2 は #1044 ~ #110B)
#114A ~ #117F I2C バッファ(1.3.0・1.3b3 以降。1.3b2 は #110C ~ #112B)

 

メモリマップの範囲は IchigoJam BASIC のバージョンによって異なります。次の範囲になっています。

基本的に使用するのは #000~#FFF(#000~#1001)となります。

そのため、最新ではアドレスが 16 進数 4 桁ですが、3 桁で表記するのが通常となっています。

 

IchigoJam BASIC バージョン (正式版)

IchigoJam BASIC バージョン (ベータ版) 有効なアドレスの範囲
1.0.0 ~ 1.0.1 0.9.9-RC6 ~ 1.1 beta 7 #000 ~ 0#FFF
  1.1 beta 8 ~ 1.1 beta 10 #000 ~ #100F
1.1.1 1.1 beta 11 ~ 1.2 beta 3 #000 ~ #101F
1.2.0 ~ 1.2.3 1.2 beta 4 ~ 1.3 beta 1 #000 ~ #1081
  1.3 beta 2 #000 ~ #112B
1.3.0 ~ 1.3.1 1.3 beta 3 ~ #000 ~ #117F
  1.5b1~ (RISC-V) #000 ~ 0#FFF

IchigoCake BASIC

配列とプログラムの領域が増えているため、その分仮想メモリがずれています。

IchigoCake BASIC 1.3b7.2・正式版 IchigoCake BASIC 1.3.2 で次のとおりです。

アドレス 内容
0#000 〜 0#7FF キャラクターパターン
0#800 〜 0#8CB 配列 [0]~[101]
0#8CC 〜 0#8FF 変数
0#900 〜 0#BFF 画面のキャラクター
0#C00 〜 0#DFF 配列 [102]~[357]
0#E00 〜 #1DFF (#1E01) プログラム
#1E02 キー状態
#1E03 〜 #1E81 キーバッファ・受信バッファ
#1E82 ~ #1F49 ラインバッファ
#1F4A ~ #1F7F I2C バッファ

HELP コマンド

これらのメモリマップは HELP コマンドを用いて表示できます。

HELP コマンドは BASIC 1.0.1 以降で使用できます。バージョンによって記載が異なります。
正式版 BASIC 1.1.1 以降はアドレスの先頭のみになっています。

ベータ版では容量の都合により、短くなったり、非対応(エラー)となる場合があります。

 



キャラクターパターン

CHR$(0) から CHR$(255) までの全キャラクターパターンを参照できます。

この領域は IchigoCake BASIC も共通です。

 

アドレス キャラクターコード 縦位置
#000 00CHR$(0) ( CHR$(#00) ) 上から 1 行目
#001 00CHR$(0) ( CHR$(#00) ) 上から 2 行目
#002 00CHR$(0) ( CHR$(#00) ) 上から 3 行目
#003 00CHR$(0) ( CHR$(#00) ) 上から 4 行目
#004 00CHR$(0) ( CHR$(#00) ) 上から 5 行目
#005 00CHR$(0) ( CHR$(#00) ) 上から 6 行目
#006 00CHR$(0) ( CHR$(#00) ) 上から 7 行目
#007 00CHR$(0) ( CHR$(#00) ) 上から 8 行目
#008 00CHR$(1) ( CHR$(#01) ) 上から 1 行目
:
#7FE CHR$(255) ( CHR$(#FF) ) 上から 7 行目
#7FF CHR$(255) ( CHR$(#FF) ) 上から 8 行目

 

8 バイトで 1 キャラクターを構成します。0・#000 がキャラクターコード 0・#00 のキャラクターなので、
単にキャラクターコードに 8 をかける事でキャラクターパターンの先頭アドレスを得られます。

例えばキャラクターコード 255・#FF のイチゴを参照する場合は 255✕8=2040=#7F8 で、

このアドレスからの 8 バイト 2040~2047・#7F8~#7FF がイチゴのキャラクターパターンです。

 

アドレス(先頭はコード✕8)                 値(白い部分の和)
2040・#7F8 128 64 32 16 8 4 2 1 004 = 4
2041・#7F9 128 64 32 16 8 4 2 1 062 = 32+16+8+4+2
2042・#7FA 128 64 32 16 8 4 2 1 047 = 32+8+4+2+1
2043・#7FB 128 64 32 16 8 4 2 1 086 = 64+16+4+2
2044・#7FC 128 64 32 16 8 4 2 1 106 = 64+32+8+2
2045・#7FD 128 64 32 16 8 4 2 1 214 = 128+64+16+4+2
2046・#7FE 128 64 32 16 8 4 2 1 172 = 128+32+8+4
2047・#7FF 128 64 32 16 8 4 2 1 240 = 128+64+32+16

 

PCG として POKE などでキャラクターの書き換えができるのは

キャラクターコード 224〜255・#E0〜#FF にある 32 文字の領域 #700〜#7FF に限られます。

キャラクターコード 0~223・#00~#DF の領域 #000〜#6FF は

PEEK で参照できますが、POKE で変更する事はできません。COPY も同様です。


配列

2 バイトで配列 1 つを構成します。#800 と #801 が [0] の値で、#8CA・#8BB の [101] まで並んでいます。

頭が下位 8 ビット、次が上位 8 ビット(リトルエンディアン)の 16 ビットで、

一番上位のビットが符号ビットになります。

 

アドレス 配列 上位・下位
#800 00[0] 下位 8 ビット 
#801 00[0] 上位 8 ビット
#802 00[1] 下位 8 ビット
:
#8C9 [100] 上位 8 ビット
#8CA [101] 下位 8 ビット
#8CB [101] 上位 8 ビット

 

IchigoJam BASiC 1.2 IoT 版は IoT.IN・IoT.OUT コマンドの実行時にこの領域を使用してモジュールの送受を行います。

この領域が破壊されますので、使用しないで下さい。 BASIC 1.3 では専用の領域ができています。

 

IchigoCake BASIC では [102]~[357] が増えています。#C00 以降で割り当てられています。
従ってプログラム以降の領域は IchigoCake BASIC と IchigoJam BASIC でアドレスが異なります。

 

アドレス 配列 上位・下位
#C00 [102] 下位 8 ビット 
#C01 [102] 上位 8 ビット
#C02 [103] 下位 8 ビット
:
#DFD [356] 上位 8 ビット
#DFE [357] 下位 8 ビット
#DFF [357] 上位 8 ビット

変数

2 バイトで変数 1 つを構成します。#8CC と #8CD が変数 A の値で、#8FE・#8FF の変数 Z まで並んでいます。

頭が下位 8 ビット、次が上位 8 ビット(リトルエンディアン)の 16 ビットで、

一番上位のビットが符号ビットになります。

 

この領域は IchigoCake BASIC も共通です。

 

アドレス 変数 上位・下位
#8CC A 下位 8 ビット
#8CD A 上位 8 ビット
#8CE B 下位 8 ビット
:
#8FD Y 上位 8 ビット
#8FE Z 下位 8 ビット
#8FF Z 上位 8 ビット

画面のキャラクター

画面左上(LOCATE の座標で 0,0)を #900 として、右へ向かって右下までキャラクターの参照・配置を行います。

値はキャラクターコードです。0~31 と 127 は CHR$() とは異なりキャラクターを出力します。

POKE でのキャラクター配置はビデオ出力・液晶モジュールへの表示が有効で、シリアルへは送出しません。

 

この領域は IchigoCake BASIC も共通です。

 

VIDEO 1・2 / IchigoJam BASIC 0.9.9-RC 以降のデフォルト画面サイズ

アドレス 横座標 縦座標
#900 00 00
#901 01 00
:
#91F 31 00
#920 00 01
:
#BFE 30 23
#BFF 31 23

VIDEO1・2 は 32✕24 文字です。(横座標 0~31・縦座標 0~23)

 

画面左上(LOCATE の座標で 0,0)が #900 なのは VIDEO による画面モードを変更しても共通です。

従って VIDEO 3~8 では後方のアドレスが使用されない事になります。

CLS や VIDEO などの画面クリアではその画面で使用される範囲の値が 0 クリアされます。

画面外の領域はクリアされません。この領域は別の目的で使用可能です。

 

VIDEO 3・4 / IchigoJam BIG

アドレス 横座標 縦座標
#900 00 00
#901 01 00
:
#90F 15 00
#910 00 01
:
#9BE 14 11
#9BF 15 11

VIDEO 3・4 は 16✕12 文字です。(横座標 0~15・縦座標 0~11)

VIDEO 1・2 の縦・横共に文字サイズ 2 倍、座標は半分となっています。

IchigoJam BIG も同じ画面サイズになります。

 

VIDEO 5・6

アドレス 横座標 縦座標
#900 0 0
#901 1 0
:
#907 7 0
#908 0 1
:
#92E 6 5
#92F 7 5

VIDEO 5・6 は 8✕6 文字です。(横座標 0~7・縦座標 0~5)

VIDEO 3・4 の縦・横共に文字サイズ 2 倍、座標は半分、VIDEO 1・2 の縦・横共に文字サイズ 4 倍、座標は 4 分の1 となっています。

 

VIDEO 7・8

アドレス 横座標 縦座標
#900 0 0
#901 1 0
#902 2 0
#903 3 0
#904 0 1
:
#90A 2 2
#90B 3 2

VIDEO 7・8 は 4✕3 文字です。(横座標 0~3・縦座標 0~2)

VIDEO 5・6 の縦・横共に文字サイズ 2 倍、座標は半分、VIDEO 3・4 の縦・横共に文字サイズ 4 倍、座標は 4 分の1、

VIDEO 1・2 の縦・横共に文字サイズ 8 倍、座標は 8 分の 1 となっています。


プログラム

プログラムの入力により IchigoJam BASIC は #C00 から、IchigoCake BASIC は #E00 から入ります。

例えば 10 CLS というプログラムではじまり、次が 20 になる場合、下記のようになります。

 

IchigoJam BASIC
アドレス
IchigoCake BASIC
アドレス
解説
#C00 #E00 10 行番号 下位 8 ビット・10 の下位 8 ビットは 10
#C01 #E01 00 行番号 上位 8 ビット・10 の上位 8 ビットは 0
#C02 #E02 04 文字数 (終了コード 0 を含む)・4 文字 ※
#C03 #E03 67 C のキャラクターコード
#C04 #E04 76 L のキャラクターコード
#C05 #E05 83 S のキャラクターコード
#C06 #E06 00 行の終了コード
#C07 #E07 00 アドレス調整
#C08 #E08 20 行番号 下位 8 ビット・20 の下位 8 ビットは 20
:

※ 文字数部分は「2 バイト」と公開されているところがありますが、正しくは「1 バイト」です。

 

行番号は必ず偶数のアドレスではじまります。下位 8 ビット・上位 8 ビットの順(リトルエンディアン)です。

例えば、行番号 1 と 10000 では共に 2 バイトを固定使用するため、容量は変わりません。 

 

行の終了コードは #00 の 1 バイトですが、

ここで次のアドレスが奇数になっている場合、補正のためにもう 1 バイト #00 を含めます。

これは LPC1114 が 2 バイトずつ処理しているため、調整を行っています。

この仕様により、?FREE() などで見る場合、必ず偶数のバイト数が返ってきます。

 

IchigoJam BASIC ではプログラム終了から #FFF までは #00 が続きますが、

プログラムが 1024 バイトになる場合、終了コードははみ出します。

IchigoJam BASIC 1.1 beta8 (正式版 IchigoJam BASIC 1.1.1) より

この終了コードは #1000〜#1001 に入りますが、

必ず固定値 #00 となるので、保存・読み出しの対象になっていません。

IchigoCake BASIC の場合 #1E00~#1E01 が固定値 #00 になります。

 

SAVE でプログラムの内容がそのまま保存領域(LPC1114・LPC1115 または EEPROM)へ写され、

また LOAD・LRUN では保存領域からプログラムへそのまま写されます。

IchigoJam BASIC RPi ではプログラムの内容がそのままバイナリーファイルで SD カードへ保存されます。

これを活用し、プログラムの空き領域に POKE でデータなどを入れ、SAVE でプログラムと一緒に保存させる事が可能です。


キー状態

IchigoJam BASIC では #1002、IchigoCake BASIC では #1E02 に

矢印キーとスペースキーの押した状態が入っています。キー同時押しの検出が可能です。

例えば IchigoJam BASIC の場合、IF PEEK(#1002)=0 で矢印キーとスペースキーが押されていないかを確認できます。

 

BASIC 1.4.0・1.3.2b17 よりこの値は BTN(-1) で得る事ができます。

 

値 (同時押しの場合は和の値)

キー
01 (`00000001) ← 矢印左キー
02 (`00000010) → 矢印右キー
04 (`00000100) ↑ 矢印上キー
08 (`00001000) ↓ 矢印下キー
16 (`00010000) SPACE スペースキー
32 (`00100000) 英大 X キー(1.4.0b5~、英小・カナ不可)

 

IchigoCake BASIC 1.3.2 では #1E02 の値がクリアされていないため、不正確な値で検出される場合があります。
(32 以上の値を得る場合があり、BTN(~) も状態とは異なる値で返す場合があります)

こちら不具合と確認され、後のバージョンで改善される予定です。回避手段として POKE #1E02,0 とゼロクリアして下さい。


キーバッファ・受信バッファ

キーボードからの入力により、この領域へ参照していない文字を蓄えます。
INKEY() などで消費します。CLK でクリアが可能です。

また、シリアルから受け取ったデータの蓄えにも使用されます。

 

IchigoJam BASIC では #1003 にバッファに入っている文字数が入り、
#1004 以降がバッファとしてキャラクターコードが入ります。

#1003 が 5 であれば、#1004~#1008 の 5 文字がバッファとして入っています。

IchigoCake BASIC では #1E03 にバッファに入っている文字数、#1E04 以降がバッファとなります。

 

処理高速化の考慮で、バッファから取り出した場合でも、#1004 または #1e04 以降の内容はクリアされません。

#1003 または #1E03 の値を 0 にするだけです。
参照する場合は必ず #1003 または #1E03 の文字数を参照して下さい。


ラインバッファ

BASIC 1.3.0・1.3b2 で追加されています。200 文字です。

Enter(return)を押した際、その行を一時的に収納し処理します。
BASIC 1.2.3・1.3b1 までは画面のキャラクター領域をそのまま使っていたため、
CLS:PRINT"HELLO! では PRINT は実行されませんが、

BASIC 1.3.0・1.3b2 以降では表示されるようになっています。


I2C バッファ

BASIC 1.3.0・1.3b2 で追加されています。IoT.IN・IoT.OUT コマンドで I2C 送受に使用します。

BASIC 1.2 IoT 版では配列領域を使っていたため、IoT.IN・IoT.OUT の実行で破壊されていましたが、

BASIC 1.3.0・1.3b2 以降ではこれがなくなっています。

 

BASIC 1.4.0・1.3.2b17 より EEPROM のアクセス時にも I2C バッファを使用します。