It is currently Tue Dec 18, 2018 6:51 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Sat Nov 10, 2018 8:24 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 734
tepples wrote:
"Flash Advance Linker" was the name for the first GBA cartridge writer from Visoly. I guess the name "Linker" for the writer ended up sticking.

Ah! That does explain it. Reminds me that there's also a "DSLink" flashcart with support for "GBA game linking" (whatever that means).
With Bung Game Doctor in mind, I wonder if it had transformed to saying "you use sound if your doctor is too old".

PypeBros wrote:
EXMEMCNT for EXternal MEMory CoNTrol, presumably.

I guess we all thought so. But now, Nintendo's real intention might have been to use waitstates for overcoming problems with solid or semisolid excrements smeared on the cartridge slot contacts.

Yeah, unaligned sector-buffers may or may not make sense.
The driver where I had spotted it did handle two separate cases, alike "IF (addr & 3) THEN slow_transfer ELSE fast_transfer".
The important points are that driver-makers should support that, and that driver-users shouldn't trust on it being supported (unless somebody can confirm that it is working with most or all drivers).

PypeBros wrote:
The flashcard firmware won't load/scan the whole 128MiB. The NDS memory is only 4MiB and there would be no point in loading more than that in memory.

Maybe not. Or maybe yes. I think some flashcarts are first copying the whole program from SD card to faster internal FLASH, and then load the ARM9/ARM7 bootcode to RAM.
But well, if the patching is done during the SD-to-FLASH transfer... that won't make much of a difference because that transfer is slow anyways.

PypeBros wrote:
I see that the FIX_ALL thing is puzzling you a lot.

Yeah, looks so.
I am pretty fascinated about the bugs in there.
And also about nobody ever having noticed that bugs (which, I guess/hope that's because nobody has ever used the FIX_ALL feature).
And wondering about creating a 100% stable .dldi driver with FIX_ALL is fascinating problem (yet impossible, I think).
Or one could wonder about making a .nds file that supports it's own guessing mechanisms for undoing mis-guessed adjustments made by the installer ; )

But, more serious idea: Making a .nds file that detects FIX_ALL would be nice (and then throwing a warning/error message, saying to post about that dldi driver in this forum).

PypeBros wrote:
I think FIX_ALL might have been added to that to support hypothetical drivers written e.g. in low-level assembly.

Probably so, and based on the assumption that ASM coders won't know how to use PC relative addressing (which isn't neccessarily true, the first thing I had learned about ARM was that B and BL are relative jumps, and that ADR and ADRL are for loading relative addresses).

PypeBros wrote:
"global offset table" (which is a trick C/C++ compiler does to support relocatable code). The technique of relocating code that way is fairly common, and seen in Linux kernel modules and shared libraries.

Do you know more about that GOT (and GLUE) tables?
Are they just pointers, used as-is by the code in the .dldi binary (eg. same way as ASM code with pointers in literal pool)?
Or do they need further pre-processing before starting the .dldi code (eg. like relocation info in a DOS .EXE file)?
In that case, as there's no operating system, that pre-processing would have to be done by libfat/libnds?

PypeBros wrote:
I've never encountered an invalid opcode that could be the responsibility of the DLDI process rather than to some silly loop of mine.

Good to know that it had worked. Then, I guess your driver doesn't use FIX_ALL, right?

PypeBros wrote:
I'm pretty surprised that there is no code advancing to the next word once a word has been patched. After all, having code that just could patch the same 32-bit word twice is a non-sense.

Yup, that would fix most of the problems - and it would even allow to maintain the patch-unaligned-word feature (although I can't image why anybody would need to have that feature in the first place).
It would also require to change FIX_ALL not to patch the 80h-byte .dldi header (especially the Function pointers are in danger because they were already adjusted (before FIX_ALL) and FIX_ALL might then apply further patching to them).

PypeBros wrote:
Of course, if such mis-patching ever occured, it would be caught at the design house

But, with FIX_ALL, only if the header-patching and double-patching were fixed.
As it is now, any double-patched ".dldi" bytes do have the ".nds" +relocationOffset added at time of first patch.
And then, neither the creator of the ".dldi" file, nor creator of ".nds" file could predict what would happen :)


