TPP1 というのはこれ↓のことだと思う。前に書いたっけ？
https://github.com/TwitchPlaysPokemon/tpp1
最大で 1GiB ROM と 2MiB RAM ということで、既存のバンク切り替えレジスタの最大値まで拡張されている。
実物が出てくれれば使い道は考えるのだが…。
RGBDS の新バージョン 0.5.0 が出そうで出ない。いまのところ rc 。
かなり大改造になっているようなのだけれど既存ソースが使えなくなりそうな。うーむ。。
GB でビットコインのマイナーを作ったら PC の 125兆倍おそいという記事を読む。
git でソースを見たけど GBDK で書かれていて確かに遅そうではある。
しかし SHA2 ハッシュ計算だけでも asm ネイティブにしたら 12.5 兆倍くらいにスケールしないかなぁと思っている。
でもあのプロジェクトで真に見るべきはラズパイと GB をリンクケーブルでつないでネット接続する部分かも。
こまごまとした成果物とか niconico なり youtube なりにアップロードした方がいいのかなと思い始めている。
k12x8。
GB の画面だと 13x18 文字か。うーん。
GBA だと 横 20 文字取れる。
8x8 文字と差別化して見出しやアイコン的に使うような方法もあるか。
選択肢が広がったことは良いことである。
RGBDS 5.0 リリース。
ドキュメントがめっちゃ増えとる。
そうだったっけ？というのもあるのでメモがわりに色々書いてみよう。
無名ラベルが出来る。
: ld a,[hl+] dec b jr nz,:- |
みたいな感じ。
マクロの表記が変更になった。
Test: macro ld a,0 endm |
だったのが
macro Test ld a,0 endm |
になっている。これは修正が面倒そう。
地味にラベル末尾の「:」が厳格になっていて、付け忘れるとエラーが出る。
%1111_0000 とアンダースコアで見やすく表記できるようになったのはうれしい。アンスコは先頭以外ならどこでも良いらしい。
DL が使える。db(1),dw(2),dl(4byte) 定数値。
LOAD ブロックを用いて RAM 側で実行するコードを記述できるようになったらしい。
つまり、実際には RAM だから不定値なのだけれど、RAM に LOAD ブロックでコードを書いておくとコードのサイズ分の ds スペースを確実に確保してくれるということか。
んで、同じコードを ROM に書いておいて実行時に転送して（これは自前で書く必要があるが）RAM 側で実行できる、と。
従来 ds xxxx byteでどれくらいコードスペースが必要かコンパイルしてみるまで分からなかったよりは使いやすくなる。
という理解でいいの？
FOR が使えるようになった。
ブロック中にイテレーション変数が使えるようになり、開始終了変化量を指定できる。
おまけに BREAK もあるので IF と変数を組み合わせてこれは便利そうな予感。
ほか、デバッグに有用そうな変更点も多数。
全体的には便利になってそうだけど最終的なアセンブル結果について十分に予想できる知識と経験が無いと想定外にハマりそうな。
このあたりは高級言語つかっているときと変わらない感じか。
BGB もバージョンアップ。こちらでも tpp1 マッパーが対応になった。
音関係の精度が上がったらしいが、正直いま一番正確なのがどのエミュレータなのかはよくわからない。逆に普段触っている人に聞いてみたい
RGBASM 5.0 使ってみた感じ、基本はそのままだけど地味に色々変わったなぁという実感がある。
ld sp,xxxx でラベル未定義だった場合に "[" が足りないとエラーが出るのは命令のパースが不十分な気がする。
これも以前書いたかもだけど、C 環境に関しては gbdk-2020 というのが出ていて割と活発な活動っぽい。
https://github.com/gbdk-2020/gbdk-2020
コンパイラは sdcc。ツール系一式が sdcc 系なので覚えることが増えてつらい。いまどき GB 環境整えてくれるのは有難みしかないけれど。
件の gb-bitcoin-miner も旧 gbdk でなく新しい方で作られたような（気がする）ので、スタンダードな環境なのかもしれない。
pdf のゴツいドキュメントと共にサンプルも大量につけてくれていて勉強になりそう。
ネオポケもとかいけそうな。
しかし旧 gbdk の方でないと通らないのがあったりするかもしれないので、両方入れておくべきなのか。
国内の人たちは旧使ってる人が多そうだし。
ものは試しに RGBDS 5.0 に慣れるため、sha2(256) の GBZ80 版を書いてみた。
テスト用 ROM も含めて後で github に置いておくことにする。清書中。
誰の役にも立たないだろうけれど。
ワーク用 RAM は部分的に HI-RAM を使った方が速いのは確かだが、127byte しかない HI-RAM を 4byte 単位で使うには結構な吟味が必要だと思う。
32bit ローテートやシフトは呼び出し頻度が高いわりにシフト数が固定なので関数コールせずに全展開した方が良いかもしれない。マクロの出番。
特に GB は call(+ret) 命令の対 Z80 比の税金がクソ高い(17+10clk vs 24+16clk)ので、速さを求めるなら極力使わずにすませたい。
Z80 やったあとだと adc hl,bc とか無いのは不意を突かれた感があってげんなり。
RAM コードにすればよさそうなところもあるが、あまりやりすぎるとソースがグチャグチャになるので今回はパス。
オリジナルの C 版と速度比較してみると以下のような感じ。
C の方は GBDK 使用。crt0 や文字表示のオーバーヘッドはあるだろうけど誤差ってことで。
空文字列("") → さすがに差はでない。C 版でもほぼ一瞬で出る。
4096byte の長さだとどうか。
手計測。
C 版は 23.84秒、ASM 版は 15.27秒。う〜〜ん。
4byte 境界とか小手先の高速化はできるけどなぁ。
苦労が報われず、やや元気がなくなってしまったのだった。
画面いっしょやないかーい。
目につくところを最適化したところ 6.2 秒になった。
まあ良しとしよう。これも sha2_gb_opt として git に上げておく。