22:19:48 @uaa@social.mikutter.hachune.net
icon

あー、もしかすると自分がブロックされるのも時間の問題なのかもなあ。

GitHubのユーザーブロック機能 (2013/03/24) hiroponz.hateblo.jp/entry/2013

Web site image
GitHubのユーザーブロック機能
22:18:14 @uaa@social.mikutter.hachune.net
icon

人材を人財って書いちゃう人って、システム障害をシステム障がいって書くんだろうなあ…

22:16:31 @uaa@social.mikutter.hachune.net
icon

でも(伏せる)のソースコードをこのタイミングで公開したのって、10年記念だからというのは表向きの理由で何か裏があるんじゃないかなって疑っちゃうんですよね。

テコ入れ、もしくは撤退か何か、みたいな。

テコ入れするとしたらユーザコミュニティを育てるなりコードの品質を上げる方向で盛り上げていくだろうから、公開して一週間程度でもこの程度であればそっちの可能性は高くないと自分は読みます。

RISC-Vを使った"R"があまり盛り上がっていない現状と、コア部分のみ公開(SPRSENSE版のコードは入れてるけどLPC1114版を何故伏せて、Z80版の名残を意味深に残す?)というのを見るに、なんか処分してるような雰囲気を感じるんですよね。

商売っ気の強いプロジェクトである以上、普通のOSSと同じような感覚で遊ぼうとすると大怪我するかも、と自戒を込めて。

22:04:30 @uaa@social.mikutter.hachune.net
icon

char *p = ((char *)ram+ 0);がz88dk-sccz80で通らない問題、一か所にあるramをoffsetで切り分ける作りにするとこういう計算を要してしまうので、

char p[size_p];
char q[size_q];

のようにバッファを分けるしか手が無いんじゃいかな、という気がしてる。あと16bitの数値(変数)領域をpoke/peekで読めるという部分…多分big-endianなマシンで動かすと動作が変わってしまうという点も指摘しておかないといけない気がするんだよなあ。

21:52:37 21:56:23 @uaa@social.mikutter.hachune.net
icon

keybufの扱いがなんかマニアック(keybuf[-1]を参照してるってコメントにあるけどどういう作りなんだこれ)なので、使ってないならさっくり削除ねーという扱いにしてしまったけど、ちょっとやりすぎかなあ。

とはいえ、公開してから数日たってPR投げまくっても無反応っていうのはまあそういう扱いなのねーという理解なので気にしないことにする。

(単にソースコードを出しはするけど、向こうにとっては「公開した」って実績だけあればいいので後は徹底放置…メンテもしないしコミュニティも育てないよ、っていうスタンスなんでしょう)

21:04:22 @uaa@social.mikutter.hachune.net
icon

なんかぶん投げたくなってきたな。今日はぶん投げるか。明日の俺よろしくーって。

20:41:59 @uaa@social.mikutter.hachune.net
icon

char buf[256];

char *p = (char *)(buf + 1); // NG
char *p = (char *)buf + 1; // OK
char *p = ((char *)buf + 1); // NG

な ぜ な の か

(完全にz88dkのバグ踏んでる気が…)

20:20:40 @uaa@social.mikutter.hachune.net
icon

CP/Mエミュレータは github.com/jhallen/cpm を使ってる。
z88dkのz88dk-sccz80の構造体のパディングとかその辺がどうなってるかが気になってのぅ…(__attribute__((packed))相当なものが欲しいのじゃが)。

Web site image
GitHub - jhallen/cpm: Run CP/M commands in Linux/Cygwin with this Z80 / BDOS / ADM-3A emulator.
20:19:30 @uaa@social.mikutter.hachune.net
icon

<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$

06:32:33 @uaa@social.mikutter.hachune.net
icon

uint8* /*const*/ screen_pcg = ((uint8*)(ram + OFFSET_RAM_PCG)); // 同じ

これもダメ。多分構文解析する際に(ramが変数なのはともかくOFFSET_RAM_PAGEが )「計算する奴は許さねえ」という作りになってるんだろうなあ。gccとかclangじゃこんな書き方はごく普通にやるのに。

06:25:47 @uaa@social.mikutter.hachune.net
icon

これは、アレか。どっかで固定的に確保したメモリをオフセットとサイズで切り分けるんじゃなく、

int16 var[SIZE_RAM_VAR / sizeof(int16)];

で確保するパターンなのかも。というか別にそれで良くね?(真面目にやるとリンカスクリプトとかでサイズやアドレスを調整する世界にもなりかねん)

06:22:02 @uaa@social.mikutter.hachune.net
icon

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: OFFSET_RAM_PCG 0 // basic:#700
ram.h: OFFSET_RAM_VAR (OFFSET_RAM_PCG + SIZE_RAM_PCG) // basic:#800
ram.h: OFFSET_RAM_KEYBUF (OFFSET_RAM_LIST + SIZE_RAM_LIST) // basic:#1002

06:15:13 @uaa@social.mikutter.hachune.net
icon

uint8* const screen_pcg = &((uint8*)ram)[0];

これもダメでした。

06:13:56 @uaa@social.mikutter.hachune.net
icon

なにこれ…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
と言われてしまう。

同じじゃん!