Top
 Profile  
 
PostPosted: Sun Nov 11, 2018 1:51 am 
Offline
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 32
Quote:
PypeBros wrote:
"global offset table" (which is a trick C/C++ compiler does to support relocatable code). The technique of relocating code that way is fairly common, and seen in Linux kernel modules and shared libraries.

Do you know more about that GOT (and GLUE) tables?
Are they just pointers, used as-is by the code in the .dldi binary (eg. same way as ASM code with pointers in literal pool)?

I invite you to have a look at ELF file format, which has the GOT thing described at section 2-17. To be honest, it's been a while since I last read it and I never actually coded around that myself. Just designed my own alternative.

I don't know about the 'glue' thing. It seems specific to ARM7, from the .ld file.

PypeBros wrote:
I've never encountered an invalid opcode that could be the responsibility of the DLDI process rather than to some silly loop of mine.

Good to know that it had worked. Then, I guess your driver doesn't use FIX_ALL, right?
[/quote]
most likely, but since it is embedded into the linker firmware, I must admit i've never seen it in a separated file :-/ (the linker happened to be a clone of a famous one, and not what was pretended by the box).

Oh, and
Quote:
But I guess the HLL people didn't know how to store data at a fixed location : /
Some of the files contain something called "dldi.ld" is it safe to ignore that, or is it important?

The
Code:
ddmem ORIGIN = 0xBF800000

line in that .ld file is what tells the linker to make the code start at the "magic" address bf800000 in first place. It will also allow the programmer to reduce the number of "sections" and sometimes make custom binary formats out of .ELF files. (again, long time not used). This is something you may dig into when creating bootloaders and things like that, and that are blissfully ignored by most applicative programming.

_________________
Image - may the source be with you.


Top
 Profile  
 
PostPosted: Mon Nov 12, 2018 7:42 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 734
I have downloaded all dldi files from the chishm page, and wrote a tool for scanning some interesting entries.
Code:
Fix Feature ddmem    Size  Filesize CRC32    Filename
----------------------------------------------------------
00 00000000 BF800000 0F 0F 00008000 A12DEDB9 default.dldi
0E 00000013 BF800000 0D 00 0000106C 1B0146E0 acek.dldi
0C 00000013 BF800000 0C 00 00000BB8 A2A189EC cyds.dldi
0E 00000023 BF800000 0D 00 000005C4 435CCCFD gmtf.dldi
0E 00000023 BF800000 0D 00 00000794 2AEF560D gmtf2.dldi
0E 00000023 BF800000 0D 00 000011DC BF1CADC2 dlms.dldi
0E 00000013 BF800000 0D 00 0000125C 61852856 dlms_moon.dldi
0E 00000023 BF800000 0D 00 000013FC 814BFBA4 dlms3.dldi
0E 00000023 BF800000 0D 00 000013A0 AD52070D dlms4.dldi
0E 00000023 BF800000 0D 00 00000574 C4760A67 dsx.dldi
0E 00000013 BF800000 0D 00 00001004 7C3E3952 ewsd.dldi
0E 00000013 BF800000 0D 00 00000B90 115B4FE3 ezsd.dldi
0E 00000023 BF800000 0E 00 00001A44 0D2F707B ez5s.dldi
0E 00000023 BF800000 0E 00 00000E84 CA19D819 ez5sdhc.dldi
0E 00000013 BF800000 0F 00 000023BA 5E7F4D4B g6fl.dldi
0E 00000023 BF800000 0F 00 00002448 1C0DB9AB g6real.dldi
0E 00000013 BF800000 0D 00 0000079C 7F2F05DB m3cf.dldi
0C 00000013 BF800000 0C 00 00000DEC F784899F m3sd.dldi
0C 00000013 BF800000 0C 00 00000B70 E113B19F m3sd_alt.dldi
0C 00000013 BF800000 0B 00 00000754 F60C95F8 mmcf.dldi
0C 00000013 BF800000 0B 00 00000754 B8A8B6F6 mpcf.dldi
0E 00000011 BF800000 0F 00 00000594 8AB819BA mpsd.dldi
0E 00000023 BF800000 0C 00 00000FBC B6BD2DA8 nmmc.dldi
0E 00000021 BF800000 0D 00 000004AC 1C0A7124 mk5n.dldi
0E 00000013 BF800000 0D 00 00000ED0 BB6635E2 nsd2.dldi
0E 00000013 BF800000 0D 00 00001028 5A582569 nsd2v2.dldi
0E 00000023 BF800000 0D 00 00001708 BA8E0A84 njsd.dldi
0E 00000023 BF800000 0F 00 00000868 1F0B6682 x9sd6.dldi
0E 00000023 BF800000 0D 00 000008E4 4500CED0 r4tf.dldi
0E 00000023 BF800000 0D 00 000004E4 487F9E66 r4tf_v2.dldi
0C 00000013 BF800000 0B 00 00000784 C37E0574 sccf.dldi
0E 00000023 BF800000 0D 00 000005FC 284E6CCF scds.dldi
0E 00000023 BF800000 0D 00 000005AC A55FC880 scds1.dldi
0E 00000023 BF800000 0D 00 000005F8 FC50EBF0 scds2.dldi
0E 00000023 BF800000 0D 00 000007AC EA8E72BF scdssdhc.dldi
0E 00000023 BF800000 0D 00 00000548 2B4B9CFC scdssdhc1.dldi
0C 00000013 BF800000 0C 00 00000BB8 D41872EA scsd.dldi
0E 00000013 BF800000 0D 00 000007C0 A10A15A7 scsd_moon.dldi
0E 00000013 BF800000 0D 00 000006A8 F27EC518 sclt.dldi
0E 00000013 BF800000 0F 00 00000950 E4140E7C SCRB.dldi

