続5：中華linuxゲーム端末Anbernic 353PSでセガサターン

今度こそyabasanshiro-saでGRANDIAのムービーが遅い原因を調査する

とりあえず忘れないうちに覚書をメモ

ここまでの調査でFBCRへの書き込みで画面をマニュアル更新していることは分かっている。要はこの画面更新のタイミングがなぜ遅いのかが問題となる。単にタイマーのエミュレーションにバグがあるとかだったら直せそうなので調べてみる。（そうであってくれ）

 FBCR(25D00002)への書き込みを行っているのがどこなのか探してみる。いろいろやったがよくわからず、SSFのデバッグ機能で、25D00002を検索した。（ような気がする。うろ覚え）

そしてprintf結果と突き合わせて、どうやら060129baでFBCRに書いているようだとわかった（と思う）

そしてその近辺でpcをprintfした。普通こういうタイミングが重要な処理は割り込みのタイミングでやるはず。急にアドレスが飛んで戻っているので、おそらく割り込みだろうと決めつけて調べる。

pc 06039f94
pc 06037b10
pc 06013a1c <= なんとなくここで割り込みっぽい気がする
pc 06012952
pc 06012988
pc 0601298e
pc 06012996
pc 060129a8
pc 060129ba
mw 25D00002 @060129ba
pc 06013a34
pc 06015144
pc 06015160
pc 060151c8
pc 060151f4
pc 06015210
pc 06015222
pc 06039ae4

再びSSFで06013a1cを検索、06000a04が見つかる。なんか割り込みベクタっぽいアドレスだ。ただ、SSFの画面を見る限りはVBRは06000000と060000400で、微妙に遠い。ただ、限りなく割り込みっぽいので、Interruptで検索してprintfを入れまくる。そしてここで06013a1cを登録しているっぽいことが分かる。

