Does the communication error happen when 0x02022B4C is not 0x2? IIRC the game brings those up every time it tries to receive/send data over an inexistent link cable (warp to a cable club room and stand on one of the script tiles). You should poke around GBATEK, maybe it has something. I'm not sure if DisFire is complete enough for one to able to see how the game handles that. I'll check it out right now.
It appears that you're looking for the pseudo instruction adr. Instead of
.org 0x08900000
ldr r2, ptr_str2
.....
.align
ptr_str2: .long str2
.....
str2: .byte 'B','E','P','A','C','E','P','A',0You're welcome :D The other advantage of adr (assuming word alignment) is that it removes the need for a pointer, so you save 4 bytes. When you do ldr r0, =str1, you're implicitly placing a pointer to str1 in your pool. Its only 4 bytes, but still. I never minded the padding for .org because I only save my asm files. I delete my bins anyways - I'd only need it again if there were some problem with my routine, which would necessitate assembling again regardless. But I suppose if you really cared about it, you could do something like
.equ where_i_plan_to_paste_this_routine, 0x08yyyyyy
main:
.....
ldr r0, =(str2 + where_i_plan_to_paste_this_routine)
.....
.align
str2: .byte 'B','E','P','A','C','E','P','A',0
I used .org because it was bl'ing the malloc. It pads the file with zeroes. Basically, go to the end of the bin and copy the bytes there to the corresponding address in your ROM (ignoring the 0x8000000 for ROM, which I just type out of habit and really doesn't need to be there and is currently only inflating the bin by a gigantic amount). Btw, that post alone doesn't change the item cap. I alluded to it, but you also need to change that other routine mentioned in the post, which I should have made clearer but was probably lazy. I think I'll edit that it the next time I'm on a computer.
I remember now - I think I didn't explain the 0x99E44 routine because I posted an explanation of it elsewhere around the same time period. Not the smartest decision on my part to not even link it in the post, but after some digging, here it is: https://www.pokecommunity.com/showpost.php?p=9014911&postcount=2018
Hi! I want to ask a question about using bitfields as u32 vars in C.
/*From Nintendo*/
struct DMACNT
{
u16 Count; // Transfer Count
u16 Dummy_21_16:5;
u16 DestpCnt:2; // Destination Address Control
u16 SrcpCnt:2; // Source Address Control
u16 ContinuousON:1; // Continuous Mode
u16 BusSize:1; // Bus Size 16/32Bit Select
u16 DataRequest:1; // Data Request Synchronize Mode
u16 Timming:2; // Timing Select
u16 IF_Enable:1; // Interrupt Request Enable
u16 Enable:1; // DMA Enable
};struct DMACNT *DMA3CNT = (struct DMACNT *)0x40000DC;ldr r0, =0x40000DC
ldr r1, =0x81000800
str r1, [r0]
union DMACNT {
u32 u_DMACNT;
struct s_DMACNT st_DMACNT;
};Okay, since I don't have *that* much knowledge about ASM, here's another question. The bag is not so messed up now except that some Key Items are in the General Items Pocket. To avoid that happening, should I repoint the RAM address where the General Items are stored (which is at 0x203988C)? @.@
Right, so basically what is happening is because you've changed the length of what is read for general items but haven't moved where key items start, your key items are being read in the general list. I'm not really sure how to explain this more precisely, so maybe you could post your the routine you tried? It would be easier to explain with concrete addresses than in the abstract.
I didn't actually edit the routine, just hex edit because I don't know how to rip the routine. :( And the only part that I actually changed is:
ROM:08099E52 MOVS R0, #0x2A @ '*' @#42 (changed to 3C for 60 items)ROM:08099E56 ADDS R3, #0xA8 @ '¿' @0x3B8; offset of key items [B][changed to A8+12=BA][/B]
ROM:08099E60 ADDS R3, #0x78 @ 'x' @0x430; offset of pokeballs [B][changed to 78+12=8A][/B]
ROM:08099E6A ADDS R3, #0x34 @ '4' @0x464; offset of TMs/HMs [B][changed to 34+12=46][/B]
ROM:08099E74 LDR R0, =0x54C @0x54C, offset of berries[B] [this one I am unsure of because in a hex editor, it's 05 48][/B]ROM:08099E50 STR R0, [R1] @store address of general items at 0x203988C
ROM:08099E5A STR R0, [R1,#8] @store address of key items at 0x2039894[B] [0x88 in a hex editor, maybe I should +0x12 this?][/B]
ROM:08099E64 STR R0, [R1,#0x10] @store address of pokeballs at 0x203989C[B] [0x8 in a hex editor][/B]
ROM:08099E6E STR R0, [R1,#0x18] @store address of TMs/HMs at 0x20398A4 [B][0x88 in a hex editor][/B]
ROM:08099E78 STR R2, [R1,#0x20] @store address of berries at 0x20398AC [B][0xA in a hex editor][/B]Okay I see something. You say stuff like "A8+12=BA"
I think that looking at the hex and attempting to change the code byte by byte is a waste and only serves to create extra work.