None of that files is using FIX_ALL.
And ddmem is always at BF800000h.
I think that should make them work stable.
And other/older/later drivers are, hopefully, working similar.

When disassembling the code posted earlier above, I had set a memory access breakpoint on the DLDI area.
It did trigger on reading the FEATURE flags (with GBA/NDS flags), and on the Function table reads (with startup/isInserted).
There was nothing reading the FIX flags or the start/end addresses, so the GOT/GLUE stuff is apparently used only internally by the dldi itself, much like a literal-pools or address-arrays in asm.

Some of the above files don't have the FIX_GLUE stuff.
The other files have the FIX_GLUE flag (but not checked yet if there's anything in the glue start/end area).
Hmmm... if GLUE is specifically for ARM7... no idea if/how/when/why for that's supposed to do.


Top
 Profile  
 
PostPosted: Mon Nov 12, 2018 8:21 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 734
I have expanded the tool to throw warnings on bad dldi headers & table entries etc.
Most of it looks okay.

The GOT table contains ptrs to the ddmem start/end area (up to including end). Or, for some reason, 00000000h pointers in some cases. Anyways, there are no other dangerous values mixed with the GOT pointers, and the pointers in the existing files are all at word-aligned locations. So I guess GOT is safe to use in that form.

However, the GLUE area is a bit risky: It seems to contain a small code section, containing ARM opcodes mixed with .pool ptrs (and followed by whatever in next three bytes) (eg. in nmmc.dldi). It seems to be only a SMALL code section, and it doesn't include the 80h-byte dldi header area - so it isn't as dangerous as FIX_ALL, but it could go wrong, especially if some driver maker isn't aware of not using opcodes/constants like xxBF80xxh, xxxxBF80h in (or directly after) the GLUE area.
Some of the files with FIX_GLUE don't actually have a GLUE area (or they have it, but it's 0 bytes in size, eg. in mpsd.dldi). Alltogether I've found 9 files that do have GLUE and that do contain opcodes or other non-ddmem pointers in that area.


Top
 Profile  
 
PostPosted: Wed Nov 14, 2018 5:23 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 734
I've finally had a look at those .ld files, too. For ddmem, there's a line saying "ddmem : ORIGIN = 0xBF800000, LENGTH = 16K", with comment:
Code:
  This base address is chosen to be a reserved instruction in THUMB mode,
  and SWILT in ARM mode, with an impossible SWI value. This should allow
  the patcher / linker to find all shifted addresses within each section.
  Changed sections are: glue_7, got

So the DLDI mastermind was apparently aware of possible conflicts with opcodes, and tried to avoid them using the BF80h value. It just doesn't work as reliable as planned because of the unaligned-word-patching.

