Hmm, okay then thanks!

Though if you use macros, be careful to note which registers they modify since you won't see the "ld hl,buffer" anymore.

As for passing arguments on the stack, it's not that common but i've done it before for a text routine, whenever i came across a command to display something special (another text, the player's name, a number, etc.) i just pushed that value onto the stack. So the routine would read through the stack until it read a $0000 value

Thanks for the help chickendude.

New Question: Is there a faster way to fill in empty bytes into a range of address such as $8000 to $8000F without having to do it manually?

Well are you trying to fill the bytes with all the same number? i.e. 0. If you are make a loop that loops through $8000 to $8000F with that number. Or if it is increasing numbers, do the same but have a counter and increase each time you store it.

If you want to fill it with the same byte, you can do:

Code:

If you want to copy something like a string of 15 bytes from one place to another, you can do something like:

Code:

If you want to fill those bytes with zeros, I like to do:

Code:

Hmm, wow, thanks Xeda! Actually what do the ldir and djnz commands do?

LDIR stands for something like 'LoaD Increment Repeat'. It loads the byte at (hl) into the place pointed to by (de). Then it increments HL and DE, decrements BC and repeats this process until BC = 0

DJNZ will decrement B and jump to the label, as long as B is not 0. It is like doing this (but faster and smaller):

Code:

Can someone please explain this code?


Code:


I mean i get what it does, in terms of stack, I just need an explanation of what the commands are doing, especially with how the ()s are being interacted with.

Also thanks Xeda.

As a full example:

Code:


So, on line (A), it just defines a variable, STACKSIZE to be 100. This is only visible during assembly, and isn't actually stored on the calculator. Line (B) references another assembler-only variable "stack_ptr" which you can think of as simply being an address. The address, if you looked at that location under a memory debugger, would be a single word (because of the ".dw", "data word"), which in the case contains the address of "start_of_stack." Using the parentheses with an address between them (which "stack_ptr" is), causes the calculator to load a byte or word of memory into another register, in this case HL. After that command is executed, HL contains the value/address of "start_of_stack."

Line (C) uses indirection again, but slightly different. The parentheses load from a memory location if that's what's between them, or if it's a 2 byte register (Such as HL, DE, and a few others) it would load the memory that is contained at the address the register points to. In this case, HL points to "start_of_stack", so line (C) stores the value of register E to "start_of_stack." Don't forget that, when using "LD", the first argument is where to store, and the second is what to store. Line (D) just increments HL by one, causing it to point to "start_of_stack + 1." Lines (E) and (F) should be pretty self-explanatory.

Then on line (G) it uses indirection with an address to save the new value of HL (which points to "start_of_stack + 2" to "stack_ptr." This way, next time you run lines (B) through (G) again, it will be pointing to the next part of the stack and work as expected, so that you don't overwrite old parts of the stack.

Finally, line (H) creates a assembler variable "stack_ptr" which points to a word (I) that initially points to "start_of_stack." And line (J) creates another one and uses a Brass feature to create a large block (size STACKSIZE, or 100, bytes) of memory, all set to an initial value (0x00).

(Also, since I'm pretty sure someone will call me out on it: when using ASM, you don't necessarily "compile" code, you just "assemble" it. Assembling just changes the forms (one using mnemonics, the other using machine language) whereas compiling actually creates new assembly code from your program and doesn't give you full control over what the processor sees.)

That is, it takes the two-byte value at the specified location and loads that into HL.

For example, we'll put 0x1234 in memory at 0x8000:
Code:
We end up with 0x34 at 8000, and 0x12 at 8001 (seemingly reversed with the high-order byte lower in memory because the Z80 is little-endian).

With that, your ld hl,(xxxx) is equivalent to this:
Code:
Well, this is slower and clobbers A. But you get the point (I hope).

See also: 83pa28d (as pointed out by Runer in IRC as I was composing this).

In z80 assembly, anything with parentheses (except for 1 instruction, I believe) is indirection. What that means, is that the stuff in the parentheses points to a byte in RAM. For example, (hl) means "the byte that HL points to" and ($8000) means "the byte at $8000." something like add a,(hl) will take the byte pointed to by hl and add it to register a. Something like ld a,(OP1) will take the byte at OP1 and load it into a, ld (OP1),a will load the value of a to the byte at OP1.

Depending on the context, you might actually load 2 bytes. For example, you can do ld (OP1),hl and that will store it little endian (you might think of this as 'backwards'). So L→(OP1), H→(OP1+1). ld (**),hl is 3 bytes, ld (**),de, ld (**),bc, ld (**),sp are all 4 bytes.

Z80 does not have a lot of indirection support. You cannot do add a,(OP1) and you cannot use something like ld bc,(hl) You can use (hl) almost anywhere you can use a register, though.

Later, you will probably encounter index registers (IX and IY) and this stuff will be important

There are also the in/out instructions that use the parentheses to communicate with the ports. in a,(1) reads a byte from port 1 (the keyboard). But i think the instruction Xeda was talking about is "jp (hl)", which is really equivalent "jp hl". Basically, if HL = $9D95, "jp (hl)" will jump to the address $9D95 instead of reading the two bytes stored at $9D95 and jumping to that address (what you'd expect it to do since it looks like it should be using indirection, but it doesn't).

Also, the stack generally works downwards, meaning it starts at $FFFF and will work it's way down towards $0000. So when you push a value onto the stack, the stack's address actually gets lowere. Popping a value off the stack will increase the address.

EDIT: There's also the age-old:

Code:

Many thanks to all the people who just helped with that.

Next:
In this instruction:

Code:


What is the point of the C, and possibly NC. I get that they are carry flags and stuff, and i know flags are used to indicate stuff. But i don't get why it's needed here.

With no code between the jump and the destination like that, it's useless. But when actually making decisions about whether or not to execute certain code, conditional jumps are essential.



A simple example might be to take the absolute value of a number. If it's positive, you don't want to do anything to the value. But if it's negative, you want to negate it to make it positive. In C, coding such logic might look like this:

Code:


In z80 assembly, coding the absolute value logic might look like this:

Code:




For more advanced decision making, simply use multiple jumps! Let's say you wanted a piece of code that brings a signed integer closer to zero by one (or do nothing if it's already zero). In C, that might look like this:

Code:


In z80 assembly, it might look like this:

Code:

Thanks Runer, I understand that now.

Next thing, can someone give an example of the ret and call commands, and how they're used?

For the sake of simplicity, we will look at a subroutine for multiplying HL by 12. To do it inline, we would do:

Code:

However, if you want to use this as a subroutine, you would put an RET at the end (for RETurn) and use the CALL instruction to call the subroutine, like this:

Code:

In practice, I never use HL_Times_12 as a subroutine. 'CALL' uses 3 bytes and an additional 17 cycles, RET uses a byte and 10 cycles. In-line, it is 6 bytes and 52 cycles, so you would need to use the call at least 3 times to get any size savings. However, calls are very useful if you need to use more complicated codes in several locations, like sprite drawing routines. Then using calls could save hundreds or even thousands of bytes (depending on the size of the code and how often it is used).

bcalls are a special type of call as well. When you use bcall(_whatever), you are actually using a special type of call instruction, rst 28h, which directly calls the code at address 0028h and has the code for the bcall subroutine. The OS then use the two bytes following it to redirect the call to another location (it is actually a pretty complicated changeover).

Thanks Xeda112358! My next two questions are how do I compare greater or lesser than in between two registers (8 bit registers) and how do i generate a random number between range of a and b?

For comparing two values, there is the CP instruction which compares the register A to another register or a constant. The valid instructions are:
CP B
CP C
CP D
CP E
CP H
CP L
CP (HL)
CP A ;redundant, but this resets the c flag, sets the z flag
cp * ;* is an 8-bit constant

If A and the given register are equal, the z flag is set, else it is reset. If the register is greater than A, then the c flag is set, else it is reset. For example:

The way I remember the c and z flag is by pretending I am using sub instead. For example, sub 10 returns the c flag set if a<10 and cp 10 returns the c flag set if a<10. Often I use sub instead of cp if I do not need to preserve a since I find it easier to remember how it works and it often leads to optimisations later.

You can actually "create" a 16-bit CP instruction with HL and BC or HL and DE (or HL and SP, but Hl is redundant and SP is rarely used this way):

Code:


For a random number on a range from a to b, there are a bunch of options. As well, depending on the situations, there can be tons of optimisations. If you want more methods, feel free to ask, but here are a few simple methods:

Code:

If you know for sure that you are going to be having an interval of at least 11, you can actually save on time and size by using the naive method of division:

Code:

I'm pretty sure 0 is also considered positive, so you don't need to handle the z flag here

There's also (ix+nn) and (iy+nn)

Random number routines generally involve use of the r register, as its value is constantly updated as your program runs. Really, it gets incremented every M1 cycle (where the processor fetches the opcode), you can sorta think of this as incrementing once every instruction, but some instructions have more than one M1 cycle (possibly up to 3?). This is why r is often used in random number generators, since its value is constantly changing as your program runs. However, the last (highest) bit never changes, only the lower seven bits.

Thanks for all the help guys :'D really appreciate it.

So I wrote my first full program/routine: (a numerical input routine) and was wondering how to optimize it in any possible way.


Code: