あー、もしかすると自分がブロックされるのも時間の問題なのかもなあ。
GitHubのユーザーブロック機能 (2013/03/24) https://hiroponz.hateblo.jp/entry/20130324/p1
OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
あー、もしかすると自分がブロックされるのも時間の問題なのかもなあ。
GitHubのユーザーブロック機能 (2013/03/24) https://hiroponz.hateblo.jp/entry/20130324/p1
人材を人財って書いちゃう人って、システム障害をシステム障がいって書くんだろうなあ…
でも(伏せる)のソースコードをこのタイミングで公開したのって、10年記念だからというのは表向きの理由で何か裏があるんじゃないかなって疑っちゃうんですよね。
テコ入れ、もしくは撤退か何か、みたいな。
テコ入れするとしたらユーザコミュニティを育てるなりコードの品質を上げる方向で盛り上げていくだろうから、公開して一週間程度でもこの程度であればそっちの可能性は高くないと自分は読みます。
RISC-Vを使った"R"があまり盛り上がっていない現状と、コア部分のみ公開(SPRSENSE版のコードは入れてるけどLPC1114版を何故伏せて、Z80版の名残を意味深に残す?)というのを見るに、なんか処分してるような雰囲気を感じるんですよね。
商売っ気の強いプロジェクトである以上、普通のOSSと同じような感覚で遊ぼうとすると大怪我するかも、と自戒を込めて。
char *p = ((char *)ram+ 0);がz88dk-sccz80で通らない問題、一か所にあるramをoffsetで切り分ける作りにするとこういう計算を要してしまうので、
char p[size_p];
char q[size_q];
のようにバッファを分けるしか手が無いんじゃいかな、という気がしてる。あと16bitの数値(変数)領域をpoke/peekで読めるという部分…多分big-endianなマシンで動かすと動作が変わってしまうという点も指摘しておかないといけない気がするんだよなあ。
keybufの扱いがなんかマニアック(keybuf[-1]を参照してるってコメントにあるけどどういう作りなんだこれ)なので、使ってないならさっくり削除ねーという扱いにしてしまったけど、ちょっとやりすぎかなあ。
とはいえ、公開してから数日たってPR投げまくっても無反応っていうのはまあそういう扱いなのねーという理解なので気にしないことにする。
(単にソースコードを出しはするけど、向こうにとっては「公開した」って実績だけあればいいので後は徹底放置…メンテもしないしコミュニティも育てないよ、っていうスタンスなんでしょう)
char buf[256];
char *p = (char *)(buf + 1); // NG
char *p = (char *)buf + 1; // OK
char *p = ((char *)buf + 1); // NG
な ぜ な の か
(完全にz88dkのバグ踏んでる気が…)
CP/Mエミュレータは https://github.com/jhallen/cpm を使ってる。
z88dkのz88dk-sccz80の構造体のパディングとかその辺がどうなってるかが気になってのぅ…(__attribute__((packed))相当なものが欲しいのじゃが)。
#include <stdio.h>
struct _xxx {
char z;
char d[128];
};
int main(int argc, char *argv[])
{
struct _xxx x;
printf("%x\n", &x.z);
printf("%x\n", x.d);
return 0;
}
uaa@framboise:~/cpm$ zcc +cpm -lm -lndos test.c -o a.com
uaa@framboise:~/cpm$ ./cpm a
db3d
db3e
uaa@framboise:~/cpm$
uint8* /*const*/ screen_pcg = ((uint8*)(ram + OFFSET_RAM_PCG)); // 同じ
これもダメ。多分構文解析する際に(ramが変数なのはともかくOFFSET_RAM_PAGEが#defineされた定数であっても )「計算する奴は許さねえ」という作りになってるんだろうなあ。gccとかclangじゃこんな書き方はごく普通にやるのに。
これは、アレか。どっかで固定的に確保したメモリをオフセットとサイズで切り分けるんじゃなく、
int16 var[SIZE_RAM_VAR / sizeof(int16)];
で確保するパターンなのかも。というか別にそれで良くね?(真面目にやるとリンカスクリプトとかでサイズやアドレスを調整する世界にもなりかねん)
screen.h
uint8* const screen_pcg = ((uint8*)(ram + OFFSET_RAM_PCG)); // 同じ
basic.h
int16* const var = (int16*)(ram + OFFSET_RAM_VAR);
keyboard.h
char* keybuf = (char*)(ram + (OFFSET_RAM_KEYBUF + 1)); // kbhit[-1], len:[0], buf:[1-(KEY_BUF_LEN-1] // 24512+60 // 小さい!
ram.h:#define OFFSET_RAM_PCG 0 // basic:#700
ram.h:#define OFFSET_RAM_VAR (OFFSET_RAM_PCG + SIZE_RAM_PCG) // basic:#800
ram.h:#define OFFSET_RAM_KEYBUF (OFFSET_RAM_LIST + SIZE_RAM_LIST) // basic:#1002
uint8* const screen_pcg = &((uint8*)ram)[0];
これもダメでした。
なにこれ…z88dkの問題だと思うんだけど、グローバル変数の宣言で
uint8* const screen_pcg = (uint8* const)(ram);
このコードは通るのに、
uint8* const screen_pcg = (uint8* const)(ram + 0);
は
../IchigoJam_BASIC/screen.h:122:50: error: Expecting constant expression
と言われてしまう。
同じじゃん!