0 Members and 1 Guest are viewing this topic.
Just put the label after the .dw statement. That's what labels are for, so you don't have to calculate manual offsets
About the branch table thing - I dont put that at the start of my programm, and it still jumps to the right place on page 2.
Since I dont put it at the start, there's no need for the JP to the ProgStart either.
And appearantly my assembler doesn't want the label name after the .dw, it wants the offset.
Like I said, If my label is the first thing on Page2 i just put $4000 there, but I don't want to manually count every line to calculate what offset the other labels are at, that's insane!
Of course I could load a number in AppBackupScreen and then make a jump table at the first label of Page 2, which isnt much work or takes much room, but it's still cheating and a way of hiding my incompetence as a programmer, ghehe...
And I'm not having ANY problems at the moment, everything is working fine.Well, I still can't jump to anyhing but the first label on page 2, but you now know why that is
And don't worry, you aren't sounding rude.
I should've made muself much much more clear, you're no psychic.I'm already overwhelmed by the many people willing to help me, and they're helping me ALOT, so thank you!
The branch table is the pairs of .dw's and .db's. Unless you're not using the code you posted, you have a branch table.
b_call _RunIndicOff b_call _GrBufClr
JumpToPage2 = $ - $4000 .dw $4000 .db 1
That's slower, not to mention unnecessary.
As calc84 said, labels pretty much are offsets. The assembler doesn't like it because it's in a different file.
Don't you need ($-$4000)/3 rather than $-$4000, though?
Anyway, if you edit AsmDev's batch files somewhat (and change your source a bit), you won't have to go away from AsmDev and TASM.In short, you'll need to change the compilation order to compile the first page last, add export directives to all pages except the first, and add an #include to the file for the first page so it includes the labels exported from the other pages.
Don't you need ($-$4000)/3 rather than $-$4000, though?($-$4000)/3 doesnt work.$-$4000 does.I don't know why, I just like it when things do.
QuoteDon't you need ($-$4000)/3 rather than $-$4000, though?($-$4000)/3 doesnt work.$-$4000 does.I don't know why, I just like it when things do. In some assemblers, / doesn't work for division, and for good reason. Instead, it's like the TI-Basic colon, allowing one to place more than one ASM instruction on the same line.
Quote from: Hot_Dog on August 24, 2010, 10:22:57 amQuoteDon't you need ($-$4000)/3 rather than $-$4000, though?($-$4000)/3 doesnt work.$-$4000 does.I don't know why, I just like it when things do. In some assemblers, / doesn't work for division, and for good reason. Instead, it's like the TI-Basic colon, allowing one to place more than one ASM instruction on the same line.You are thinking of backslash ("\"). "/" is division in every assembler I know of.
Oh, and I forgot to mention this earlier. If your branch table isn't right after the app header, you do need to make sure it is at an address divisible by three after subtracting $4000.
Quote from: calcdude84se on August 24, 2010, 10:33:47 amOh, and I forgot to mention this earlier. If your branch table isn't right after the app header, you do need to make sure it is at an address divisible by three after subtracting $4000.... Never paid attention to that, but even after editting it still works.Maybe I'm lucky and it the adress is divisible by 3 each time, though I don't know.
Quote from: Jerros on August 25, 2010, 02:32:33 amQuote from: calcdude84se on August 24, 2010, 10:33:47 amOh, and I forgot to mention this earlier. If your branch table isn't right after the app header, you do need to make sure it is at an address divisible by three after subtracting $4000.... Never paid attention to that, but even after editting it still works.Maybe I'm lucky and it the adress is divisible by 3 each time, though I don't know.I'm about 99% sure that any address within the app should work, and the "multiple of 3" thing is just a result of silly TI documentation. Because the *only* way that the remainder when divided by 3 would matter is if TI actually divided it by 3 in the bcall routine, which I am very sure they don't.
Don't bother us with questions if you have problems simply because you decided to try a different route."
In that case, they said exactly what I would say..."We've done it for years this way, and it works perfectly and easily, so you should do it the way that WE do it. Don't bother us with questions if you have problems simply because you decided to try a different route."