gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

ASM > 16 bit or 8 bit negative numbers + Burning a ROM

#7956 - funkeejeffou - Sun Jun 29, 2003 1:00 pm

Let's say that I store in RAM 16 bit negative numbers like :
Code:
variable
@DCW 0xFFFF    ;this equals -1

if I load it's value to a register like this :
Code:
mov r0, variable
ldrh r1, [r0]
then r1 = 0x0000FFFF = 65535 and not -1 !!!

That's annoying me a little bit and I'd like to figure out a fast way to load 8 or 16 bits variable into a register.
I thought about doing this for 16 bit variables(would be the same for 8bits with 24 shifts):
Code:
mov r1, r1 lsl#16
mov r1, r1 asr#16
so that the upper bits will be fixed, but it's kinda slow...
Anybody has a suggestion ?

I also have another problem, my code works fine on VisualBoy but some graphic bugs occurs on harware (my bitmaps wich are stored in ROM are buggy when reaching the last pixels).
Since I'm using Goldroad, must I patch the rom?
I'm also suspecting the F2A config; the fixdata an 32K options are unfamiliar to me...
How do you burn in the right way a ROM?

Help will be much and much appreciated.

#7963 - DekuTree64 - Sun Jun 29, 2003 4:02 pm

Use ldrsh/ldrsb. They repeat the upper bit of the number through the rest of the register's bits. You don't get as many addressing modes, but you can usually calculate those with one add anyway, so it's still faster than 2 shifts.

#8034 - GbaGuy - Tue Jul 01, 2003 1:57 am

Wouldn't loading 0x8000FFFF be -1, or would that
be -0xFFFF ?

#8037 - tepples - Tue Jul 01, 2003 2:15 am

0x8000ffff is 0x80000000 + 0x0000ffff, or -2^31 + 65535, or -2147418113.

If you want -65535, then you want 0x100000000LL - 0xffff = 0xffff0001.

If you want -1, then you want 0xffffffff.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#8069 - funkeejeffou - Tue Jul 01, 2003 4:01 pm

Thanks Deku, it works again (even on goldroad, hehe).
As for burning the rom, I've found out that I had to leave clean the first 0xBFh bits of the rom, so that the header won't overwrite some data(wich was my texture, that's why the first bits were wrong). Goldraod doesn't do it itself, so if you also have this problem, just do:
Code:
bstart                         ;first adress of the ROM is always the jump call to
                                 ;to your first line of code IN ARM!!!
@org 0x80000C0h       ;jump 0xBF bits
;beginning of code

Hope this wil help out some other Goldroad users