Keep asking questions; we need the traffic.

Yup, and we get bored (and destructive) if we get left alone too long.

And when we get bored, we code massive and useless programs. Keep us occupied!

Gladly! How are things displayed directly to the lcd? I've been using plotSScreen as the address to send my bytes to, but it's gotten annoying in that the display only updates when I either go to the graph screen outside of program execution or use GrBufCpy.

*cough DoorsCS 6 cough*

There is an LCD driver, and two LCD ports for it. It's usually more have a hassle to manipulate the LCD directly, so plotsscreen is normally used, and then it is copied form there to the LCD with GrBufCpy, ionFastCopy, or something else like that. You can learn more about it here, and/or wait for the more experienced assembly coders to come and elaborate/correct (on) what I said.

That explains everything! I like that much better than relying on a slow ROM call. The only problem that I foresee is not having the display backed up on the calculator anywhere.

I should look through Asm in 28 Days more often. I bet it would answer a lot of my questions.

Edit: I just came to the realization that, even though I could speed what I do plenty by displaying directly to the LCD, there's no reason to spend so much time doing that if I'm not already having problems with speed.


If anyone could answer this following thing for me, however, I would be very grateful: When I use GetCSC, no keypress usually returns $81, but sometimes returns 0. What should happen and what could be going wrong?

That is really weird. Can you post the code you used for getting/displaying the keypresses?

Code:
Well, it's working like it should again. That was really annoying when it didn't, though.

And always remember to do 'or a' (B7) rather than 'cp 0' (FE00).

Edit: 800 posts!

Those two bytes thank you.

Ok... I've made a little thing to display an 8x8 sprite in the top-left corner of the screen, based on in-program data. Can anyone think of optimizations or better ways to do this?
Code:

The sprite's supposed to be a little robot guy. Wow, this is good practice for opcode reading!

Definitely don't do the ex af,af' thing - you'll fail epicly if an interrupt triggers inside that.

Ok.
Code:

It's a little more efficient if you put the sprite data at the end, but if you're assembling by hand, that's too much work and I don't blame you. Other than that, looks good. (Although you could use the stack to preserve A rather than use AF', since interrupts are nice to keep on)

I seem to be having trouble with stacks. Whenever I try to push or pop anything, my calc crashes (both of the ones I've tried). An example of this would be this, which should pop the 2 bytes from (SP) to DE:
Code:
The calc crashes when I try to alter SP an any way. Can anyone think of a reason for this?

It's certainly going to crash if you try taking something off the stack without putting something on first, but I'm sure you know that, so no. There's really no reason for it crashing.

If you're just mucking about with the SP register without disabling interrupts (stuff like incrementing sp), you could easily get a crash. If you're just pushing and popping, though, it'll work fine.

Since when is the pop instruction two bytes? I think you're using the wrong opcode. And yes, you have to match pushes and pops - never pop until you've pushed.

Why would this simple little prog crash?
Code:
Opcodes:
Code:

Because the SP isn't in the same spot it was when the program started - you do know that other things (*cough, TI-OS, cough*) use the stack also, right? Likewise, RET uses the stack to know where to return to, so you are returning to a random address as the two byte return address is no longer aligned properly with the SP (since you inc'd SP, but didn't decrease it)

You should probably go read about the stack in "Learn Z80 in 28 days" before trying to use it in a program