Then there's some stuff about GLUE:
Code:
  *(.glue_7)
  *(.glue_7t)

I think that's related to "glueing" ARM code sections to THUMB code sections (with the "t" for THUMB). The nmmc.dldi file has this in GLUE area (for THUMB/ARM mode switching):
Code:
  BF800098 E59FC000  ldr     r12,=0BF800BE1h    ;\
  BF80009C E12FFF1C  bx      r12                ;
  BF8000A0 BF800BE1 .pool       ;<-- patch here ;
                    .thumb                      ; GLUE area
  BF8000A4 4778      bx      r15                ;
  BF8000A6 46C0      nop                        ;
                    .arm                        ;
  BF8000A8 EA000387  b       8000ECCh           ;/
  BF8000AC E92D4010  push    r4,r14             ;-after GLUE (no conflict here)

Not too sure what the "7" in "glue_7" and "glue_7t" is meant for. It doesn't seem to be ARM7 related. Or maybe it's meant as "area with ARM7-compatible opcodes", no matter if that area is used on ARM7 or ARM9.

For the GOT table, one corner case are the NULL pointers (I think they are intended as leading alignment padding). Subtracting 0-BF800000h gives 40800000h, then adding the NDS RAM address 0xxxxxxxh gives 4xxxxxxxh. That's stable even if next byte is BFh (because BF4xh won't match the BF80h patch area). EDIT: The NULL pointers aren't patched because they aren't in the BF80xxxxh range.

However, the other corner case is the GOT table usually being located at the END of the .dldi file, and that won't work: The .dldi file content is just copied to the 32Kbyte DLDI area in the .nds file, and if the .dldi file was smaller than 32Kbytes, then it's just leaving the old .nds file data in the remaining area - and does then try to patch the GOT table, up to including the next 3 bytes after the END of GOT table.
If that goes wrong depends on the RAM address used by the .nds file, the content of the new .dldi file, and the content of the previously used .dldi file(s). Maybe that's rare to get wrong, but if it goes wrong then it's probably hard to figure out what had happened : )


Top
 Profile  
 
PostPosted: Sun Nov 18, 2018 3:04 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 734
I've asked Robz8 what the BOOT_FC.nds file was for, and got some interesting info:
Robz8 wrote:
The 16KBytes is allocated by the latest libnds.
Also, since TWiLight Menu++ has DSi-extended binaries, I made a different "boot.nds" file to boot it, that being "boot_fc.nds", which does not have DSi-extended header and binaries, and arm9 code starting at 0x200, in order for flashcard firmwares to boot it as homebrew correctly.

As for why I have a DLDI driver in a DSi program, it's for TWiLight Menu++ to work on flashcards as well, and to use a flashcard as secondary storage on both DSi and 3DS consoles.
TWiLight Menu++ has DLDI drivers built-in, so a different one is loaded depending on the flashcard's cardhdr.
I don't think there's an option in libnds to disable/remove DLDI drivers.

I was thinking that 16K were from older libraries, but now it turns out to be a new restriction added in newer libraries (libnds versions since January 2017). Don't know why somebody thought it'd be a good idea to do that, maybe for cases when storing DLDI in ARM7 WRAM? Nice idea - except it won't work with DLDI drivers that require 32K allocated (there's at least one, see below).

Also interesting: Going by robz8's comment, some flashcart firmwares refuse to boot homebrew if it doesn't have a homebrew header. Not sure what that means exactly, theoretically there should be no difference between homebrew & retail headers. I guess the flashcart firmwares might use the header to determine if they should apply DLDI patching, and if they should unlock access to direct SD card sector access?
If somebody knows more about that, please say something!
Ie. which firmwares are doing that, what header entries do they look at, what happens if they don't like the header?

