Homebrew Homebrew Development

  • Thread starter Thread starter aliak11
  • Start date Start date
  • Views Views 1,474,952
  • Replies Replies 6,048
  • Likes Likes 54
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.

do you know how big your bss section is ?
 
  • Like
Reactions: VinsCool
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 ?

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
 
Is this related to the infamous "Relocation to invalid address!" 3dsxtool error?

no, never heard of that idea. please contact fincs to let him know about it.

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
yeaaah that's like way too big for the current loader. i'll let you know when the update is live.

in the meantime i'd recommend sizing down some stuff (like the ROM array) and moving it to the heap (regular one is 24MB, linear one is 32MB).
 
  • Like
Reactions: filfat
I have created an input a struct :P
check the files :P
I'd prefer to stick with the input system i'm currently using. But if needed, i'll use your method! ;)
Of course it does...
It doesn't! It gives an error while building. I'll post the log here once i get home..
 
  • Like
Reactions: filfat
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


for my tests I try : fake_plasma_slow.gba

it's a small homebrew for gba (about 444 bytes)
 
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.
 
minexew Here's what happends it i put extern u32 input; in main.c file:
Code:
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;
        ^
 
Sorry i wrote "extern u32 input" in main.h file.

#include <3ds.h> is already wrote inside main.c..

I'd suggest to put #include <3ds.h> into main.h, so that the file is self-contained and doesn't rely on previously included files.
If you still can't get it to work, just use an unsigned instead of u32, on the CTR they're the same thing.
 
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.

1) call sdmcInit before using stdio
2) paths are formatted like "sdmc:/boot.3dsx"
3) i'm not sure if mkdir is implemented, but FTPony is definitely able to create a directory
4) also check out sdmc.c in ctrulib
 
  • Like
Reactions: filfat
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.

That definitely would be a problem. While I'm familiar with the GBA hardware itself, I haven't fiddled with gpSP a whole lot so I'm not sure how it does it's thing. If that's the case I'll probably just end up coding my own CPU interpreter (or a port of VBA's interpreter) for now and then build from there. And maybe in the future if I can just write to an exeutable page I can easily recompile from GBA ARM to 3DS ARM. It's still kinda up in the air for now since I'm still getting oriented with the 3DS.
 

Site & Scene News

Popular threads in this forum