UART 4 について書き込まれた不適切な記述がいまだに消えない件と、その他の問題点

2023年7月15日、リポジトリ
[GitHub - fu-sen/IchigoJam-BASIC: 🍓🅱️ IchigoJam BASIC コマンド一覧 command reference (Japanese)](https://github.com/fu-sen/IchigoJam-BASIC)
で見つけた問題点を Issues として投稿していたところ、いきなり**事実に反する、または反する可能性が高いと考えられる**主張を**一方的に連投**された上、あげくのはてに**情報を破損させようとしている呼ばわり**された上**反論を書き込めない不都合が発生する**という事件が発生しました。
この事件の2日前、別の Issue を投稿したところ、「このとおりに反映いたしました」と称してほとんどが**投稿の内容に合わない**、かつ**正しかった記述を誤りへと書き換える**修正が行われたため、これを**エビデンスとともに**再指摘する Issue での出来事でした。

あれから5ヶ月、いまだに **Issue の新規投稿や返信、さらに Pull Request のための fork すらもできない不都合**が続いています。
しかも、前の Issue への反応として追加された誤りの一部は、今もそのまま残っています。
なるべく早く**不都合の解消と誤りの修正**がなされることを望みます。

# 事件に関係するページ

## 事件前の Issue

* [FILE の説明が事実と異なる · Issue #3 · fu-sen/IchigoJam-BASIC · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/issues/3)
* [I2CR・I2CW の返り値の説明が無い · Issue #4 · fu-sen/IchigoJam-BASIC · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/issues/4)
* [位置の計算式がおかしい · Issue #5 · fu-sen/IchigoJam-BASIC · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/issues/5)
* [UART typo? · Issue #6 · fu-sen/IchigoJam-BASIC · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/issues/6)

どれも素直に修正していただけました。
#3 と #4 については、様々なバージョンで検証する、様々な資料を調査するなど、コストが高い検証も行っていただけたような記述があります。
さらに「ご報告ありがとうございます。」「報告ありがとうございます。」「ありがとうございます。」という感謝の言葉もあります。

## 誤りの追加がなされるきっかけとなった Issue

[UART の記述が 1.4.1 の挙動と異なる · Issue #7 · fu-sen/IchigoJam-BASIC · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/issues/7)

見直してみると、短文による現状の指摘とログが貼られているのみで、「どう直すべきか」が書かれていません。
これは、自分の至らなかった点であると考えます。

しかし、どう直すべきかがわからないのであれば**聞いてくれればいい**のであって、いきなり**正しい部分を誤りに書き換えた**上で、「このとおりに反映いたしました」という**誤った主張**をしていい理由にはならないと思います。

とはいえ、この時点では「細かく調査していただき、ありがとうございます。」とも書かれており、まだ Issue に対して好意的であるように感じました。

## 実際に誤りを追加したコミット

[記載修正 (issue #7) · fu-sen/IchigoJam-BASIC@bf7a522 · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/commit/bf7a52260909f821ff88753ac7a26a28843ca95a)

正しい「改行コード LF」という記述のほとんどが、「改行コード CR」という誤った記述に書き換えられています。
(なぜか送信モード 10 についてのみ、書き換えを免れています)

さらに、送信モード 4 について、「画面表示を行わない」という誤った記述が追加されています。
送信モード 4 では、`PRINT` した内容を**UARTには**出力しませんが、ビデオや液晶の画面には**出力します**。
この「画面表示を行わない」という表現は送信モード 8 でも使用されており、「画面」とは「シリアル送出」ではないもの、すなわちビデオや液晶の画面のことを指していると考えられます。
改行コードについてはその後修正していただけましたが、この誤りについてはいまだに修正していただけていません。

## 事件現場

[UART の記述が 1.4.1 の動作と異なる · Issue #8 · fu-sen/IchigoJam-BASIC](https://github.com/fu-sen/IchigoJam-BASIC/issues/8)

`UART 4` の実行後も液晶の画面に `PRINT` した内容が出力されること、および改行コードは CR ではなく LF が出力されることを、エビデンスとともに指摘しました。

すると、**1日も経たない短時間のうちに**一方的な主張が行われ、**返信の書き込みができない不都合**が発生しました。
しかも、Pull Request を要求しているかのような投稿もあるにもかかわらず、**Pull Request のための fork もできない不都合**も発生しています。
自分は指摘後一旦GitHubを離れ、**次に戻ってきたときには既にこの状態でした。**
**あまりにも早い凶行**に、激しい怒りを覚えました。

## 事件に対するお気持ち表明

[Issueの対応が早くていい奴だと思っていたら裏切られた｜みけCAT](https://note.com/mi_ke_cat/n/nb8488123baa3)

事件の発覚後から書き始め、翌日の昼頃に投稿した記事です。
事件の経緯、相手の主張の問題だと思う点、相手がかわりに取るべきだったと考えられる行動の案などを記載しています。

ただし、返信などができない不都合について「ブロックされた」と決めつけてしまっているのは、自分の反省点です。

# 事件の凶悪ポイント TOP3

ここでは、この事件で自分が特にひどいと思ったポイントを紹介します。

## 1位：エビデンスに基づく改善のための指摘をしているだけなのに、情報を破損させようとしている呼ばわりされた

相手はこんな主張をしてきました。

> なお、このテキストは私が製作・公開していますが、長年様々な人が製作した仕様書や実際の検証により、ここまで積み上げられてきたものです。つまりは私のものではなく、IchigoJam にたずさわる皆さんの努力によってここまでの形になったものです。この情報を一個人によって異なるからと issues を建て破損させようとしている状況にあります。

私は、これに対し**非常に憤り**を感じました。

私は、実機を用いた**検証をした上**で、ログや画面写真といった**エビデンスとともに**指摘を投稿しました。
すなわち、自分も「**皆さん**」の一員として、規模は小さいかもしれないとはいえ「**努力**」をし、「**積み上げ**」に協力をしようとしただけなのです。

一方、相手は**勝手に、自分の指摘に反して**正しい記述を誤った記述に書き換えました。
ということは、**破損させようとしている**のはむしろ相手のほうです。
Issueを立てることで相手が**勝手に作った**ルールの引き金を引くきっかけになった可能性はありますが、**そんなものは知りません。**

にもかかわらず、自分のことを「**一個人**」というバカにしているとも捉えられる表現で指し、**破損させようとしている**呼ばわりしてくるというのは、**非常に許しがたく思います。**
**侮辱**にあたるのではないか、とすら思いました。

## 2位：事実に反するものを含む主張をいきなり一方的にされた上、反論が書き込めない不都合が発生した

指摘を書き込んでから次に自分が様子をチェックするまでという**短い間**に、**事実に反するものを含む**多くの書き込みがなされ、さらにそれらに対する**自分の反論が書き込めなくなるという不都合**が発生しました。
書き込みの中には Pull Request を求めているように見えるものもありましたが、残念ながら Pull Request のための **fork もできなくなる不都合**も発生しました。
かわりにnoteに反論を書きましたが、見ていただけるかはわかりません。
GitHubのサポートへの連絡もしましたが、どうやら効果は無かったようです。

相手の主張の中には「感じがします」「しっくりきます」といった主観的なものなど、正確な真偽はわからないものも多いですが、**明確に事実に反し、かつ一方的**で、**非常に不快**だった主張が1件ありました。
それがこれです。

> > モード4において、「画面表示を行わない」と書かれていますが、液晶 (SWITCH 1) を用いて確認したところ、PRINTした内容が画面に出力されました。
>
> これについては UART とは関係なく、SWITCH の仕様なので、issues の対象外です。これは無視されます。

「これ」すなわち「モード4において、PRINTした内容が画面に出力される」ということが「**UART とは関係なく、SWITCH の仕様**」だという、**直感的にもおかしく**、かつ**実験でも否定される**、**明確に事実に反する主張**をしています。
さらに、この**明確に事実に反する**根拠をもとに、「**これは無視されます**」という**一方的な主張**をしています。
そもそも、無視**される**のではなく、お前が自らの判断で無視**する**んですよね？
**大変不愉快です。**

## 3位：最初は Issue に誠実に対応していただけていたようだったのに、いきなり豹変された

このリポジトリは最終更新がだいぶ前だったので、最初に Issue を立てたときは立てても放置されるかなと思いました。
しかし、実際に Issue を立ててみると、素早く、しかも**礼儀正しく丁寧**な対応をしていただけました。
少なくとも、自分はそう感じました。
のちに一方的な主張をいきなりしてくるとは、本当に夢にも思いませんでした。
その後も数件 Issue を立て、いずれも同じように素晴らしいと感じる対応をしていただけました。

しかし、事件現場となる1個前の Issue では、これまでとはうってかわって、指摘内容に反して**実験をすればすぐにわかるような嘘**をリポジトリに書き込むという対応をされました。
これはおかしいことであり、ここで手を引くという選択肢もあったかもしれません。
しかし、「異変を見つけたら、すぐに引き返す」[８番出口](https://store.steampowered.com/app/2653790/_/?l=japanese)のリリースから4ヶ月以上も前であり、リポジトリに書き込まれた嘘を放置するのは良くないと思ったので、再指摘を行いました。
すると、今度は一旦は Pull Request を要求しているように見える投稿がなされたものの、**すぐに手のひらを返し**、「UARTのモード4においてPRINTした内容が画面に出力されるのはUARTとは関係なくSWITCHの仕様」という**デタラメ**を含む主張が**一方的になされ**、Pull Request のための **fork ができない不都合が発生**しました。

> 今 IchigoJam に時間をさける状況ではない

> また連続した issues により、私の活動時間を奪われており、悪影響を受けている状況でもあります。

という主張もなされていますが、時間が無いのであれば**Issue を無視**すればいいだけでしょう。
無視はできないという**こだわりがある**のであれば、素直に「時間が無いため対応できません」などと書いてクローズすればいいでしょう。
READMEなどで**更新停止・更新頻度減を宣言**したり、[**リポジトリをアーカイブ**](https://docs.github.com/ja/repositories/archiving-a-github-repository/archiving-repositories)したりするという選択肢もあるでしょう。
**いきなり**このような**一方的な主張**をまくしたて、(したと断定はできませんが) 一旦は Pull Request を要求するかのようなそぶりを見せながら**即手のひらを返してブロックする**という**個人攻撃**をしていい理由にはならないと考えます。
もちろん、レポジトリに嘘を書き込んでいい理由にもならないでしょう。

# UART 4 の動作が SWITCH とは関係ないことを再検証

手元にある以下のバージョンにおいて、あらためて UART 4 の動作は SWITCH とは関係ないことを確認しました。

* 1.3.1 / IchigoJam S
* 1.4.1 / IchigoKamuy
* 1.4.3 / IchigoJam Q
* 1.5b / IchigoJam R
* 1.4.1D2 / IchigoDake
* 1.5.0D / GIGA IchigoDake
* 1.4.1 / IchigoCake

具体的には、以下のコマンド列を実行しました。

```
PRINT 1
UART 4
PRINT 2
UART 13
PRINT 3
SWITCH 1,22
PRINT 4
UART 4
PRINT 5
```

ここに含まれる `PRINT` コマンドは、それぞれ以下の条件で実行されます。

|PRINT|UART 設定|SWITCH 設定|
|---|---|---|
|`PRINT 1`|初期状態|初期状態|
|`PRINT 2`|`UART 4`|初期状態|
|`PRINT 3`|`UART 13`|初期状態|
|`PRINT 4`|`UART 13`|`SWITCH 1,22`|
|`PRINT 5`|`UART 4`|`SWITCH 1,22`|

以下が、実際の実験の様子です。

<iframe width="560" height="315" src="https://www.youtube.com/embed/vnBaSfne7Hk?si=hONA1qhQrXUSTQGv" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

それぞれの `PRINT` コマンドによって画面 (ビデオまたは液晶) に表示されるかは、以下のようになりました。
(ビデオ：ビデオ画面へ表示 / 液晶：TFT液晶画面へ表示 / なし：表示されず)

|PRINT|1.3.1|1.4.1|1.4.3|1.5b|1.4.1D2|1.5.0D|1.4.1 (Cake)|
|---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|`PRINT 1`|ビデオ|ビデオ|ビデオ|ビデオ|ビデオ|ビデオ|ビデオ|
|`PRINT 2`|ビデオ|ビデオ|ビデオ|ビデオ|ビデオ|ビデオ|ビデオ|
|`PRINT 3`|ビデオ|なし|なし|ビデオ|-|ビデオ|なし|
|`PRINT 4`|液晶|なし|なし|ビデオ|なし|ビデオ|なし|
|`PRINT 5`|液晶|液晶|液晶|ビデオ|ビデオ|ビデオ|液晶|

今回実験を行った全てのバージョンにおいて、同じ `UART 4` の実行後である `PRINT 2` と `PRINT 5` で画面に表示されるかどうかは一致しています。
また、同じ `UART 13` の実行後である `PRINT 3` と `PRINT 4` で画面に表示されるかどうかも一致しています。
(1.4.1D2 では `PRINT 3` の実験を行うのを忘れてしまいましたが、`UART 13` に対する `OK` は表示されなくなっているのが確認でき、`PRINT` でも同様に出力されないと推測できます)

したがって、少なくとも `UART 4` および `UART 13` の実行後に画面 (ビデオまたは液晶) への出力が行われるかどうかは、`SWITCH 1,22` を実行したか否かにかかわらず同じであることがわかります。
よって、`UART` の動作は `SWITCH` とは関係ないと推測できます。

# UART 4 に関する説明をあらためて見返してみて

これが、事件の直前、UART 4 で「画面表示を行わない」という嘘が書き込まれたときの UART 4 の説明です。
[IchigoJam-BASIC/UART.txt at bf7a52260909f821ff88753ac7a26a28843ca95a · fu-sen/IchigoJam-BASIC · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/blob/bf7a52260909f821ff88753ac7a26a28843ca95a/UART.txt)

> 4 画面表示を行わない、エコーバックあり
>   （1.2b63（正式版 1.3.0）～）
>   PRINT のみ送出、エコーバックあり（1.2b62 のみ）

そしてこれが、さらにその直前、この嘘が書き込まれる前の UART 4 の説明です。
[IchigoJam-BASIC/UART.txt at f67d98f315dbf77a4b7eb9cf60c9b859fe3c8dfe · fu-sen/IchigoJam-BASIC · GitHub](https://github.com/fu-sen/IchigoJam-BASIC/blob/f67d98f315dbf77a4b7eb9cf60c9b859fe3c8dfe/UART.txt)

> 4 PRINT のみ送出、エコーバックあり、改行コード CR
>   （1.2b63（正式版 1.3.0）～）
>   PRINT のみ送出、エコーバックあり、改行コード CR（1.2b62 のみ）

よく見ると、「1.2b63（正式版 1.3.0）～」と「1.2b62 のみ」という異なるバージョンについて、「PRINT のみ送出、エコーバックあり、改行コード CR」という全く同じ記述がされている、不自然な表現になっています。
となると、「1.2b63（正式版 1.3.0）～」において「画面表示を行わない」というのは誤りであっても、「1.2b62 のみ」においては「画面表示を行わない」可能性が考えられそうであることに気付きました。

1.2b62 や 1.2b63 における UART 4 については、以下のページに記述がありました。

[IchigoJamをパソコンにつなぐシリアルモードまとめ＆エコーバックモード追加 1.2β62](https://fukuno.jig.jp/2242)

> シリアル送信ON (キー入力などのエコーバックモード) [new!] 1.2b62

[はじめてのIoTプログラミング with ZenIT ペアプログラミングバージョン](https://fukuno.jig.jp/2262)

> シリアル送信ON (キー入力のエコーバックのみ) [new!] 1.2b63

しかし、これらのページの記述はいずれもシリアル送信の制御に関するもののみであり、PRINT などによる画面への出力を抑制する、といった話は出てこないようです。
さらに、モード5～7についても似た表現になっており、モード4のみ画面への出力を抑制する、というのは不自然に思えます。
したがって、該当バージョンのファームウェアを実際に実行して試していないので断定はできませんが、「1.2b62 のみ画面表示を行わない」という可能性も低そうだと考えられます。

とはいえ、1.2b62 では「エコーバックモード」、1.2b63 では「エコーバックのみ」と表現が変わっています。
ということは、1.2b62 ではモード4でも (エコーバックに加え) PRINTの内容がUARTに出力され、1.2b63 ではPRINTの内容はUARTに出力されない、という可能性は考えられます。
もし、送信モード4で追加された「画面表示を行わない」というのがこのこと (モード4ではPRINTの内容を**UARTに**出力しないこと) を指しているのだとすれば、嘘だとまではいえないかもしれません。
そうだとしても、「画面表示を行わない」という表現は送信モード8の「シリアル送出および**画面表示を行わない**」(ビデオや液晶の画面に表示しない、VRAMへの書き込みを行わない) と被り、**誤解を招く表現**であるため、変更するべきだと思います。

# その他の問題点

ここでは、事件現場となったリポジトリで発見したその他の問題点を、Issuesのかわりにここに掲載します。

## 内容が誤っていると思われるもの

### CHR$ の説明が不適切

[CHR$ の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/CHR%24.txt)に

> CHR$ を使用する多くは PRINT になるでしょう。

と書かれています。
一方、たとえば [HEX$ の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/HEX%24.txt)を見ると、

> HEX$ の使用は PRINT で使う事になります。

と書かれています。

ここで、
[IchigoJam BASIC リファレンス ver 1.4](https://ichigojam.net/IchigoJam-1.4.html)
を見てみると、`CHR` の解説は

> PRINT内で、文字コードに対応する文字を返す（コンマ区切りで連続表記可）

`HEX` の解説は

> PRINT内で、数を16進数の文字列にする（２番目の数は桁数、省略可）

となっており、同様の「PRINT内で」という表現が使われています。
そのため、`CHR$` も `HEX$` も `PRINT` (`?` を含む) 内でのみ使う機会があると考えられ、それ以外の有効な活用法がありそうな「多くは」という表現は不適切であると考えられます。

### COPY の解説の誤りと表現の不統一

[COPY の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/COPY.txt)において、

> 仮想メモリ領域の &lt;転送元&gt; から &lt;転送先&gt; へ
> &lt;転送数&gt; バイト転送を行います。
> &lt;転送元&gt;→&lt;転送先>、&lt;転送先&gt;＋1→&lt;転送先&gt;＋1、……
> とコピーしていきます。

とありますが、「&lt;転送**先**&gt;＋1→&lt;転送先&gt;＋1」ではなく「&lt;転送**元**&gt;＋1→&lt;転送先&gt;＋1」が適切であると考えられます。

また、この部分以外では「転送元/先」のかわりに「領域元/先」という表現が使用されており、どちらかに統一したほうがいい可能性があります。

### DAC の書式の誤り

[DAC コマンド](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/DAC.txt)において、

> [ コマンド 書式 ]
> DAC(&lt;端子&gt;,&lt;値&gt;)
>
> [ 例 ]
> DAC(9,1023)

とありますが、この丸括弧は余計であり、実機でつけると Syntax error になりました。
丸括弧をつけない `DAC <端子>,<値>` および `DAC 9,1023` が正しいと考えられます。

![DAC 実験](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/4d21a1df-01f9-1110-2512-ce3a64ea4744.png)

### KBD における上書き先の誤り

[KBD の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/KBD.txt)において、

> SD カードに入れるファイル keymap.txt で設定も可能です。
> また KBD コマンドで kapmap.txt は上書きされます。

とあります。一方、
[IchigoJam BASIC RPi1.2 ドキュメント](https://ichigojam.github.io/RPi/index_ja.html)
では、

> KBD 	キーボードのキーマップの切り替え(※2)
>
> ※2 ver1.2.5以降、KBDコマンドで keymap.txt にも設定が保存されます。 

とあります。
よって、KBD コマンドで上書きされるのは `kapmap.txt` ではなく `keymap.txt` であると考えられます。

## 内容が足りないと思われるもの

### HELP の出力内容の誤り (網羅不足)

[HELP の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/HELP.txt)において、

> 1.2 以降は下記の内容となります。
>
> MEM MAP
> #000 CHAR
> #700 PCG
> #800 VAR
> #900 VRAM
> #C00 LIST

とありますが、以下に挙げる手元にある1.2以降のバージョンすべてにおいて「MEM MAP」が表示されなかったため、「1.2 以降は下記の内容となります」というのは誤りです。

* 1.3.1
* 1.4.1
* 1.4.1D2 (各アドレスも含め何も出力されず)
* 1.4.3
* 1.5b
* 1.5.0D

さらに、

> IchigoCake BASIC は下記の内容となります。
>
> MEM MAP
> #000 CHAR
> #700 PCG
> #800 VAR
> #900 VRAM
> #C00 VAR2
> #E00 LIST

とありますが、IchigoCake BASIC 1.4.1 では「MEM MAP」は出力されなかったため、「IchigoCake BASIC は下記の内容となります」というのも誤りです。

なお、1.0.0 では「MEMORY MAP」が出力されたため、この解説に記載されている「MEM MAP」は解説用の文字列ではなく、実際に出力される内容であると解釈するのが妥当であると考えられます。

<details><summary>各バージョンでの出力内容</summary>

![1.0.0 における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/b2cda5ba-4a16-d167-603a-a90412ff48ff.png)
![1.3.1 における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/13370510-ad30-a96b-2848-d382fb78b37a.png)
![1.4.1 における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/0443e864-4fd0-dbc8-6ff5-fdd42f3661cd.png)
![1.4.1D2 における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/9ee2fbd8-528d-191c-ce20-820134d7b7e6.png)
![1.4.3 における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/3247a56a-41cd-4605-07e3-33c14f771f73.png)
![1.5b における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/557c8573-2ec8-0fe5-c57b-00e42a1da32d.png)
![1.5.0D における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/b9e74a93-7500-fbf5-fbbc-91536b56a7d7.png)
![IchigoCake BASIC 1.4.1 における HELP](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/1232b051-44e5-d062-f2c1-8a594348d9c4.png)

</details>

### I2CR・I2CW の1バイトコマンドについて書かれていない

`I2CR` および `I2CW` コマンド (1.3系～？) では、コマンドの長さを省略することで、1バイトのコマンドを、アドレスではなくデータを直接指定して送信することができるようです。
しかし、[I2CR のページ](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/I2CR.txt) および [I2CW のページ](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/I2CW.txt) には、このことが書かれていないようです。

### PRINT におけるコンマに言及が無い

`PRINT` 文では、データをコンマで区切って指定することで、複数のデータをタブ区切りで出力できます。
この機能は、少なくとも 1.0.0 では使用可能なようです。
しかし、[PRINT のページ](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/PRINT.txt)には、書式・解説ともにこのことへの言及が全く無いようです。

![1.0.0 の PRINT でコンマを使う](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/7289e0c7-061c-4152-859c-1d8746038589.png)

### TEMPO の解説が誤解を招く

[TEMPO の機能](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/TEMPO.txt)には、

> PLAY のテンポを指定します。

とあります。
この表現からは、`TEMPO` でテンポを指定しておけば、その後の `PLAY` におけるテンポの初期値として使用されるかのような印象を受けました。

しかし、
[IchigoJam BASIC リファレンス ver 1.4](https://ichigojam.net/IchigoJam-1.4.html)
を見ると、`TEMPO` の解説は

> 再生中の音楽のテンポを変更する

となっており、これは [IchigoJam BASIC リファレンス 1.0](https://ichigojam.net/IchigoJam-1.0.html) でも同様です。

さらに、実際に実機 (1.4.3) で以下の手順で試してみました。
まず、

```
10 TEMPO 60
20 PLAY "CDEFG"
```

を実行し、再生される音を覚えておきました。
次に、10 行目を削除して再び実行すると、同じような音が再生されました。
すなわち、`PLAY` の前に `TEMPO` を実行しても、その設定値が `PLAY` におけるテンポの初期値にはならないことがわかります。
さらに、

```
30 TEMPO 60
```

を追加して実行すると、2音目以降の再生時間が長く (テンポが遅く) なりました。
よって、`TEMPO` によるテンポの設定は**再生中の**音楽には有効らしいことがわかります。

このため、「`TEMPO` によるテンポの設定は再生中の音楽にしか効かず、`TEMPO` の後で実行する `PLAY` コマンドには効かない」ことを表す表現を入れたほうがいいと思います。

### USR の記述不足

[USR のページ](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/USR.txt)において、少なくとも

* 第4引数に割り算ルーチンのポインタを渡すバージョンが存在することに関する記述
* RISC-V を考慮した記述 (第1引数や戻り値が R0 ではなく R10 (x10) であることなど)

が存在しないようです。

## 細かいtypoなどと思われるもの

### GOSUB におけるtypo

[GOSUB の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/GOSUB.txt)において、

> 1.1.0 beta1（正式版 1.1.0）よりでは省略形 GSB を使用できます。

という表現がありますが、「よりでは」の「では」を削除して「より」としたほうが自然だと思います。

### IOT.OUT におけるtypo

[IOT.OUT の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/IOT.OUT.txt)において、

> 1.3 以降では i2C バッファが追加されたため、破損しなくなりました。

とありますが、小文字の i ではなく大文字の I を使用するのが正しいと思います。

### LOAD・LRUN・SAVE における不自然な表現

[LOAD の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/LOAD.txt)および[LRUN の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/LRUN.txt) には、

> そのため、プログラムの空いた領域（#FFF に近い後ろの領域）を
> POKE で値を入れ SAVE 行う事でこの値も含めて保存し、
> LOAD・LRUN の後 PEEK でこの値を取り出せます。

とあります。また、[SAVE の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/SAVE.txt) には、

> そのため、プログラムの空いた領域（#FFF に近い後ろの領域）を
> POKE で値を入れ SAVE 行う事でこの値も保存する事ができます。
> LOAD・LRUN の後 PEEK でこの値を取り出せます。

とあります。
「SAVE 行う事」の部分に「を」を挿入し、「SAVE **を**行う事」としたほうが自然だと思います。

### OUT における表現の不統一

[OUT のページ](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/OUT.txt)の「機能」には、

> OUT 端子へ出力します。

とあります。一方、「解説」には、

> &lt;端子&gt; を省略した場合、複数の端子状態を入力します。

> 0・1  <端子> へ入力

とあります。

「OUTコマンドへ入力する」や「周辺機器へ入力する」などの解釈ができ、間違いであるとは言い切れないものの、「(端子へ) 出力」に統一したほうが自然だと思います。

### PEEK における表現の不統一

[PEEK の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/PEEK.txt)において、

> IchigoCake BASIC では [102]～[357] が存在します。
> そのアドレスは #C00～#Dff に対応します。

とあります。
小文字を用いた `#Dff` のかわりに、大文字に統一した `#DFF` を用いたほうが自然だと思います。

また、

>    1 ← 矢印 左キー
>    2 → 矢印 右キー
>    4 ↑ 矢印 上
>    8 ↓ 矢印 下
>   16 SPACE スペースキー

とありますが、

* 「上」および「下」にも「キー」をつける
* 「左」および「右」にも「キー」をつけない

のいずれかに統一したほうが自然である可能性があります。

### POKE におけるtypo

[POKE の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/POKE.txt)において、

> IchigoCake BASIC では配列 [102]～[357] が #C00～#DFF に対応します。
> したがってプログラム以降はアドレズがずれています。

とありますが、「アドレ**ズ**」ではなく「アドレ**ス**」とするのが一般的だと思います。

### REM におけるtypo

[REM の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/REM.txt)において、

> これを用いて、一時的に実行しなくないコマンドに対し、
> 頭に REM を入れて無視させる事が可能です。

とありますが、「実行し**な**くない」ではなく「実行し**た**くない」が適切だと思います。

### SIN における句点抜け

[SIN の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/SIN.txt)には、

> &lt;角度&gt; は度で指定します。返される値は 256 倍の値です

とあります。一方、[COS の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/COS.txt)では、

> &lt;角度&gt; は度で指定します。返される値は 256 倍の値です。

とあります。
`SIN` の解説にも、`COS` と同様に句点 (。) を追加したほうが自然だと思います。

### SWITCH の書式の表現が不適切

[SWITCH のコマンド 書式](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/SWITCH.txt)には、

> SWITCH [&lt;モード&gt;][,&lt;液晶の濃さ&gt;] (1.3.2b12～）

とあります。一方、たとえば [BEEP のコマンド 書式](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/BEEP.txt)には、

> BEEP [&lt;周期&gt;[,&lt;長さ&gt;]]

とあります。
`SWITCH` においても、`BEEP` と同様に角括弧をネストさせた

```
SWITCH [<モード>[,<液晶の濃さ>]] (1.3.2b12～）
```

としたほうが自然だと思います。

### UART における句点抜け

[UART の機能](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/UART.txt)には、

> シリアルの送受信を設定します

とあります。
他の多くのコマンドの機能の記述と同様に、句点 (。) を追加したほうが自然だと思います。

### USR における不適切な表現

[USR の解説](https://github.com/fu-sen/IchigoJam-BASIC/blob/2e43365fbf9be023eab4db9dbbf97d5e23113040/USR.txt)には、

> 1.3.2b12（正式版 1.4.0）より、マシン語向けの API が実行されています。

とありますが、「実行」より「実装」のほうが適切である可能性が考えられます。