static void FASTCALL BiosSetScuInterrupt(SH2_struct * sh)
{
   SH2GetRegisters(sh, &sh->regs);

   LOG("BiosSetScuInterrupt. vector = %02X, func = %08X\n", sh->regs.R[4], sh->regs.R[5]);

これで、どうやらベクタ番号41番と分かり、先日見つけたサターンの仕様を見ると

SCU Interrupt
bit 1    V-blank-OUT    VDP2    vector 41    Level E

となっている。1画面書き終わったら発生するV-blank-OUTの割り込みのようだ。という事は単に1画面60フレームごとに割り込みでマニュアル更新しているということになる。

単に画面の描画が60fpsに間に合ってなくて遅くなっているという事だろう。エミュレーションバグとかではなかった。簡単に治せそうにない。当てが外れたようだ。

フレームスキップが有効になっているが、無効にしても同じ速度で動いている。自動フレームスキップが何の役にも立ってなさそうだ。 何か違うところが遅いのかもしれない。

実機でしか動かせないからどこが遅いのかしらべるの大変そう。。

MOONLIGHT & SUNSHINE

 ROCKNIXでMoonlightとやらの設定があった。どうやらNvidiaのGameStreamとやらでPC上のゲームをlinuxゲーム端末で遊べるというものらしい。

ただ、いくら探してもnvidiaのアプリ上にgamestreamらしきものはなかった。どうやら非対応になった模様。

それに代わるものとしてMoonlightの開発チームがsunshineというものを作っているようだ。PC上にsunshineをインストールし、PCのIPをlinuxゲーム端末に設定すると、遠隔でPC上のゲームを遊べる。

PCは電源を入れてsunshineを動かしておかなければならない。wakeonlanとか設定して自動ログインとかにしておけばいつでも遊べる感じになりそうだが、めんどくさいのでそこまではしない。

steamのbig pictureが多分最初から設定されていて（インストールされてあったら自動的に登録されてたりする？） 、まあまあそれなりに遊べそう。

マウス入力はできなそうなので、ゲームパッドで遊べるやつ専用かな。とりあえず428は遊べそうだが、画面サイズが640x480でなんか縦長に圧縮されたような画面になってちょっと気になる。

終わらせ方はSELECT+RUN+L1+R2同時押しで終わる。

自民党がまた金配るみたいだな

現役世代から金をとって老人に配りたいんだろう。それで票を買いたいわけだ。そもそも配るくらいなら最初から取るなと言いたいところだが、一度作った仕組みは変えたくない、一度取り始めた税金は意地でも減税したくないという事だろう。

プログラム的に言うと継ぎ足し継ぎ足しで無駄コードがわんさか入っているスパゲッティコードだけど、動かなくなるから削るなみたいな感じだろうか？

放送法とか。当初は電波塔とかの整備で予算が必要だったのかもしれないが、もう要らんはずだし。 ガソリン税も二重課税になって、一般財源にされて何に使ってるかよくわからなくなってる。流用流用で何に使ってるか分からないまま税金だけどんどん増えている。

プログラムだったら、コードを見直して、何がどうなっているか把握できる状態を保っておかないと管理できなくなるんだが。都度見直しして根本原因を直す。コードは常にきれいに無駄なく保つってことができない奴は優秀とはいえない。

口先だけの文系に任せてるからこうなってるんじゃないのか？もっと理論立てて仕組みを考えられるやつにやらせたほうがマシになるんじゃないのか？

と思ったりしていたが、アメリカではイーロンマスクが容赦なくリファクタリングしまくっているようだ。将来的には無駄を排除したすっきりしたシステムになるのかもしれないが、どうなるんだろう。結構な痛みは伴っているようだが。

しかしアメリカはすごいな。日本だと一人二人変わったところで、何も変わらずスパゲッティを肥大化させていくだけだろう。

続4：中華linuxゲーム端末Anbernic 353PSでセガサターン （更新）

yabasanshiro-saでGRANDIAのムービーの音がおかしい原因の調査の覚書のメモ（更新）

GRANDIAを動かすとムービーが遅い気がする。そして雑音だらけで何を言っているか分からない。遅いせいで雑音だらけなのか？音だけでも何とかしたい。と思って調べた。

ソースコードvdp2.cpp:882くらい

swap_frame_bufferがmanual changeされていて、VDP1 offset 0x02にval=3が書かれたとき更新される。

FBCR	Frame buffer switching mode

どうやら遅いわけではなく、もともとそういうスピードにしてそう？？

音が雑音だらけで遅くなっているのかと勘違いしていた。どうやら雑音だけの問題の模様。

セガサターンの音を再生する機能（SCSP）にはSLOTというものがあり、オープニングムービーでは、SLOT04とSLOT08を使っている模様（SSFのデバッグモードを使うとわかる）

08だけ生かすとほぼ無音（あっているのか？）
04だけ生かすとノイズまみれ。ただ、ノイズにまみれた中で、ところどころ正常な音が鳴る。部分的に問題なさそう。

とりあえずSLOT04が悪いようだ。

データを見てみると、サウンドバッファにあるデータをM68kに投げて、データを戻してから再生するようだ。おそらく、M68kとやらを使って圧縮された音を展開しているんじゃないだろうか。

原因を調べようとprintfを入れると音がマシになる。

またタイミング問題かよ。。。

タイミングの問題を調べようとする

なんかyabause.cのあたりで、CPUシミュレーションとSCSPシミュレーションの同期が取れてないような気がしてきた。

とりあえずyabause.cの中を見てみる

deciline = 1/10ライン
SCSP 44100 * 512 clock？
M68k 44100 * 256 clock？

decilineの9と10でHBlankINとHBlankOUTになり、ScspExecされる

PAL 50フレーム x 313ライン
NTSC? 60フレーム x 263ライン

1/10ライン当たり 143.0874... clockということ
この端数が良くないとか？

scsp_cycles_per_deciline =

VLBlankで
    setM68kCounter((u64)(44100*256/60)<<SCSP_FRACTIONAL_BITS)
    SmpcINTBACKEnd()
    Vdp2VBlankIN()
    SyncCPUtoSCSP() 

と見ていった中で、SyncCPUtoSCSPが実質何もやっていないように見える。

CPUから書いたデータをSCSPで受けて、M68kに渡して展開、戻ってきたデータを(ここで壊れている感じ？)SCSPで鳴らす。 CPUとSCSPでタイミングを合わせないとうまくデータがやり取りできないのでは？

とりあえずの解決策

よく見ると、SCSPのコードには2通り実行コードがあった。

void ScspExec(){
  if (thread_running == 0){
    thread_running = 1;
    if (g_scsp_main_mode == 0) {
      YabThreadStart(YAB_THREAD_SCSP, (void * (*)(void *))ScspAsynMainCpuTime, NULL);
    }
    else {
      YabThreadStart(YAB_THREAD_SCSP, (void * (*)(void *))ScspAsynMainRealtime, NULL);
    }
    YabThreadUSleep(100000);
  }
}

何も変えない場合、ScspAsynMainRealtimeで動く。試しにg_scsp_main_modeを0にして、ScspAsynMainCpuTimeに変えてみると、雑音がなくなった。ただ、やっぱりスロー再生みたいになっているようだ。なんか遅い気がした感覚は気のせいではなかったようだ。

見たところRealtimeの方は時計の時間に同期して動くように見える。それに対してCpuTimeはおそらくシミュレーション時間に同期して動くものだと思われる。ここで雑音になった原因を考えてみると、端末のCPUが貧弱なためにCPUエミュレートが遅くなり、ムービーがスロー再生気味になるのに対し、SCSPだけ現実時間で動いて同期が取れなくなり、音声データがおかしくなり雑音だらけになったという事だろう。当初推測した原因（遅いせいで雑音になる）は一応当たっていたという事になる。

 なんにせよグランディアの音が正常に鳴るようになった。やったー。と言いたいところだが、今度はスロー再生になるのが気になってしまう。CPUの処理能力が足りないんだろうが、うーん。。

FBCRで毎回書いてるみたいだから、なぜそれが遅くなっているかだなあ。

 

続3：中華linuxゲーム端末Anbernic 353PSでセガサターン

前回に引き続き、yabasanshiroがメモリを消費しまくる原因を探している。

 _ZNSt10_HashtableIjSt4pairIKjiESaIS2_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb1EEEEC4Ev
toolchain/aarch64-rocknix-linux-gnueabi/include/c++/14.2.0/bits/hashtable.h:539 (discriminator 2)
_ZN10DynarecSh210SetContextEP10SH2_struct
yabause/src/sh2_dynarec_devmiyax/DynarecSh2.h:320
SH2Reset
yabause/src/sh2core.c:180 (discriminator 1)
YabauseStopSlave
yabause/src/yabause.c:966
_Z11yabauseinitv
yabause/src/retro_arena/main.cpp:272
main
yabause/src/retro_arena/main.cpp:440 (discriminator 1) 

このあたりでメモリ消費が大きいという事で、ファイル名からしてダイナミックリコンパイルの処理の模様。

試しにインタプリタ方式で実行してみると嘘のようにメモリ消費量が下がった。変更するところは以下。src/retro_arena/main.cppのyabause_init()内、

yinit.sh2coretype = 0;

とすると、上の方で定義しているSH2Interpreterが選ばれる模様。ただ、これだとインタプリタなので遅い。 早く動かしたくてstandalone版を何とかしようとしているので、本末転倒になる。

次はこのダイナミックリコンパイルの処理を何とかしないといけないという事だ。

メモリリークの場所

探すのにだいぶ苦労したが、 DynarecSH2.cppのInit部分

void CompileBlocks::Init()
{
  dCode = (Block*)ALLOCATE(sizeof(Block)*NUMOFBLOCKS);
  memset((void*)dCode, 0, sizeof(Block)*NUMOFBLOCKS);

この関数は最初だけじゃなく、結構何回でも呼ばれる。そのたびにdCodeが新しく確保されていく。とりあえずNULLじゃなかったら確保しないようにすればメモリリークはなくなる。

最初はdCodeのサイズ自体が大きすぎるのかと思って削減用のコードを書いてしまった。半分くらいに減らしたところで、よく見たら16MB程度であり、何かのきっかけで20MB程度増えるという現象に合致する数字であることに気づくという失態。

本家のソースを見るとすでに対処済みのようだった。見当がついた時点でそっちを見ればよかった。

root        2897  227 26.1 1060784 262320 pts/0  Rl+  01:46  22:07  |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897  227 26.1 1060784 262360 pts/0  Rl+  01:46  22:09  |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897  227 27.1 1060784 271604 pts/0  Sl+  01:46  22:11  |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897  226 25.2 1050692 252664 pts/0  Sl+  01:46  22:12  |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897  226 25.0 1049160 251088 pts/0  Sl+  01:46  22:12  |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd

 何回か戦闘してもメモリ250MBくらいに収まっている。仮想メモリは1GBくらい行っているので最悪それくらいまでは消費し得るのかもしれないが、今のところ大丈夫そう。おそらくは前回確認したcurrentQuadの部分だと思われるが、際限なく増えるわけではないのでとりあえず良し。

あとはGRANDIAのムービーが激重でコマ送りになっているのが何とかなればいいんだけど、これはちょっと見当つかないな。

 

続2：中華linuxゲーム端末Anbernic 353PSでセガサターン

前回、とりあえずメモリリークっぽいというところまでは分かった。ただ、どこでメモリリークしているのかは分からない。

jemallocではプロファイルが取れるようなので取ってみようとした。

jemalloc prof

./configure --host=aarch64-rocknix-linux-gnueabi --enable-prof

でビルドして、

MALLOC_CONF=prof:true

としてみたが、ファイルが取れなかった。リンクしてmalloc_stats_printは動いてそうだが、なぜかファイル出力されない。 

どうやらatexitで登録されている処理が動いてないようだ。YabDeInitとやらの処理の途中でおそらくabortしており、exitされていないという可能性がある。

とりあえず無理やりmenuから何かの操作をしたらexit(-1)するようにしたところファイルは出力された。

このファイルをみるためjeprofを動かさなければならないが、perlは入ってない。PCで動かそうにもarmのものなのでシンボルが読めなそう。textファイルなので直接読んでみる。

heap_v2/524288
  t*: 370: 661091 [0: 0]
  t0: 95: 43814 [0: 0]
  t1: 0: 0 [0: 0]
  t3: 255: 21950857 [0: 0]
  t4: 0: 0 [0: 0]
  t5: 0: 0 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x56712c 0x567620 0x4eef9c 0x4e1f64 0x513014 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 4194308 [0: 0]
  t0: 1: 4194308 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x4e1e54 0x5130b0 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 516101 [0: 0]
  t0: 1: 516101 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x7fadca9364 0x7fadc25e0c 0x7fadc9bf98 0x7fadc30c10 0x7fadc9bffc 0x7fadc90560 0x7fb5afd208 0x7fb59f37d0 0x7fb59ee404 0x476364 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 5121 [0: 0]
  t0: 1: 5121 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x512f78 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 516101 [0: 0]
  t0: 1: 516101 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x56d584 0x562eac 0x563e20 0x4f43e8 0x4e2540 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 1: 41128 [0: 0]
  t3: 1: 41128 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x56d584 0x562eac 0x56473c 0x4f74d8 0x4f7c0c 0x4fc844 0x4fd020 0x4e4b74 0x7fb54e0d34 0x7fb554c18c
  t*: 1: 448 [0: 0]
  t3: 1: 448 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x512f8c 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 1057519 [0: 0]
  t0: 1: 1057519 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x512fa4 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 1057519 [0: 0]
  t0: 1: 1057519 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x7faedbc9b0
  t*: 1: 661636 [0: 0]
  t0: 1: 661636 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x5598c0 0x5130a8 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 516101 [0: 0]
  t0: 1: 516101 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c97644 0x5792e4 0x512fec 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 4194308 [0: 0]
  t0: 1: 4194308 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fb5a70714 0x7fb5a71194 0x7fb59f05c8 0x7fb5a17e50 0x7fb59ee33c 0x7fb59ee550 0x476364 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 32 [0: 0]
  t0: 1: 32 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fb5a70714 0x7fb5a71194 0x7fb59f05c8 0x7fb5a1c894 0x7fb5ae796c 0x7fb59ee3b8 0x476364 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 32 [0: 0]
  t0: 1: 32 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fafdb0418
  t*: 1: 80 [0: 0]
  t0: 1: 80 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7faed40544
  t*: 1: 396057 [0: 0]
  t0: 1: 396057 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fafdb205c
  t*: 1: 265483 [0: 0]
  t0: 1: 265483 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fafd32870
  t*: 5: 15364 [0: 0]
  t0: 5: 15364 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fafd1ab74
  t*: 1: 512 [0: 0]
  t0: 1: 512 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7faecac574
  t*: 1: 661636 [0: 0]
  t0: 1: 661636 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7faedd277c
  t*: 1: 8 [0: 0]
  t0: 1: 8 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7faed41198
  t*: 2: 164677 [0: 0]
  t0: 2: 164677 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7faed42da4
  t*: 1: 330638 [0: 0]
  t0: 1: 330638 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fafd33ca8
  t*: 2: 11954 [0: 0]
  t0: 2: 11954 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x5673bc 0x4eef9c 0x4e1f64 0x513014 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 97907 [0: 0]
  t0: 1: 97907 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x53b5c4 0x55f0b0 0x4ca080 0x47b178 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 8192 [0: 0]
  t0: 1: 8192 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fb596d0cc 0x7fb5c37d4c 0x7fb5988620 0x7fb59891f8 0x7fb598bde8 0x7fb5985dfc 0x7fb59860f0 0x47b688 0x4769e0 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 65611 [0: 0]
  t0: 1: 65611 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fb596d0cc 0x7fb5c37d64 0x7fb5988620 0x7fb59891f8 0x7fb598bde8 0x7fb5985dfc 0x7fb59860f0 0x47b688 0x4769e0 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 65611 [0: 0]
  t0: 1: 65611 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7fb596d0cc 0x7fb5c37da0 0x7fb5988620 0x7fb59891f8 0x7fb598bde8 0x7fb5985dfc 0x7fb59860f0 0x47b688 0x4769e0 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 65611 [0: 0]
  t0: 1: 65611 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x5673d0 0x4eef9c 0x4e1f64 0x513014 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 2: 388000 [0: 0]
  t0: 2: 388000 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x51a5e0 0x52b1e4 0x5309fc 0x53d42c 0x627dc0 0x4add8c 0x4764fc 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 4194308 [0: 0]
  t0: 1: 4194308 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x5673e4 0x4eef9c 0x4e1f64 0x513014 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 2: 388000 [0: 0]
  t0: 2: 388000 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5c95628 0x7faedbd3e4
  t*: 1: 225995 [0: 0]
  t0: 1: 225995 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5d09f54 0x7fb5d0a0c8 0x7faed3b6c4
  t*: 2: 164677 [0: 0]
  t0: 1: 82338 [0: 0]
  t3: 1: 82338 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c93b80 0x7fb5d09f54 0x7fb5d0a0c8 0x54bde8 0x54a7c8 0x4d53fc 0x513180 0x47b148 0x47652c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 12582912 [0: 0]
  t0: 1: 12582912 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c9418c 0x7fb5c95628 0x7fb57a4944 0x7fb5f699b4 0x7fb5f80f78
  t*: 1: 82338 [0: 0]
  t0: 1: 82338 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c9ec90 0x617e38 0x542768 0x4afa34 0x618ce8 0x476b7c 0x7fb5481fcc 0x7fb54820a8 0x47ab70
  t*: 1: 65611 [0: 0]
  t0: 1: 65611 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x563e20 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 5: 1039333 [0: 0]
  t3: 5: 1039333 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x563e20 0x4f55a0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 4: 531792 [0: 0]
  t3: 4: 531792 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x563e20 0x4f16b4 0x4e2508 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 2: 227959 [0: 0]
  t3: 2: 227959 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x563e20 0x4f50e0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 6: 683878 [0: 0]
  t3: 6: 683878 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x563e20 0x4f43e8 0x4e2540 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 3: 341939 [0: 0]
  t3: 3: 341939 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x563e20 0x4f45f4 0x4e2524 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 1: 113980 [0: 0]
  t3: 1: 113980 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x564b64 0x565260 0x4fc4d0 0x4fd020 0x4e4b74 0x7fb54e0d34 0x7fb554c18c
  t*: 1: 113980 [0: 0]
  t3: 1: 113980 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x5633a8 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 19: 4814936 [0: 0]
  t3: 19: 4814936 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fa8 0x5633a8 0x4f50e0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 2: 451990 [0: 0]
  t3: 2: 451990 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x563e20 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 5: 1970845 [0: 0]
  t3: 5: 1970845 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x563e20 0x4f55a0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 4: 1076334 [0: 0]
  t3: 4: 1076334 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x563e20 0x4f16b4 0x4e2508 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 2: 451990 [0: 0]
  t3: 2: 451990 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x563e20 0x4f50e0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 15: 3389928 [0: 0]
  t3: 15: 3389928 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x563e20 0x4f43e8 0x4e2540 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 3: 677986 [0: 0]
  t3: 3: 677986 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x563e20 0x4f45f4 0x4e2524 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 3: 677986 [0: 0]
  t3: 3: 677986 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x5633a8 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 36: 19556783 [0: 0]
  t3: 36: 19556783 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x5633a8 0x4f16b4 0x4e2508 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 1: 225995 [0: 0]
  t3: 1: 225995 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x5633a8 0x4f50e0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 4: 1811755 [0: 0]
  t3: 4: 1811755 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x563e20 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 5: 2454642 [0: 0]
  t3: 5: 2454642 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x563e20 0x4f55a0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 4: 1076334 [0: 0]
  t3: 4: 1076334 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x563e20 0x4f16b4 0x4e2508 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 6: 1355971 [0: 0]
  t3: 6: 1355971 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x563e20 0x4f50e0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 21: 4745899 [0: 0]
  t3: 21: 4745899 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x563e20 0x4f43e8 0x4e2540 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 2: 451990 [0: 0]
  t3: 2: 451990 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x563e20 0x4f45f4 0x4e2524 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 3: 677986 [0: 0]
  t3: 3: 677986 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x56473c 0x4f74d8 0x4f7c0c 0x4fc844 0x4fd020 0x4e4b74 0x7fb54e0d34 0x7fb554c18c
  t*: 2: 451990 [0: 0]
  t3: 2: 451990 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x5633a8 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 34: 17685727 [0: 0]
  t3: 34: 17685727 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x5633a8 0x4f50e0 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 4: 1522884 [0: 0]
  t3: 4: 1522884 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x5652f4 0x4f5748 0x4fbe98 0x4fd020 0x4e4b74 0x7fb54e0d34 0x7fb554c18c
  t*: 1: 225995 [0: 0]
  t3: 1: 225995 [0: 0]

 t何とかで出ているのはおそらくメモリサイズだろう。とりあえず多そうなのは、以下。

@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fc0 0x5633a8 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 36: 19556783 [0: 0]
  t3: 36: 19556783 [0: 0]
@ 0x7fb5cfaa70 0x7fb5cfb2f8 0x7fb5cedcf4 0x7fb5c90ee4 0x7fb5c9e820 0x562fd8 0x5633a8 0x4f5414 0x4e24d0 0x4e4b50 0x7fb54e0d34 0x7fb554c18c
  t*: 34: 17685727 [0: 0]
  t3: 34: 17685727 [0: 0]

16進数はおそらくプログラムの位置だろう。addr2lineで見てみる。

aarch64-rocknix-linux-gnueabi-addr2line -e src/retro_arena/yabasanshiroYglGetProgram -f
yabause/src/ygles.c:2170
YglTriangleGrowShading_in
yabause/src/ygles.c:2290
VIDOGLVdp1DistortedSpriteDraw
yabause/src/vidogl.c:5384
Vdp1DrawCommands
yabause/src/vdp1.cpp:547
VdpProc
yabause/src/vdp2.cpp:1204

YglGetProgram
yabause/src/ygles.c:2171 (discriminator 1)
YglTriangleGrowShading_in
yabause/src/ygles.c:2290
VIDOGLVdp1DistortedSpriteDraw
yabause/src/vidogl.c:5384
Vdp1DrawCommands
yabause/src/vdp1.cpp:547
vdp2VBlankOUT
yabause/src/vdp2.cpp:1204

ygles.c:2170は以下のあたり

   if ((program->currentQuad + YGL_MAX_NEED_BUFFER) >= program->maxQuad) {
     program->maxQuad += YGL_MAX_NEED_BUFFER*32;
    program->quads = (float *)realloc(program->quads, program->maxQuad * sizeof(float));
      program->textcoords = (float *) realloc(program->textcoords, program->maxQuad * sizeof(float) * 2);
      program->vertexAttribute = (float *) realloc(program->vertexAttribute, program->maxQuad * sizeof(float)*2);
    YglCacheReset(_Ygl->texture_manager);
   }

currentQuadが増えたらメモリを取り直している。なにかで増えたら増えていく模様。

なんとなく原因は分かったが、どうやって直せばいいのか？どういう作りなのか理解しないと直せなそう。 

とりあえずここまで。 

追記：

上記を無理やり開放するようにして動かしてもメモリが増える現象は変わらなかった。currentQuadは毎回0にされており、無限に増えていくわけではなさそう。どうやらテクスチャの最大必要なところまで拡大する処理のように見える。

ピークを引きずっているわけなので、いつまでもそれだけ確保し続けるのもちょっと困りものだが、とりあえず今回の原因ではなさそう。ここ以外でメモリ消費で大きいものを探すと以下だった。

@ 0x7f9b7faa70 0x7f9b7fb2f8 0x7f9b7edcf4 0x7f9b793b80 0x7f9b809f54 0x7f9b80a0c8 0x54be08 0x54a7e8 0x4d53fc 0x5131a0 0x47b148 0x47652c 0x7f9af81fcc 0x7f9af820a8 0x47ab70
  t*: 1: 12582912 [0: 0]
  t0: 1: 12582912 [0: 0] 

で、以下

_ZNSt10_HashtableIjSt4pairIKjiESaIS2_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb1EEEEC4Ev
toolchain/aarch64-rocknix-linux-gnueabi/include/c++/14.2.0/bits/hashtable.h:539 (discriminator 2)
_ZN10DynarecSh210SetContextEP10SH2_struct
yabause/src/sh2_dynarec_devmiyax/DynarecSh2.h:320
SH2Reset
yabause/src/sh2core.c:180 (discriminator 1)
YabauseStopSlave
yabause/src/yabause.c:966
_Z11yabauseinitv
yabause/src/retro_arena/main.cpp:272
main
yabause/src/retro_arena/main.cpp:440 (discriminator 1)

ダイナミックリコンパイルのあたり？っぽい。OpenGL関係でリークしているのかと思って探し回っていたが予想外。

うーん。 確保されてても解放されてて問題ないのだろうか。t0とかの意味が分からない。

解決→次

続：中華linuxゲーム端末Anbernic 353PSでセガサターン

前回何とかAdvancedWorldWarを許容範囲で動かすことができるようになったが、しばらく動かしていると死ぬ問題が発生した。

カーネルログを見るとOOM-killerで殺されているように見える。

ps をwhileで回しながら動かしてみると、画面が切り替わるたびにメモリが増えていき減ることがない模様。そして限界を超えると殺される。 

メモリリークの可能性がある。が、どうやって調べるか。

valgrindは動かなかった。ld.soにデバッグ情報がないため。イメージ丸ごとビルドはできそうだが、現状途中で止まる。 

あとはmallocをフックするやつを作るか、探してくるか。それで調べたところによるとglibc mallocはいけてないらしい。もしかしたらjemallocを使えば解決するのかも。

うーん。めんどくさい。

jemallocクロスコンパイル

また何度かこけるかと思ったが、驚くほどすんなりとクロスコンパイルできた。

https://github.com/jemalloc/jemalloc/tree/master

からとってくる。

yabasanshiroのビルドのログから、 ツールチェーンの場所が分かるので、パスを通し

./configure --host=aarch64-rocknix-linux-gnueabi

make

 で完了。libにできたライブラリをコピーする。

RG353PS上で

LD_PRELOAD=/tmp/libjemalloc.so.2 ldd /tmp/yabasanshiro

で見ると、jemallocが使われそうな感じに見える。

とりあえずこれで実行してみたが、メモリリークっぽい現象は変わらなかった。残念。

起動してタイトル画面あたり。メモリ300MB？（メモリ使用率30%くらい）

root        3363  201 29.9 625348 299948 pts/0   Rl+  00:52   1:07
root        3363  202 30.0 629148 300548 pts/0   Rl+  00:52   1:10
root        3363  202 29.9 629148 300280 pts/0   Rl+  00:52   1:12
root        3363  203 29.9 629180 300376 pts/0   Rl+  00:52   1:14
root        3363  204 29.9 629180 300416 pts/0   Rl+  00:52   1:17

戦闘を何回か行ったとき。メモリ700MB？（メモリ使用率70%くらい）戦闘するごとに20Mくらい増えてそう。800MB超えるといつ殺されてもおかしくない感じになる。

OpenGLの何かを作りっぱなしなのではと思ったが、一応フリーはされてそう。

root        3363  222 66.0 1080976 662092 pts/0  Rl+  00:52   7:15
root        3363  222 66.1 1081588 662728 pts/0  Rl+  00:52   7:17
root        3363  222 67.7 1098036 678596 pts/0  Rl+  00:52   7:20
root        3363  222 68.4 1114484 685876 pts/0  Rl+  00:52   7:22
root        3363  222 69.3 1114612 694828 pts/0  Rl+  00:52   7:24
root        3363  222 69.3 1114996 694768 pts/0  Rl+  00:52   7:27
root        3363  222 69.3 1114996 694856 pts/0  Rl+  00:52   7:29
root        3363  222 69.3 1114996 694920 pts/0  Rl+  00:52   7:31
root        3363  222 69.3 1114996 695044 pts/0  Rl+  00:52   7:34
root        3363  222 69.3 1114996 694704 pts/0  Sl+  00:52   7:36
root        3363  222 69.3 1114996 694776 pts/0  Rl+  00:52   7:39
root        3363  222 69.6 1115252 697852 pts/0  Sl+  00:52   7:41

さて、どうするか。。。 →次回

中華linuxゲーム端末Anbernic 353PSでセガサターン

Anbernic 353PS

celesteが面白かったのでpico-8を携帯できないかと思って中華端末を買ったが、飽きてきたのでホコリをかぶっていたサターンのソフトを引っ張り出して動かしてみた。

端末に入っているのはyabasanshiroとかいうエミュレータで、libretro版とか言われるものと、standalone版が入っている。

yabasanshiro-lr (libretro版)

古の名作Advanced World War 千年帝国の興亡を動かしてみたが、地味にコマ送り気味で遅い。ちょっと使うには厳しい性能。右上の色が変なのも気になる。

 

グランディアも動いたが、戦闘がかなり遅くて厳しい。

yabasanshiro-sa (standalone版)

速度はまあまあ、何とか使えるくらいの速度が出ているが、結構致命的な問題がいくつかある。

Advanced World Warだと武器のリストが何にも見えないので使い物にならない。

グランディアだと戦闘画面で死んでしまう。

yabasanshiro-saの修正

yabasanshiro-lrが遅いので、もっと早い端末が出れば、、としばらく待っていたが出る気配がない。何とかしたいと思って試行錯誤。

ROCKNIXというカスタムファームウェアを入れてみたが、改善はされていないようだ。ただ、dockerで開発環境が準備されているので何とかビルドできそう。

イメージ全部はビルドできずに途中で止まってしまったが、とりあえずyabasanshiroのビルドはできるようだ。

PROJECT=Rockchip DEVICE=RK3566 ARCH=aarch64 ./scripts/build yabasanshiro-sa

PROJECT=Rockchip DEVICE=RK3566 ARCH=aarch64 ./scripts/build yabasanshiro-lr

グランディアが死ぬ問題

VIDOGLVdp1ReadFrameBufferがopenglのスレッドとは別のスレッドから呼ばれ、_Ygl->smallfboを別スレッドから作ろうとして死ぬ。最初に作っておけば死にはしないが、やはり別スレッドからフレームバッファアクセスできず、キャラが表示されない。

どうやらyabasanshiro-lrはOpenGL？でyabasanshiro-saはOpenGLES？で動いていて、サブセットであるGLESだとなんかこういうのがNGになるのかもしれない。

とりあえずフレームバッファをコピーするイベントを追加して、アクセスに来た時に、フレームバッファがコピーされてないならイベントを発行してyieldし、コピーされるのを待つようにした。

グランディアはこれである程度使えそう。

Advanced World Warが真っ黒になる問題

yabasanshiro-lrの方が移植の再現度が高いようなので、とりあえず影響ありそうなソースを片っ端からコピーして持ってくる。lr並みに遅くなるかと思ったが、たいして速度に影響はなかった。libretroが悪いか、OpenGLESが早いのかだと思われる。

セガサターンの中にはいくつか画面があり、問題となるのはNBG3の表示（SSFだと各画面のON/OFFができるのでそれで確認）だ。他の関数呼び出しを止めたりして確認していき、Vdp2DrawPatternPosの中でYglIsCachedに入っているかどうかが関係ありそうな気がしたが、デバッグ用にprintfしたら現象が出なくなるなど、ちょっとお手上げ。

とりあえずNBG3専用にVdp2DrawPatternPosNBG3を作って、cacheaddrをいじったりして、原因不明だが表示はされるという状態になった。他の端末で動かしたら表示されなかったりしそうだが、まあ自分しか使わないので良しとする。

Advanced World Warの背景が変な色になる問題

これは簡単に解決した。色情報にinfo.cor/cog/cobを足しているが、おそらく255を超えているため、色が変になる。Y_MINで255にリミットすれば大丈夫。

        r = Y_MIN(Y_MAX( ((dot & 0x1F) << 3) + info.cor, 0 ),255);
        g = Y_MIN(Y_MAX( (((dot & 0x3E0) >> 5) << 3) + info.cog , 0),255);
        b = Y_MIN(Y_MAX( (((dot & 0x7C00) >> 10) << 3) + info.cob, 0 ),255);

 

 

いい感じ？と思ったら音が途中からガタガタ言い始める。でも疲れたので終了。

追記：しばらく動かしていると死ぬようだ。変更前のものでも同じ。もとから何か問題があるようだ。メモリリークのせい？

セガサターンの仕様

 yabasanshiroのソース調べてたら物凄いサイトを見つけたのでメモ。どう見ても公式の情報なんだけど、なんだこれは？

 https://docs.exodusemulator.com/Archives/SSDDV25/segahtml/index.html

ダウンロードしたい

追記：見れなくなってる 。。。

firefoxが遅い気がする

昔はfirefoxを使ってて、拡張機能の更新？かなにかがあってそれまで使ってた拡張機能が使えなくなったのを機にchromeに移行した。

去年くらいまではchrome使ってたんだが、支払い画面にフィッシングのgoogleADを入れられてからchromeは一切使わないことにした。(金銭的には被害はなかったが、カード番号変えたりで超面倒臭かった)

ちょうどそのころfirefoxがandroidでも拡張機能を入れられるようになり、特別な事をしなくても広告ブロックが出来るようになった。こうなれば最早firefoxに戻らない理由はない。

今はありがたくfirefox+ublockで快適にスマホが使えている。消しても消しても出てくる広告の閉じるボタンをチマチマ狙わなくて良いのだ。

ただ、ページ読み込みの時にしばらくの間止まることが割とあってそこだけはストレス。ublockの処理が終わるまでネットワークを止めているみたいだ。

厳密なブロックのために先読みを止める設定をオフにすると気持ち早くなった気がするが、ublockの為なら我慢して使うしかないか。 スマホがボロいのが悪いのかもしれない。

追記

 アクセシビリティのフォントサイズを自動調整をオフにするとだいぶ快適になる

google検索

長年放置していたせいか、このブログがgoogle検索に一切引っ掛からなくなっているようだ。

大した事を書いてある訳でも無いんだけど、読む価値無しって扱いはひどくねー？フィッシング広告は出してくる癖によー。

まあgoogle直々のフィッシング広告に引っ掛かってからは検索はbing使ってるから別に良いんだけど。(ブラウザは当然firefoxに戻した。スマホでも広告ブロック出来て超快適。chromeとか言うフィッシングブラウザはアンインストール出来ないので無効化している。)

このブログも何処かへ移行しようかとも思ったが、そこまで手間をかける価値も無いのでこのまま放置する。

AwesomeMiner+zpoolでマイニングをやってみる

SBIの株主優待で仮想通貨をもらった。暗号資産の口座ができてしまったので、試しにマイニングをしてみようと思った。

メインで使用しているPCは9年前に買ったMSIのノートPC。一応GPUも乗っているゲーム用ノートPCだったが、windows 11も入らない、かなり時代遅れの代物。

こんなものでどうにかなるのか分からないが、まあとりあえずやってみた。まずNiceHashというのをやってみようとして無理だったので、AwesomeMinerというのをやってみた。

NiceHash

とりあえず検索して目に入ったNiceHashをやってみようとした。ユーザ登録してログインすると、身分証明書を送らされそうになる。

いったん保留して、まずアプリを入れてみる。どっちでもよさそうだが、とりあえず両方ダウンロードする。

firefoxが警告を出してきたが、検索すると、web経由でマイニングさせるツール？と誤検知？しているといったようなことだったので、一応信用して入れてみる。

ところが、実行してみたところ、GPUを認識していないようであった。ソースはgithub公開されているようだったので見てみようかと思ったが、たぶん以下のあたりで、この9年前のPCは対象外なんだろう。

Easy one-click GPU mining for NVIDIA GPUs using microarchitecture (compute capability) SM 5.3+.

 ということでNiceHashはあきらめた。身分証明書を送る前でよかった。

AwesomeMiner+zpool

次に調べたのはAwesomeMinerというもの。いろいろ試行錯誤したが、要は以下を設定しておけばよさそうだった。

インストールしてAdd Newminerで、Managed Profit Miner=>Profit ProfileでnVidia GPUを選ぶ。あとはとりあえずOKにしてFinish。

よくわかっていなかったが、どうやらマイニングをするプログラムとその結果をためておくところ？(pool)は別物のようだ。今どきは個人でマイニングしても太刀打ちできないので、みんなでpoolして、収益を分け合おうという事らしい。

このpoolにもいろいろ有り、どれに参加するかで利益が変わるということのようだ。とりあえずビットコインのアドレスがあれば使える（何の登録も必要なさそう）zpoolというのを使ってみることにした。zergpoolというのも同じやり方で使えるようだ。

OptionsのProfit Switchingでビットコインアドレスを入れておく。zpoolとかzergpoolはいろいろなアルゴリズムでマイニングした結果を、この入力したビットコインアドレスに換金してくれるという事だと思われる。

とりあえずstartしてみる

 

図はいろいろやった後だが、どう考えても電気代の方が高い。やればやるだけマイナスである。こんな時代遅れPCでやるほうが間違っていたという事だ。

マイニング結果はzpoolのwalletで、bitcoinアドレスを検索すると出てくる。

zpool以外にもいろいろ設定できるようだが、分散してしまうので、どれか一つに絞ったほうが良さそうだ。半日～1日くらい動かして、0.00000011BTC、Minimum payoutが0.00075000BTCとあるので、払い出せるほど溜まるまで3500～7000日くらいかかる計算だ。空き時間に小銭でも稼げたらと思ったが、どう考えてもやらないほうがいい。

調整内容

最初は一日0.2円とかだった。いろいろやって改善されてこれである。無意味だったが、一応何をやったか記録しておく。

やったのはベンチマークをとること。

Tools->Benchmarkで計算アルゴリズムの一覧が出てくる。（設定してあるpoolが対応しているもの？）

 

Currentの列がこのPCの計算能力だが、最初は入ってないか、一般的な値？が入れられていたりする。ここで一通り計算して結果を保存しておく。

マイニング中はProfit Switchingのところに、どのアルゴリズムをどういう基準で選んでいるか表示されるようだ。poolとアルゴリズムｘPCの計算能力で最も収益が高いものが選ばれて計算されていると思われる。

 

benchmarkをやらずにstartした場合、この指標がなくて、このＰＣで計算できないアルゴリズムが選ばれたりしており、収益0.02円とかになっていた。（そういう時は計算を実行しているコンソールログにはやれGPUのメモリが足りないだのなんだのとエラーが出ており、まともに計算できてないようであった。）

一応benchmarkを一通り実行することで、計算できないものが選ばれなくなった。ただ、この結果、選ばれるのはCPUアルゴリズムばかりである。GPUが載っている意味なし。NiceHashに対象外されるのも道理だな。