Kerm and Mateo pushed me to create a thread with all of my questions.
My current project is a port of the World's Hardest Game for the TI 84+CE.
On this thread, if you answer a question, please include the why and how, and possibly some sample code to get me started.
Thank you for your help!

My first question is... how do I move a square around the screen in ez80 asm?

While that is a fantastic idea for a starting program, you may want to start even simpler. Such as, how would I draw a rectangle on the screen in the first place? The CE's LCD supports many different modes, and is in 16bpp as default. The location of the LCD's data is located at the memory-mapped location called VRAM, which equates to 0xD40000. You will need to come up with some code that draws a line at an (x,y) point, and then repeat this same horizontal line for the height of the rectangle. If you need some coding guidance, we would be more than happy to help.

That probably is a better program to write. How do you write to the LCD? I think that is a better question.

WikiTI is your friend. Take a look at the LCD controller and the memory layout. To get things to display on the screen, the easiest thing to do is to write to the LCD memory (VRAM/GRAM, starting at address D40000h). It's arranged as 240 rows, each 320 2-byte pixels wide, for a total of 320*240*2 bytes. The pixels are each 16 bytes representing bit-packed red, green, and blue values: 5 bits of red, followed by 6 bits of green, followed by 5 bits of blue. SourceCoder and other tools can help you translate between 24-bit color (8 bits each of red, green, and blue) and the 5-6-5 format.

Edit: For example, set the top-left pixel to white, and the bottom-right pixel to black:
Code:

Kerm, that code is exceptional!
My next question comes from trying to implement that as a routine. I have the following code:

Code:


This immediately crashes the calculator.
Does anyone know what I am doing wrong?

The problem is you are treating addresses like variables. They are not variables, just locations in memory where you can store things to. This should work better; hopefully this is a better thing to learn off of. Note this is untested.


Code:

Thank's mateo. Now I am trying to figure out how to clear the screen on each draw, implementing solid frame rate. Code is as follows:


Code:

I would really, really recommend you take a look at the manual and see how jumps and calls actually behave. You only need to clear the screen if the down key is pressed, otherwise the data should remain fixed. Here's an example of what I mean:


Code:

Do you have to write pixel by pixel or is there a faster method than this: (this isn't even done)

Code:

And so on...

That's how the program flow works, but even if you wanted to do this exact thing, here's what you would do:

Code:

And call it from a loop. I don't remember exactly how to make loops so you'll have to do that yourself.
(Also man I need to get back into CSE ASM)

Here is my working code
It creates a "World's Hardest Game" like sprite that moves around the screen. Press mode to exit.


Code:


Is there a way to modify this so that if you do, for example, both up and right, it does diagonally to the northeast?

Also, is there a ROM call to draw a circle of a certain radius at a certain coordinate?

I don't think _GetCSC supports multiple keypresses, it only returns one keypress (the first key pressed/held/read). You'd have to read from the key registers directly.

For drawing horizontal lines (which is often what you'll want to do), there is a much faster way.

Code:


For drawing arbitrary shapes (AKA sprites) you will have to write a sprite routine.

Note to Mateo: Wouldn't it be better to start learning graphical stuff in 8bpp mode? I find it a LOT easier to work with, and it doesn't require that much extra setup.

Adding a bit to what Hactar said, with a sprite routine what you are essentially doing is drawing a box. The VRAM is one continuous chunk of memory, so what you can do is something like this:

Code:
That should (hopefully) draw a sprite to the top left corner. You'd probably want to add x/y coordinates for the sprite, too. You just need to change the starting VRAM position (add the x/y offset).

Hello all, this code isn't doing anything right, here it is, in case you know what's wrong xD
Known issues:
Wrong colors
Box is stretched out (wide)
Doesn't end on pressing mode, I'd assume because the loop continues to execute, but I dunno at this point
Screenshot:


Code:

And sprite.bin:

Code:

What have you done to debug it so far? You probably already know this, but I strongly recommend trying to solve one of those issues at a time, rather than getting overwhelmed looking at the whole list. Also, as a general piece of advice, I usually try to build my programs one component at a time, making sure that component (for example, displaying a sprite) works correctly before adding the next component on top. That can help you track down which component a particular problem is coming from, even if you don't have an emulator or debugger available.

I agree with Kerm, adding components one at a time (and debugging them one at a time) is how i generally do things. That way you can make sure one thing is (more or less) working before moving on to the next. Writing a ton of code all at once is a great way to get a headache and spend more time debugging than coding. The mode issue is pretty simple. Look at your code here:

Code:
Do you not see anything odd here? First off, your endGame routine is called. When it's done running, it'll return to where it was called from and continue running. I assume this is why you added the ret z. But keep in mind that the flags change very often, in your endGame routine you use two system routines. Both of those almost certainly change the values of the flags. If you want to preserve the flags, you'd have to put the af register on the stack and pop it before you exit endGame. But a better solution would be to directly exit from the endGame routine. Rather than calling it, what can you do so that it doesn't return back to the main loop?

For the other questions, i can't help much. Try drawing different types of sprites, for example a sprite like this:
111111111
101010101
101010101
...
111111111
You can maybe get an idea of what's going wrong and where. Though if your sprite is 8bpp, why do you load the value two times in drawLoopLine8bpp? (ld (de),a \ inc de \ ld (de),a \ inc de)

EDIT: Btw, call label \ ret is the same as jp label.

Thanks, Chickendude. I didn't see that I was calling instead of jumping. :
Also, I fixed the width issue. My issue is now only with the colors and another issue with ending:
I have to press mode twice to end, once to switch into 16bpp mode and again to finally quit.

The issue might be because you call drawFrame at the start and then the code continues running (back to drawFrame). Actually, now that i look at it, it looks like your palette code never runs until you exit with [Mode]. Try removing (or commenting out) the first call to drawFrame and seeing if that fixes anything.

Based on the discussion of your ASM code on IRC, I wanted to clarify and expound further on a few points:

• The best use of ASM tutorials is as a way to learn techniques, test them out by running the code provided in the tutorials, extend them by modifying the given programs slightly to see if hypotheses about how you can modify them work, and then write and test your own code with those techniques. Tutorials shouldn't be considered a source of code to copy-and-paste into your own independent, released programs, because that usually implies that you don't understand the concept well enough to write it yourself.
  
• With any language, especially ASM, start small and work your way up towards larger and more complex projects only as you're confident about it. Better to knock out a few projects that are at or below your skill level and build experience and confidence than to get frustrated trying something above your skill or concentration.
  
• ASM is the extreme of a structured language, where what you write is exactly what the processor will do. Before you write the program, outline what you want it to do. If you must, make a flow chart or write pseudocode. When you're debugging your code, try to execute it line-by-line in your head as if you were the processor, tracking the values of registers and seeing where what happens diverges from what you expect to happen. Add debug print statements (and when we get an emulator, use the debugger!).

Good luck. And remember to post questions (including code) in this thread.