- Joined
- Apr 21, 2010
- Messages
- 1,034
- Reaction score
- 110
- Trophies
- 1
- Website
- sites.google.com
- XP
- 442
- Country



Is there a max file size for .3dsx files? I'm making an attempt to port gpSP to the 3DS, and while I have everything in line for it to at least be executed (main loop is completely isolated from the rest of the program at the moment), the ending file size is 1.1MB and it seems to crash if I run it. However, if I don't link all the other files it will run just fine. I'm not entirely sure what's causing the file size to go up so much but it's preventing me from getting at least *something* running.
atm the 3dsx loader fails if the bss section is too big. this has been fixed and ninjhax should be updated fairly soon.

You can look into input.h and input.c inside DownloadMii and then just pass Input_s Input* to every function that uses it(or use extern)Guys i need your help. How can i take input in main.c and use the taken input in other .c files?
atm the 3dsx loader fails if the bss section is too big. this has been fixed and ninjhax should be updated fairly soon.
do you know how big your bss section is ?
0029ffa4 00008000 B bios_block_ptrs
00e2d124 00008000 B bios_rom
00d894dc 00008000 B io_registers
00eeea70 00008000 B memory_map_read
00ee6a70 00008000 B memory_map_write
00ca7fa4 00010000 B block_data
00d794dc 00010000 B iwram
00e0d124 00020000 B gamepak_backup
00e35168 00030000 B vram
00d387c4 00040000 B bios_translation_cache
00cf87c4 00040000 B ram_block_ptrs
00cb7fa4 00040000 B rom_branch_hash
00d914e0 0007bc43 B savestate_write_buffer
00e6516c 00080000 B ewram
001dffa4 000c0000 B ram_translation_cache
002a7fa4 00a00000 B rom_translation_cache

Is this related to the infamous "Relocation to invalid address!" 3dsxtool error?
yeaaah that's like way too big for the current loader. i'll let you know when the update is live.I believe it should be big enough to house a whole GBA ROM (about 32MB), plus RAM, so fairly large. I'm only attempting to port gpSP at the moment so I'm still getting around their files, but I do know that it initializes straight arrays for each RAM and ROM segment. And it seems that one of their files compiled out to almost the whole 1.1MB, so after stubbing that file out it's a lot more sensible in size (but still crashing). I might end up sizing it down a bit during testing to prevent crashes while I work on getting it working, but the end goal is to at least be able to emulate full 32MB ROMS like Mother 3. If this gets anywhere. I do have it in a "It compiles!" state so that's good, because I should be able to emulate a CPU from here at least.
EDIT: Here's a printout of some of the BSS blocks from nm:
Code:0029ffa4 00008000 B bios_block_ptrs 00e2d124 00008000 B bios_rom 00d894dc 00008000 B io_registers 00eeea70 00008000 B memory_map_read 00ee6a70 00008000 B memory_map_write 00ca7fa4 00010000 B block_data 00d794dc 00010000 B iwram 00e0d124 00020000 B gamepak_backup 00e35168 00030000 B vram 00d387c4 00040000 B bios_translation_cache 00cf87c4 00040000 B ram_block_ptrs 00cb7fa4 00040000 B rom_branch_hash 00d914e0 0007bc43 B savestate_write_buffer 00e6516c 00080000 B ewram 001dffa4 000c0000 B ram_translation_cache 002a7fa4 00a00000 B rom_translation_cache

"Extern" doesn't accept u16 or u32 variables...You can look into input.h and input.c inside DownloadMii and then just pass Input_s Input* to every function that uses it(or use extern)![]()

I have created an input a struct"Extern" doesn't accept u16 or u32 variables...
"Extern" doesn't accept u16 or u32 variables...

