No. No no no no. You're still thinking like BASIC. You need to actually spend at least a month on ASM in 28 Days, reading each lesson over a couple of times and maybe making a few little programs to make sure you understand everything in that lesson.

Wait are you interested in interfacing basic user variables with ASM code? because if you're not, like everyone has been trying to say, variables in ASM as kinda different. It can be hard to grasp at first.

What you have to understand is how your calculator really works. You see BASIC will hide all of that nasty stuff for you. In exchange, it can be slow and cumbersome because it has to check that you didn't make mistakes.

Now, the calculator, and even computers, are nothing more than lots of transistors stringed togethers. Off and on (0s and 1s) will create numbers, commands, etc. Groups of eight are bytes. Each byte has a name, or a memory address. That memory address is nothing more than a number that conveniently will fit into two? bytes. You can do the following with memory addresses: 1) store a number between 0 and 255, or 2) start running whatever command is stored there (that's a little complex though unless you know hex). The nature of this means that anything can be data and anything can be command. We can use this to our advantage later on!

The first question is, where does your program start? At the begining!!
But where did it actually start? Do you know the exact location of your program start before it gets loaded onto the calc? No, which is why everything you code in ASM in relative to each other. The start of your program is always the program start label. Label is a bad name because I know in basic, you think a label is somewhere you can goto. Well, that's kinda the case in ASM. But actually, an ASM label is actually a memory address. We just give it a name (label) because we don't want to call the battle engine loop 0xFF.. and a bunch of hex. We want to give it a meaningful name.

So for variables:
label = memory address for a number between 0-255.

for strings, lists, matrices, arrays, structures, etc.
label = memory address of first byte of such a structure.

for functions:
label = first byte of executable; often times first command, but most ASM commands are stored in multiple (1-3) bytes.

Now, let's start simply with accessing a single byte with its own label:
the idea is that we need the memory address. But you already know it! You even gave it a name so that you don't have to figure out what the number actually is. So you load the name into hl or another register pair.

But what good is an address if you can't visit? The tool for visiting is the dereferencer "()" Put parentheses around hl like this (hl) to indicate to the processor that you want to visit the address that hl is holding and get the stuff stored at the address.

Now how does a plain label differ from defining saferam? Well, the key word is DYNAMIC!!!! dynamic is the idea that the program elements can change size depending on what is needed. For example, let's say your program only needs to store temporary copies of data only to be scrapped after wards. What's the point of storing it directly into the program? It's stuck there even when the program is not running. With the saferam, whatever is stored there is cleared after you exit the program, but at least you can save the necessary stuff back into it if you need to.

I am really sorry if this does not help. ASM is kinda hard for me to explain, but I try my best to help out. I'm sorry I'm not an expert like Kerm, who can probably explain it better.



Code:


Anwers (just highlight/select this blank space)
1. jp label_address
this is because label_address is the location of the first byte of the command in this executable code. the jp command (used in a previous section of code) simply tells the process to start looking at this address and treating the stuff as executable.

2. label_address+1
since xor a is 1 byte, we need to go to the byte after label_address. Well, I mentioned before that label_address is really representing some number like 255... Well, if the variable is located immediately after the byte that contains xor a, then what is the number of the next address? label_address+1.

3. label_address+2
well, same as before, but we must skip over the two bytes (one for the xor a, and one for the .db 0)

4. label_address+4
I mentioned that a word is two bytes. So you have to skip over one for xora, one for the first .db 0, and two for the .dw 0

I hope this helps a bit.

Excellent! My only comment is that labels can also store 0-65536 if you treat the contents of the label as a word instead of a byte.

Kerm, still the label itself will only be pointing to a memory address holding one byte of information. Sure you can ld hl,(label), but you're technically loading the next byte of data after the label along with the byte of data at the label. Sorry, I wouldn't be so picky if this wasn't important, but I wouldn't want him getting confused and doing something like this:

Code:
In an attempt to load $0132B213 into hl.

Excellent explanation Liazon.

Ah, good distinction. Yup, that makes good sense about not confusing him.

alright here is the code i use and the storing works:


Code:


now how exactly would i recall the information using _vputs.

just do:
Code:
making sure that you include those routines I posted earlier in the thread.

good point thanks. iirc, that would almost be legal except that I believe that you have to load each individually into the right register. Wouldn't you have to use the a register for loading stuff from an address? You can't do


Code:


right?

Someone oughta explain sprites and screen buffer stuff to him soon, otherwise he'd just be limited to text. ALthough text is a real great place to start though.

You are perfectly free to use both a and hl to load to and from memory. True, b wouldn't work, but I didn't use b did I?

oh i see what you're trying to point out.

since each individual word is 2 bytes, it's label+2 in order to get the value of $0132B213

Ya, i forgot how important hl and a are.

i am not really worried about sprites just yet. i am just going to use text and menus but i am using menus that if you push down it drops down to next choice. And ti83asm.inc does not have _vputsA. But it does have _vputsn i learned this when i tried to assemble and it could not find _vputsa.

Did you do that? Seriously, if you can't get your head around something as simple as loading a value from a register to RAM and vice versa, you should wait a little and learn Asm later.

i did do it and here is what i get:

TASM Z80 Assembler. Version 3.2 September, 2001.
Copyright (C) 2001 Squak Valley Software
tasm: pass 1 complete.
rpg.z80 line 0374: Label not found: (_vputsA)
rpg.z80 line 0374: Unused data in MS byte of argument. (2)
tasm: pass 2 complete.
tasm: Number of errors = 2

Come on! "vdispA" =/= "_vputsA"

well i tried it and it did not work. i have the command

_divhlbya

but not the command

_divhlby10

and because of that those lines of code did not work.

You can write your own divhlby10 routine. Let's see... I can use one from DCS:


Code:

so to use those routines i could just include that code anywhere and then call to it at anytime or could i make them include files and call to it.

Yup, it's best to put them after the rest of your code but before any data such as strings.

but is there any way i can save it as a .inc file and then execute it like with a command:

exe divhlby10
or
call divhlby10

Sure, just put it in a file, save it as routines.inc, then do #include routines.inc somewhere in the main asm program, and use call divhlby10. You can also, as I said, paste the routine in your asm program and still do call divhlby10.