ChibiAkumas ASM Programming Forum

Edit: nevermind

Still no idea how to fix it.

This could be happening for a few reasons:

1. Your sprite is going offscreen, and corrupting data outside of VRAM (could even be the stack)
2. Your code is leaking something - for example pushing more than it pops, eventually the stack fills over time and the machine crashes
3. There's particular part of the code which is causing the problem. you could be doing something like writing to (DE) instead of (HL), You may get away with that 99 out of 100 times - but the 1 time will crash

Here's the things to try:
1. Does the program crash over time if you do nothing?
2. Try to do limited things over and over (eg press left 3 time, then right 3 times), does it crash in this case (could be a bug like mentioned above) - or is when you touch a certain point (could be a calculation issue in your drawing routines)
3. Try disabling parts of the code one by one - That may be the part that is broken, but it could be just a bug in another part of your code overwriting that code.

I know it sucks, but debugging is hard and you've just got to do it. I can't decide to build a house and expect other people to do all the hard bits like plumbing and electrics for free - the same is true of writing a program, no one likes debugging their own code, so they certainly won't want to debug yours!

I've just spent a month porting and debugging the 68000 tilemap code for my 'MaxTile' graphics routine. It had to work identically to the Z80 version, but just showed a black screen at first. All I could do was look over all the code, look at what the code I'd written did (knowing what the commands do - not looking at the output, there was none!), ask myself what it should be doing, and think about if there's something wrong with the code. I did all this without a debugger of any kind (I've become accustomed to not having one). Can't see the problem? no neither could I, you just have to keep at it, hour after hour, day after day, week after week (if required) until you figure out or spot what's wrong and fix it.

Look at the code and ask yourself what the code IS actually doing (not what you want it to do).
Try to think like the machine, ask yourself what the code NEEDS to do to get the result you want.
The crash is the difference between what you've written, and what you meant to write!*

*I'm not saying that to be rude or insulting, but it's just how I debug. You can't look at your code and go 'Oh yes this routine draws a sprite', you need to go deeper and look at it line by line and think what effect that line has... because your 'sprite drawing' routine is a an effective 'code destroying machine gun' if you load it with the wrong destination address, or a 'stack corruption freight train' if you forget to POP an item you pushed in your drawing loop!!!!.

Over time it gets easier, you start to be more familiar with the CPU commands, and exactly what they do (changes to flags etc) you also start to recognize what will cause a crash (EG Sprite clipping issues in ChibiAkumas caused crashes on the speccy when sprites when of the bottom of the screen due to the stack being just below VRAM. On the CPC resets are often the result of junk pushed onto the stack before a return - as Call &0000 is a reset.). It takes time though, so if you're struggling all you can do is go back to something simpler, even if it's just trying out z80 commands in a debugger+monitor like my Z80 tutorials.

Finally, I recommend Winape for beginners, it has an Assembler and Debugger built in. I know you want to program the speccy, but Winape will be easier if you're new to Z80

Edit: nevermind

Oh, so you You solved the problem already.
it's a good job I didn't spend any time trying to help you then isn't it!

I appreciate your help anyway and will take it as a advice.