I'd prefer to stick with the input system i'm currently using. But if needed, i'll use your method!I have created an input a struct
check the files![]()
It doesn't! It gives an error while building. I'll post the log here once i get home..Of course it does...
I believe it should be big enough to house a whole GBA ROM (about 32MB), plus RAM, so fairly large. I'm only attempting to port gpSP at the moment so I'm still getting around their files, but I do know that it initializes straight arrays for each RAM and ROM segment. And it seems that one of their files compiled out to almost the whole 1.1MB, so after stubbing that file out it's a lot more sensible in size (but still crashing). I might end up sizing it down a bit during testing to prevent crashes while I work on getting it working, but the end goal is to at least be able to emulate full 32MB ROMS like Mother 3. If this gets anywhere. I do have it in a "It compiles!" state so that's good, because I should be able to emulate a CPU from here at least.
EDIT: Here's a printout of some of the BSS blocks from nm:
Code:0029ffa4 00008000 B bios_block_ptrs 00e2d124 00008000 B bios_rom 00d894dc 00008000 B io_registers 00eeea70 00008000 B memory_map_read 00ee6a70 00008000 B memory_map_write 00ca7fa4 00010000 B block_data 00d794dc 00010000 B iwram 00e0d124 00020000 B gamepak_backup 00e35168 00030000 B vram 00d387c4 00040000 B bios_translation_cache 00cf87c4 00040000 B ram_block_ptrs 00cb7fa4 00040000 B rom_branch_hash 00d914e0 0007bc43 B savestate_write_buffer 00e6516c 00080000 B ewram 001dffa4 000c0000 B ram_translation_cache 002a7fa4 00a00000 B rom_translation_cache


3DS_Paint
draw.c
arm-none-eabi-gcc -MMD -MP -MF /c/devkitPro/Projects/3DS/3DS_Paint/build/draw.d
-g -Wall -O2 -mword-relocations -fomit-frame-pointer -ffast-math -march=armv6k -
mtune=mpcore -I/c/devkitPro/Projects/3DS/3DS_Paint/include -I/c/devkitPro/libctr
u/include -I/c/devkitPro/Projects/3DS/3DS_Paint/build -DARM11 -D_3DS -c /c/devki
tPro/Projects/3DS/3DS_Paint/source/draw.c -o draw.o
main.c
arm-none-eabi-gcc -MMD -MP -MF /c/devkitPro/Projects/3DS/3DS_Paint/build/main.d
-g -Wall -O2 -mword-relocations -fomit-frame-pointer -ffast-math -march=armv6k -
mtune=mpcore -I/c/devkitPro/Projects/3DS/3DS_Paint/include -I/c/devkitPro/libctr
u/include -I/c/devkitPro/Projects/3DS/3DS_Paint/build -DARM11 -D_3DS -c /c/devki
tPro/Projects/3DS/3DS_Paint/source/main.c -o main.o
menu.c
arm-none-eabi-gcc -MMD -MP -MF /c/devkitPro/Projects/3DS/3DS_Paint/build/menu.d
-g -Wall -O2 -mword-relocations -fomit-frame-pointer -ffast-math -march=armv6k -
mtune=mpcore -I/c/devkitPro/Projects/3DS/3DS_Paint/include -I/c/devkitPro/libctr
u/include -I/c/devkitPro/Projects/3DS/3DS_Paint/build -DARM11 -D_3DS -c /c/devki
tPro/Projects/3DS/3DS_Paint/source/menu.c -o menu.o
In file included from c:/devkitPro/Projects/3DS/3DS_Paint/source/menu.c:1:0:
c:/devkitPro/Projects/3DS/3DS_Paint/source/menu.h:27:8: error: unknown type name
'u32'
extern u32 input;
^
minexew Here's what happends it i put extern u32 input; in main.c file:

Sorry i wrote "extern u32 input" in main.h file.
#include <3ds.h> is already wrote inside main.c..

Anyone had success with the mkdir function, or is it not implemented. If so how do I create an folder.
Question 2: does fopen, fclose, fread, fprintf etc work? :
Thanks.
How are you going to run gpSP, considering it uses a dynarec? AFAIK there is no way for regular userland apps to write to executable pages, make pages executable, or anything that would let them run runtime-generated code.