I know this is the third new thread I've made on the z80 board, but I think that this is a thread that could help anybody interested in beginning z80 assembly.

I'm learning z80 asm from the 28 days tut. While the tutorial is, for the most part, clear and concise, the author doesn't have any exercises!! I'm not always the most imaginative person, so I've had some difficulty designing exercises for my new asm learnin'

I think it would be cool if this forum could convene and create a list of problems (and maybe solutions to the problems), easy and difficult, to stretch the minds of fledgling z80 asm coders like myself.

So, post a problem, post 10 problems, post ones you made up yourself or ones you stole from a jenky old c++ book, post anything you can think of!

I'll start with a few that I've made over the past week

1. Make a program that increments a number when you press up/down and displays the number on the screen. Bound the number between 0 and 100 or something like that.

2. Take the previous program and modify it so that when enter is pressed the current number is multiplied by 2.

3. Make a program that moves a character around the screen. When you press up, it goes up, down, it goes down, yada, yada.

4. Make a game where a horizontally moving character at the bottom of the screen has to move laterally to catch randomly generated falling characters. Display a score and make it so that each character that falls off the bottom of the screen loses you a life.

If you have succeeded in making all four of those work, then I congratulate you; your knowledge is moving along very fast indeed! For your program (3), where you move a character around the screen, I might like to challenge you to use a sprite and the graphscreen instead. You'd need a sprite XOR function to draw and erase the sprite (more efficient than erasing the entire screen) and a routine to copy the graph buffer to the LCD fast; luckily Doors CS (and other shells, if you prefer) have iPutSprite and iFastCopy for such purposes. I'm trying to think how you might be able to expand your examples for more functionality besides better graphics.

I think for 0.5, one of the programs should be a basic counter program (count from 0 to 100 and display each number). That was my first program that I didn't just copy code for, and I think it really helped me with z80 ASM. For (2), I'm curious what you chose to do for multiplying by two. Basically, are you using a loop, or a single instruction? And I second Kerm's suggestion of using sprites and the graphscreen as a way to make 3 and 4 more challenging

Ah yes, thank you for saying that, _player. I remembered that you had a first program that you've quoted a few times before, but I couldn't remember what it was exactly. I would like to know if Rascherite has indeed made those programs, or just made the ideas for them, as that would dictate how difficult my suggested exercises might be.

I'd like to do it in the graph buffer, but I want to get the hang of using basic functions before I start working with graphics, so I'm trying to seek out exercises to test my asm ability that don't require use of advanced i/o.

Sounds smart. To clarify our questions above and help us tailor exercises to you, therefore, did you or did you not complete those exercises that you set for yourself in your first post yet?

Yes, I have completed all of them (except for the last one, I haven't added a score tracker yet)

I actually did everything until number 4 before reading this post

Very impressive! Then sticking with things you can do with the homescreen, how about a menu sort of thing similar to TI-BASIC's Menu() command? Also, I vote that you show us some of your code so we can critique your style and see if you're doing anything accidentally inefficient, if you don't mind.

Sounds fantastic! Tear it apart for me. Should I upload it somewhere or can I just put it inline here?

I think this is what I did for exercise 3:

Code:

I know that it's not optimized.[/code]

You've fallen into the classic trap of that program, I'm afraid. You repeatedly cp and call z, but you're modifying the accumulator in the routines that you call! If you hit the wrong coordinates, it will make the character move unexpectedly. It might not show up in the coordinate range of the homescreen, but switch that to the graphscreen and you'll the issue.

ah! That's why the T moved randomly sometimes XD
thanks.
EDIT: is there a way to fix it, then?

You could jr to your routines instead of calling them, and have them jr back into LOOP to display the string.

ah. so like jr z,GOUP?

hahah I'm not suprised other people have done exercises like these, I'm not the most creative sometimes...

Here's code for...
1/2. I just looked at this code and it is BAD. I don't really wanna go back and correct it, so I don't wanna post it here. If anybody thinks itd be THAT valuable, I guess I could fix it up

3.

Code:


4. (still without score)

Code:

I know the way the timing work is odd, tips on that please.

Criticism is appreciated!! I want all the knowlege this glorious forum has to give.

Yes, exactly. And, in GOUP (and similar routines), you would jr back into the place in LOOP where you display the string instead of returning.

ah, ok.
I'll try that soon.

First-pass tips from looking through your program, on instruction-level things. I'll do a higher-level second pass over your program structure later.

1. ccf is "change carry flag", not "clear carry flag". Therefore, scf/ccf is the same as the non-existent "reset carry flag". Faster and smaller way to clear the carry flag: "or a".


Code:


2. Whenever you want to ld a,0, do xor a instead. It XORs the accumulator with itself, which of course (if you are familiar with xor) sets A to all zero bits, faster and one byte smaller than ld a,0.

3.
Code:
You're most welcome!

4. Regarding randomness:
Code:

I don't know how opposed you are to using shell/DCS functions, but you can get much, much better randomness and uniformity by using something like the iRandom function. 'r' is based on simple counting of clock cycles, so in a fairly structured program patterns will appear very quickly.
http://dcs.cemetech.net/index.php?title=IRandom

5. I continue to suggest that you name things like "AppBackupScreen+4" instead of having those throughout your code.

6. Try to think about where you can re-order instructions to save bytes. For example:


Code:

Thank you for all the info, Kerm!
1-3. Make perfect sense

4. All due respect to you and your fantastic shell, but I'm a programmer who likes to reinvent the wheel, for better or for worse. I'll eventually write a legit random number generator, but I want it to be my own.

5. I will start doing that, but in my defense, when we talked about that earlier, more than 3/4 (if not all) of this program was already written.

6. So, ld a, h has a shorter opcode than ld a, 0 ?