Concerning newer flashcarts, I have downloaded three "acekard2" firmwares here http://old.r4wood.com/pages/Acekard-2i-Kernel.html
ak2_V4.23 - contains only 1 official dldi driver (using ARM code) (ak2_sd.dldi)
AKAIO.1.8.1 - contains 3 homebrew dldi drivers (using THUMB code) (ak2_sd.dldi, rpg_sd.dldi, rpg_nand.dldi)
AKAIO.1.9.0 - contains 3 homebrew dldi drivers (using THUMB code) (ak2_sd.dldi, and the same rpg_xxx drivers as in 1.8.1)
The interesting parts are Function Table entries pointing directly to THUMB code in the homebrew(?) drivers.
And, the "rpg_nand.dldi" is disguising itself as needing only 8Kbyte allocated (in hdr[0Dh]=0Dh), but the space used by the BSS area alone is bigger than 19Kbytes (plus yet MORE space needed for code/data), so this driver won't work with the new 16K libnds versions.

PS. Dunno why the official ak2_V4.23 package contains only 1 dldi driver (maybe it supports the "rpg" hardware variants, too? Or maybe the official drivers for "rpg" hardware got lost somehow?)


Top
 Profile  
 
PostPosted: Tue Nov 20, 2018 11:44 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 734
Here's the dldiscanning tool for win32 (dldiscan.exe, with source code in dldiscan.asm, plus a collection of .dldi files):
Attachment:
dldiscan.zip [95.09 KiB]
Downloaded 47 times

It's scanning all *.dldi files in current folder, and displays some info, plus WARN:Warnings on uncommon/unreliable things.
And, additionally, it's scanning all *.nds files in current folder, and displays similar info (if the file contains a DLDI header).

