That's really good to know! Basically what I did before was keep adding RAM tiles until I got graphical glitches and then subtracted one RAM tile.uze6666 wrote:Woa, only 4 bytes free?!? You're really running after trouble! As a rule of thumb never go over 97-98% ram usage to leave some stack for the kernel interrupt. I can tell you that sound issues already happened to me a long time ago when I was pushing the ram a bit too tight (that and random crashes and glitches). I never profiled the kernel for its top stack usage but it's probably in the range 60-80 bytes. Usage is spread across:So yeah, if you triggerFX and the internal call stack is at it deepest (2 sub functions calls) and a rendering interrupt occurred at this precise time, I could well create such issue.
- Video rendering interrupt: pushes all registers and flags (33 bytes)
- Video mode: uses the stack at varying levels, probably 10 bytes in average
- Inline mixer: pushes 5 registers
- Music engine: this one is in C and I tried to limit the number of function calls. But it could eat up to 50 bytes.
Sadly, it turns out the issue is only mostly solved. I play tested it for an hour with no glitches before I posted saying that I think it's fixed. After posting, the very next time I ran it, a note was sustained, but that's the only time it's ever happened, and I haven't been able to make it happen again.
Using this method to measure stack usage should include anything that the kernel does with the stack, since I presume if it's using more stack that it would overwrite the canary values with something else. The one time that I did get it to sustain a note, I looked and saw there were still 26 canary values untouched, so I guess there goes the theory of me being too close to the RAM limit and having something in the kernel blowing the stack.