You can help: Copy all you .dldi files and all your homebrew .nds files to one folder, then run dldiscan.exe in that folder.
Best redirect the output to a log file (eg. via "dldiscan >temp.txt").
I would be particulary interested in any .dldi files throwing "WARN:CRC=UNKNOWN" (ie. files that aren't in the collection yet).
And about any .nds files that display any warnings (eg. for uncommon alignment or the like).
Also, any .nds files that don't display "#### ARM9" would be interesting (except the .sc.nds ones, that are showing garbage because they are having a bogus stub at the begin of the file; I guess I could just remove the stub to fix that issue).

With the files currently tested, the output looks as so:
Code:
DLDISCAN - DLDI Scanning tool 2018 nocash
Fix Feature ddmem    all  glue got  bss  sizes filesize crc32    name
00 00000000 BF800000 7FF8 0000 0000 0000 0F 0F 00008000 A12DEDB9 DLDI  default.dldi
0E 00000013 BF800000 106C 0020 000C 001C 0D 00 0000106C 1B0146E0 ACEK  acek.dldi
0C 00000013 BF800000 0BB8 0000 0014 0020 0C 00 00000BB8 A2A189EC CYDS  cyds.dldi
0E 00000023 BF800000 05C4 0000 0000 0000 0D 00 000005C4 435CCCFD GMTF  gmtf.dldi
0E 00000023 BF800000 0794 0000 0000 0000 0D 00 00000794 2AEF560D GMTF  gmtf2.dldi
0E 00000023 BF800000 11DC 000C 0000 001C 0D 00 000011DC BF1CADC2 DLMS  dlms.dldi
0E 00000013 BF800000 125C 000C 0000 001C 0D 00 0000125C 61852856 DLMS  dlms_moon.dldi
0E 00000023 BF800000 13FC 000C 000C 021C 0D 00 000013FC 814BFBA4 DLMS  dlms3.dldi
0E 00000023 BF800000 13A0 0000 000C 021C 0D 00 000013A0 AD52070D DLMS  dlms4.dldi
0E 00000023 BF800000 0574 0000 000C 0200 0D 00 00000574 C4760A67 DSX   dsx.dldi
0E 00000013 BF800000 1004 000C 001C 0224 0D 00 00001004 7C3E3952 EWSD  ewsd.dldi
0E 00000013 BF800000 0B90 0000 0010 0020 0D 00 00000B90 115B4FE3 EZSD  ezsd.dldi
0E 00000023 BF800000 1A44 0000 0024 0230 0E 00 00001A44 0D2F707B EZ5S  ez5s.dldi
0E 00000023 BF800000 0E84 0000 0014 0280 0E 00 00000E84 CA19D819 EZ5H  ez5sdhc.dldi
0E 00000013 BF800000 23B8 0000 0024 4044 0F 00 000023BA 5E7F4D4B g6fl  g6fl.dldi
0E 00000023 BF800000 2448 0000 0034 4070 0F 00 00002448 1C0DB9AB g6fl  g6real.dldi
0E 00000013 BF800000 079C 0000 0010 0024 0D 00 0000079C 7F2F05DB M3CF WARN:OVERKILLEND  m3cf.dldi
0C 00000013 BF800000 0DEC 0000 0014 0020 0C 00 00000DEC F784899F M3SD  m3sd.dldi
0C 00000013 BF800000 0B70 0000 0000 001C 0C 00 00000B70 E113B19F M3SD  m3sd_alt.dldi
0C 00000013 BF800000 0754 0000 0000 001C 0B 00 00000754 F60C95F8 MMCF  mmcf.dldi
0C 00000013 BF800000 0754 0000 0000 001C 0B 00 00000754 B8A8B6F6 MPCF  mpcf.dldi
0E 00000011 BF800000 0594 0000 0010 0008 0F 00 00000594 8AB819BA MPSD WARN:OVERKILLEND  mpsd.dldi
0E 00000023 BF800000 0FBC 0014 0014 001C 0C 00 00000FBC B6BD2DA8 NMMC  nmmc.dldi
0E 00000021 BF800000 04AC 000C 0000 001C 0D 00 000004AC 1C0A7124 MK5N  mk5n.dldi
0E 00000013 BF800000 0ED0 0000 000C 0020 0D 00 00000ED0 BB6635E2 nsd2  nsd2.dldi
0E 00000013 BF800000 1028 0000 000C 0004 0D 00 00001028 5A582569 nsd2 WARN:OVERKILLEND  nsd2v2.dldi
0E 00000023 BF800000 1708 0014 0014 0024 0D 00 00001708 BA8E0A84 NJSD  njsd.dldi
0E 00000023 BF800000 0868 0000 000C 1A28 0F 00 00000868 1F0B6682 X9SD WARN:OVERKILLEND  x9sd6.dldi
0E 00000023 BF800000 08E4 0020 0000 001C 0D 00 000008E4 4500CED0 R4TF  r4tf.dldi
0E 00000023 BF800000 04E4 0000 0000 0000 0D 00 000004E4 487F9E66 R4TF  r4tf_v2.dldi
0C 00000013 BF800000 0784 0000 0000 001C 0B 00 00000784 C37E0574 SCCF  sccf.dldi
0E 00000023 BF800000 05FC 0000 0000 001C 0D 00 000005FC 284E6CCF SCDS  scds.dldi
0E 00000023 BF800000 05AC 0000 0000 001C 0D 00 000005AC A55FC880 SCDS  scds1.dldi
0E 00000023 BF800000 05F8 0000 0000 001C 0D 00 000005F8 FC50EBF0 SCDS  scds2.dldi
0E 00000023 BF800000 07AC 0000 0000 001C 0D 00 000007AC EA8E72BF SCDS  scdssdhc.dldi
0E 00000023 BF800000 0548 0000 0000 001C 0D 00 00000548 2B4B9CFC SCDS  scdssdhc1.dldi
0C 00000013 BF800000 0BB8 0000 0014 0020 0C 00 00000BB8 D41872EA SCSD  scsd.dldi
0E 00000013 BF800000 07C0 0000 0000 001C 0D 00 000007C0 A10A15A7 SCSD  scsd_moon.dldi
0E 00000013 BF800000 06A8 0000 0000 001C 0D 00 000006A8 F27EC518 SCLT  sclt.dldi
0E 00000013 BF800000 0950 0000 0000 0000 0F 00 00000950 E4140E7C SCRB  SCRB.dldi
01 00000000 68430000 7FF8 0000 0000 0000 0E 0E 00004000 8D3B9260 KILL WARN:UsesBuggedFixAllWARN:OVERKILLEND  killer.dldi
0E 00000023 BF800000 0ED4 0000 000C 002C 0D 00 00000ED4 C1D6DD19 RPGS  ak2_sd_official.dldi
0E 00000023 BF800000 08F4 0000 000C 0008 0C 00 000008F4 69F95B8C RPGS WARN:THUMB WARN:OVERKILLEND  ak2_sd_akaio190.dldi
0E 00000023 BF800000 0958 0000 000C 0020 0C 00 00000958 4B959C56 RPGS WARN:THUMB  rpg_sd_akaio181-190.dldi
0E 00000023 BF800000 1950 0000 000C 4CA8 0D 00 00001950 6E410A07 RPGN WARN:THUMB WARN:BSS_EXCESS  rpg_nand_akaio181-190.dldi
0E 00000023 BF800000 082C 0000 000C 0004 0C 00 0000082C 42BA42AD RPGS WARN:THUMB WARN:OVERKILLEND  ak2_sd_akaio181.dldi

Fix Feature rambase  all  glue got  bss  sizes filesize rombase  name game area
0E 00000021 0202D440 04AC 000C 0000 001C 0D 0F 002D1640 0002D640 MK5N #### ARM9  GeoWars.nds
00 00000000 02001040 4000 0000 0000 0000 0E 0E 0003D640 00001240 DLDI #### ARM9 WARN:NOALLOC32K BOOT_fc.nds
00 00000000 0201BE40 8000 0000 0000 0000 0F 0F 00078840 0001C040 DLDI #### ARM9  ndsmail.nds
00 00000000 02034C80 8000 0000 0000 0000 0F 0F 000CE800 00034E80 DLDI #### ARM9  lmp-ng-1.02.nds
00 00000000 02016240 8000 0000 0000 0000 0F 0F 00051240 00016440 DLDI #### ARM9  000SNEmulDS.nds
00 00000000 02037500 8000 0000 0000 0000 0F 0F 000AC040 00037700 DLDI #### ARM9  ComicBookDS.nds
00 00000000 02037500 8000 0000 0000 0000 0F 0F 000AC240 00037900 DLDI  -??-  ComicBookDS.sc.nds
00 00000000 020301C0 8000 0000 0000 0000 0F 0F 00088440 000303C0 DLDI #### ARM9  pokeyDS.nds
0E 00000013 0202D440 07C0 0000 0000 001C 0D 0F 002D1840 0002D840 SCSD  -??-  GeoWars.sc.nds
00 00000000 02006300 8000 0000 0000 0000 0F 0F 000BCE40 00006500 DLDI #### ARM9  MissileCommand.nds
0C 00000013 02018900 0754 0000 0000 001C 0B 0F 00058E00 00018B00 MMCF #### ARM9  ds81.nds
00 00000000 02024B80 8000 0000 0000 0000 0F 0F 00100840 00024D80 DLDI #### ARM9  GameUP.nds
0E 00000023 02015C40 05C4 0000 0000 0000 0D 0F 00136640 00015E40 GMTF #### ARM9  011-Slots.nds
00 00000000 02013000 8000 0000 0000 0000 0F 0F 00068240 00013200 DLDI #### ARM9  Weckermp3.nds
00 00000000 0200B040 8000 0000 0000 0000 0F 0F 0004A600 0000B240 DLDI #### ARM9  Flickbook_v0.3_(Preview)_(Nintendo_DS).nds
00 00000000 02022780 8000 0000 0000 0000 0F 0F 002E9640 00022980 DLDI #### ARM9  TowerDefense.nds
00 00000000 02022780 8000 0000 0000 0000 0F 0F 002E9840 00022B80 DLDI  -??-  TowerDefense.sc.nds
00 00000000 02011640 8000 0000 0000 0000 0F 0F 00166040 00011840 DLDI #### ARM9  Xmas_gifts.nds
00 00000000 02056880 8000 0000 0000 0000 0F 0F 000BB640 00056A80 DLDI #### ARM9  dsdoom.nds
00 00000000 02056880 8000 0000 0000 0000 0F 0F 000BB640 00056A80 DLDI #### ARM9  dsdoom121.nds
00 00000000 02055380 8000 0000 0000 0000 0F 0F 000A2640 00055580 DLDI #### ARM9  dsdoom112.nds
00 00000000 02055D40 8000 0000 0000 0000 0F 0F 000B7640 00055F40 DLDI #### ARM9  dsdoom120.nds
00 00000000 02054600 8000 0000 0000 0000 0F 0F 000A0040 00054800 DLDI #### ARM9  dsdoom111.nds


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: Gilbert and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group