Reverse-engineering DLDI specs for NDS

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

tepples wrote:In order to help you further, I might need to understand what went wrong last time you asked on forum.gbadev.org.
No, you rather don't want to know that - it just didn't work out well. And, there's almost nobody left having started new threads in the DS development section in past 5 years. Maybe there'll be some bigger NDS/DSi retro scene in some years, but at the moment it's not, at least not at gbadev.org.
Or maybe it'll be in nesdev other retro section - the NDS is really kinda retro now. And the DSi was widely seen as NDS cost-down-retro-revision even when it was new. I only hope nobody feels distracted when I post that kind of stuff here - it's just because I like this forum (and mind that the GBA/NDS video engines aren't so distant from SNES).
tepples wrote:This interleaving might be part of why you don't notice a wait when loading an application using DLDI.
If the flashcart bootloaders were supporting multithreading for that purpose (I would guess not).
Finding the DLDI header won't take up too much time anyways (if it's in first some Kbytes of the ARM9 area).
The bigger problem would loading NDS programs without DLDI support - then it would need to scan the whole ARM9 area.

I didn't do the maths yet on how slow it could be - maybe it isn't taking up too many milliseconds even on large ARM9 bootcode blocks. But, two ideas for speeding up things:

If the RAM=ROM+1FFFE00h formula does apply to all cart headers, then one could use that to detect files with DLDI (and skip patching normal software without DLDI).

And, there are those sixteen FFh-bytes at 1230h in the above ROM dump, that looks as if the DLDI header at 1240h were 32-byte aligned? If that's the case in all .nds files then one would need to verify only each 8th word. The memory system would still have the same amount of traffic (for loading 32-byte cache lines), but "LDR r0" should be around 7 clks faster than "LDMIA r0-r7", and needing only one CMP instead of eight CMP/CMPNE's should be also 7 clks faster.

Oh, and ARM7 support. My current theory would be that the code is loaded to ARM9 memory space (using the RAM=ROM+1FFFE00h addressing), and ARM7 might simply jump to the same Main RAM locations when using the DLDI functions.
The things that could cause ARM7 issues:
The driver maker might have used ARM9 opcodes (eg. BLX) in DLDI.
And, if the .nds file does NOT align the driver area to 32-byte cache lines, then things could go wrong if it would store variables at the very end of the allocated DLDI memory space (but unlikely that it has squeezed memory that tightly).
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

Sorry. Not important.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by tepples »

I'd hazard a guess that drivers for SLOT-2 cards are more likely to be ARMv4 compatible in order to run on the ARM7 in GBA mode, as a SLOT-2 card can also be used in an actual GBA.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

Yah, the GBA cart makers probably knew how not to use ARM9 opcodes.
Going by the chism page, the problem applies to an older version for some R4 card, and there's a patched bugfixed driver for it.
I haven't compared the two R4 driver versions yet, doing so would probably reveal what had caused the ARM7 issue.

My theory about a fixed "RAM=ROM+1FFFE00h" formula was wrong. The installer is doing that by taking the old and new text_start entries (ie. from the old unpatched .nds file, versus newly installed driver from .dldi file):

Code: Select all

    memOffset = rd(pAH, DO_text_start);       <--- FROM pAH here !!   (.nds)
    if (memOffset == 0) {memOffset = rd(pAH, DO_startup) - DO_code;}
    ddmemOffset = rd(pDH, DO_text_start);     <--- FROM pDH here !!!! (.dldi)
    relocationOffset = memOffset - ddmemOffset;
Hmmmm, I think... that's working for any memory addresses including in ARM7 area, and including in Fast WRAM, or even in VRAM.
The text_start entry in the .nds file tells the installer where the driver finally appear in RAM (regardless of it's location in ROM).
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

Just making sure that I didn't completely misread the HLL code in dlditool.c. Here comes the proof-of-bugginess.
killer.zip
(799 Bytes) Downloaded 768 times
BEWARE the attachment will DESTROY your NDS file. You can't re-install any working DLDI driver in your NDS file after using killer.dldi.

Code: Select all

BOOT_FC.NDS file before installing killer.dldi:
   001240: ED A5 8D BF 20 43 68 69  73 68 6D 00 01 0E 00 0E   .... Chishm.....

BOOT_FC.NDS file after installing killer.dldi (bytes at 1243h-1246h are destroyed):
   001240: ED A5 8D FF 30 00 02 69  73 68 6D 00 01 0E 01 0E   ....0..ishm.....

Content of the KILLER.DLDI file:
   000000: ED A5 8D BF 20 43 68 69  73 68 6D 00 01 0E 01 0E   .... Chishm.....
   000010: 44 4C 44 49 20 64 72 69  76 65 72 20 66 6F 72 20   DLDI driver for
   000020: 64 65 73 74 72 6F 79 69  6E 67 20 79 6F 75 72 20   destroying your
   000030: 4E 44 53 20 66 69 6C 65  00 00 00 00 00 00 00 00   NDS file........
   000040: 00 00 43 68 F8 7F 43 68  00 00 00 00 00 00 00 00   ..Ch..Ch........
   000050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
   000060: 4B 49 4C 4C 00 00 00 00  80 00 43 68 80 00 43 68   KILL......Ch..Ch
   000070: 80 00 43 68 80 00 43 68  80 00 43 68 80 00 43 68   ..Ch..Ch..Ch..Ch
   000080: 00 00 A0 E3 1E FF 2F E1  00 00 00 00 00 00 00 00   ....../.........
   000090: 00 00 00 00 00 00 .. ..  .. .. (zeropad to 16Kbyte size)
The killer.dldi file is basically a copy of default.dldi, with FIX_ALL enabled, and with virtual addresses changed from BF80xxxxh to 6843xxxxh (in this case causing the "Ch" in "Chishm" to be seen as matching address MSBs). This is making use of all bugs at once:
- The DLDI header itself can be destroyed by address adjustments.
- Address adjustments can be performed even on non-word-aligned-words.
- FIX_ALL really doesn't work (and the other FIX_features aren't much better).
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

I've tried to track down a few more programs that use DLDI...

Is there a list with "Games and Tools that do use DLDI" somewhere?

What I've found is https://ezflash.sosuke.com/viewtopic.php?t=4048 (list of 15 dldi games/tools, most links are broken, but 5-6 are still working), and https://pdroms.de/?s=dldi&post_type=pdr_file_post (10 more dldi games/tools). And, http://www.chishm.com/SendSave/index.html (has a GBA (!) tool called "GBA Game Save Backup Utility" using DLDI).

Looking at some of those downloads... they are all having 32Kbytes allocated (so the BOOT_FC.NDS with only 16Kbytes seems to have been a rare exception - and it's probably nonfunctional anyways, as it's a DSi tool that probably doesn't support NDS flashcarts at all).
For the alignment, they seem to be all 64-byte aligned, but the padding space isn't obvious (=FFh filled) in all cases, so it's hard to say if they were padding for 32-byte or 64-byte alignment... except, the GBA tool, that's clearly using padding to 64-byte boundary.
So I guess it might be relative safe to assume that the installer tool needs to check only words at 64-byte boundaries (in "most cases" at least, there's probably somebody who had changed that alignment).

Would there be any interest in DLDI support on DSi? I have no idea how many games & tools are actually needing DLDI support (and if they were really worth adding DLDI support).
The "top ten titles" might already have native support for DSi SD/MMC slot, if that's so, then DLDI would be needed only for some rather obscure old NDS titles, ie. the kind of stuff that wasn't updated (and maybe not even used or downloaded) in the past some years.

About adding DLDI support in unlaunch: It might be possible, but at the moment I don't really want to go through the hazzle...
The how-to idea would be "hoping" that most of the DLDI tools are using some sort of "standard libnds" functions on ARM7, then the installer could hook that code (IRQ handler or so), and the hook could check if ARM9 requests a DLDI function to be executed.
Most of the handshake could be done via the DLDI main RAM buffer (ie. by having the request/param words, and the ARM7 code, and a small buffer for a few sector(s), and the a request/ready flag in that memory space) (so one won't need any DMA or IPC for communicating between ARM9 and ARM7).
The main issue would be to find a good ARM7 hook location (and hope that it's alive & working in all situations, and without crashing or screwing up ARM7 timings too much).

If somebody knows a good hook location in common homebrew ARM7 code, please let me know!!!
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

I have also disassembled some of the DLDI related code in the boot_fc.nds file (ie. that stuff that uses the .dldi functions).

First of, below is initializing EXMEMCNT using the FEATURE_SLOT_xxx flags in DLDI header.
For ARM7 side, one would need to change the code to set bits in EXMEMCNT to 1=ARM7 instead of 0=ARM9.
EXMEMCNT is write-able only on ARM9, so the code must be always executed on ARM9 side (even when using DLDI on ARM7 side).

Normally only one of the FEATURE_SLOT_xxx bits should be set (depending on where the storage hardware is located).
The code does also permit BOTH bits (in rare case that the memory were wired to BOTH slots, or with having an access LED in the second slot, or whatever weird thing).
The code does also permit NONE of the bits to be set (eg. when using other media) (eg. would work for DSi SD/MMC slot, but, that slot can be accessed by ARM7 only, so it won't work with DLDI code on ARM9 side).

Code: Select all

                 ;------------------
                 init_dldi_features:
0200B028 4B08     ldr     r3,=2001040h       ;DLDI hdr
0200B02A 6E5B     ldr     r3,[r3,64h]   ;hdr[64h] aka FEATURE_xxx flags
0200B02C 06DA     lsl     r2,r3,1Bh  ;bit4 to bit31 (signflag) ;FEATURE_SLOT_GBA
0200B02E D504     bpl     200B03Ah ;@@skip1
0200B030 2080     mov     r0,80h
0200B032 4907     ldr     r1,=4000204h  ;EXMEMCNT
0200B034 880A     ldrh    r2,[r1]
0200B036 4382     bic     r2,r0    ;clear bit7  ;GBA Slot Access (0=ARM9)
0200B038 800A     strh    r2,[r1]
                 @@skip1:
0200B03A 069B     lsl     r3,r3,1Ah  ;bit5 to bit31 (signflag) ;FEATURE_SLOT_NDS
0200B03C D504     bpl     200B048h ;@@skip2
0200B03E 4A04     ldr     r2,=4000204h  ;EXMEMCNT
0200B040 4904     ldr     r1,=0FFFFF7FFh
0200B042 8813     ldrh    r3,[r2]
0200B044 400B     and     r3,r1    ;clear bit11 ;NDS Slot Access (0=ARM9)
0200B046 8013     strh    r3,[r2]
                 @@skip2:
0200B048 4803     ldr     r0,=2001040h+60h   ;return DLDI hdr+60h
0200B04A 4770     bx      r14
And then here's a code snippet for calling the actual DLDI functions:
The BLX would work only on ARM9, but ARM7 could do something similar via some opcode combo.
If the functions are always called via BLX or BX, then they could have THUMB set.
But it might be safer to stick with ARM code for the function entrypoints.

Code: Select all

                 ;------------------
                 dldi_startup_inserted:   ;to be called AFTER init_dldi_features
020061F4 B5F0     push    r4-r7,r14
020061F6 4647     mov     r7,r8      ;save r8
020061F8 46CE     mov     r14,r9     ;save r9
020061FA B580     push    r7,r14
020061FC 0004     lsl     r4,r0,0h   ;r4=r0
020061FE B085     add     sp,-14h
02006200 000D     lsl     r5,r1,0h   ;r5=r1 (aka dldi hdr+60h)
02006202 4690     mov     r8,r2      ;r8=r2
02006204 001E     lsl     r6,r3,0h   ;r6=r3
02006206 2800     cmp     r0,0h
02006208 D011     beq     200622Eh ;@@fail
0200620A F007FE49 bl      200DEA0h              ;---> whatever
0200620E 426A     neg     r2,r5                 ;\
02006210 416A     adc     r2,r5                 ;
02006212 2308     mov     r3,8h                 ; uhm,
02006214 4283     cmp     r3,r0                 ; compiler optimization for not
02006216 4180     sbc     r0,r0                 ; doing CMP r5,0 + CMP r0,8 for
02006218 4240     neg     r0,r0                 ; having only 1 branch opcode?
0200621A 4310     orr     r0,r2                 ;
0200621C D107     bne     200622Eh ;@@fail      ;/
0200621E 68AB     ldr     r3,[r5,8h]            ;\
02006220 4798     blx     r3                    ; call hdr[68h] aka startup()
02006222 2800     cmp     r0,0h                 ;
02006224 D003     beq     200622Eh ;@@fail      ;/
02006226 68EB     ldr     r3,[r5,0Ch]           ;\
02006228 4798     blx     r3                    ; call hdr[6Ch] aka isInserted()
0200622A 1E07     sub     r7,r0,0               ;   ;<-- r7=result (!)
0200622C D106     bne     200623Ch ;@@okay      ;/
                 @@fail:
0200622E 2700     mov     r7,0h
                 @@return_r7:
02006230 0038     lsl     r0,r7,0h
02006232 B005     add     sp,14h
02006234 BC0C     pop     r2,r3
02006236 4690     mov     r8,r2
02006238 4699     mov     r9,r3
0200623A BDF0     pop     r4-r7,r15
                 ;---
                 @@okay:
                  ... more stuff here... then jumping to @@return_7
If startup or isInserted fails, then the program is usually displaying "fatInitDefault failed!".
Some programs are also having more meaningful error messages, directing the user to check if have installed their DLDI driver.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by tepples »

EXMEMCNT? What the crap?
Attachments
whats_the_craps.png
whats_the_craps.png (8.96 KiB) Viewed 24030 times
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

Yes, sorry. I was tired and did spellcheck what I was writing. I meant that one needs to control the excrements, of course.
I'll also need to fix that in http://problemkaputt.de/gbatek.htm#dsme ... andmainram

I've also checked the r4tf v1/v2 drivers.
The older v1 without ARM7 support is using THUMB code trying to return to ARM code with "POP r15".
That won't work on ARM7 (it had to use "POP r1 + BX r1" or the like).
The later v2 doesn't use any THUMB code at all (that new version is also a good bit smaller than the old version).

The v1 source code does also include some comments & options for DMA support (disabled), and support for non-2-byte aligned sector buffers (enabled). I would have assumed that sector buffers were usually/always 4-byte aligned. But going by that comments there might be a few .nds files having completely unaligned buffers.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by tepples »

ndiddy suggested K-Meleon 74 Windows 9x Edition, which runs on a Windows 98 PC with 1 GB of RAM and KernelEx set to Windows 2000 SP4 compatibility.
User avatar
PypeBros
Posts: 34
Joined: Sat Nov 10, 2018 7:35 am

Re: Reverse-engineering DLDI specs for NDS

Post by PypeBros »

Hello. I've done some work with DLDI in the past, so if there are questions you would still like to see answered despite your "please disregard this topic" warning at the top of the first post, go ahead.

Basically,
- a DLDI-capable .nds has a location where the DLDI program should get installed and code in that .nds will use the function pointers at that location to access the driver
- the DLDI driver should come from the device itself. The .nds can be patched on-the-fly when loaded into memory.
- some older linker cards did not have DLDI. Instead, they used to expect developer to access SD card through their own, proprietary interface. That was e.g. the case for the supercard. When DLDI came out, people using these cards had to rely on a .dldi file and a batch-patcher tool to embed the driver into the .nds image before loading the game on their system, because nothing in the linker firmware would do that (and the game would not know their device).

That's why you see a DLDI chunk with placeholders in .nds files you download: this is simply the code that is there, waiting to be replaced by the linker firmware. And it likely does nothing because it doesn't know what device it will be running on.

Hope that helps.
Image - may the source be with you.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by nocash »

tepples wrote:ndiddy suggested K-Meleon 74 Windows 9x Edition, which runs on a Windows 98 PC with 1 GB of RAM and KernelEx set to Windows 2000 SP4 compatibility.
Interesting, the faked-user-agent-feature might even work for win98 users to get into closed community sites like cpcwiki.eu but I am still feeling badly discriminated because I am not one of the win98 users with whopping 1GB RAM nor with KernelEx (not too mention that they forgot win95 support in their win9x version). But the project as such isn't bad.

I've tried to estimate the chance of DLDI errors to occur with the FIX_xxx features:

Code: Select all

FIX_ALL:
The risk for one word to match ddmemStart base would be:
  1:100000000h  for BF800000h
The risk for one word to match ddmemStart..ddmemEnd would be:
  1:1000000h    for BF800000h..BF8000FFh  ;small .dldi file
  1:20000h      for BF800000h..BF807FFFh  ;large .dldi file
The risk for ANY WORD in the .dldi file to match ddmemStart..ddmemEnd would be:
  1:10000h      for BF800000h..BF8000FFh  ;small .dldi file
  1:4           for BF800000h..BF807FFFh  ;large .dldi file
If there were 16 .dldi drivers, 64 .nds homebrews, each .nds with 4 revisions,
that would give 16x64x4 combinations (=1000h), so the overall risk would be:
  1:10h         for BF800000h..BF8000FFh  ;small .dldi file
  400h:1        for BF800000h..BF807FFFh  ;large .dldi file
Or same if the 64 authors had tested 64 builds with 1 .dldi driver each.
I haven't spotted a .dldi driver actually using FIX_ALL yet, but if it were
used then it would probably cause mysterious troubles once or then.

FIX_GLUE and FIX_GOT:
The GLUE/GOT tables are relative small, so that does reduce the risk.
If all words in the table are WANTED to be adjusted, and if ddmem range is
BF800000h..BF807FFFh then there's no risk of having a word with BF80h in its
LSBs (since BF80BF80h or BFBF80xxh would exceed the BF800000h..BF807FFFh
range).
The LSB of a word could be BFh, but the previous (already adjusted) word
would be likely a NDS memory address (eg. 00xxxxxxh..07xxxxxxh) without
risking to have 80h in it's MSB (which could be seen as BF80h).
No idea if Chishm was doing that intentionally, but using BF800000h as ddmem
base seems to be surprisingly well chosen to overcome the installer bugs.
The only issue would be a .dldi file that uses the whole 32K space with
GOT/GLUE tables located at the very end of the 32K space, then the next bytes
after the 32K area would cause problems if they were 80h,BFh or xxh,80h,BFh.
FIX_GLUE and FIX_GOT are used by most or all .dldi drivers, but it's quite
possible that they will never trigger any bugs due to lucky circumstances.
PypeBros wrote:if there are questions you would still like to see answered despite your "please disregard this topic" warning at the top of the first post
That warning about making a fool of myself? That's just there because I suspect that most people would say that it's foolish to "reverse engineer open source HLL projects" (or at least, I would say so myself). But if you want to join the club...

I am wondering how many dldi drivers are there out there?

The chishm webpage has about 40 drivers (more than I had estimated above), and they are all from 2006-2008, so there might be even more dldi drivers since then, unless the newer flashcarts are still using the old drivers?

Especially interesting would be if some of them are using FIX_ALL?
Using that would make sense if they have addresses in literal pool, without being aware of the installer bugs.

And is DLDI as error-prone as it looks like in the installer source code?
Eg. people having properly installed the correct driver, and then randomly seeing undefined opcodes during driver execution?

Oh, and is there some reason for the unaligned-word-adjustments?
I mean, ARM CPU can't access unaligned words at all, unless it were using some kind of "unaligned_32bit_read_function".
If some .dldi files (or libfat) are using unaligned words then it would be required, otherwise it's making the address-adjust guessing more unreliable.

Yesterday I have spotted this sentence in internet (discussing ExFAT with DLDI):
Oh, and on most linkers, that would require a firmware upgrade because the linker use the SD card to store files of its own, too. again, this might not be available except you have a fresh new linker.
That makes me wonder if there's something going on - that I am not aware of yet.
What is that linker???
It's apparently not the usual "source-->assembler-->linker-->executable" toolchain.
It sounds more as if there were a runtime-linker used by the .dldi or .nds file itself?
Maybe "linker" is referring to the bootmenu in the flashcarts...?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Reverse-engineering DLDI specs for NDS

Post by tepples »

"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.
User avatar
PypeBros
Posts: 34
Joined: Sat Nov 10, 2018 7:35 am

Re: Reverse-engineering DLDI specs for NDS

Post by PypeBros »

nocash wrote:Yes, sorry. I was tired and did spellcheck what I was writing. I meant that one needs to control the excrements, of course.
I'll also need to fix that in http://problemkaputt.de/gbatek.htm#dsme ... andmainram
EXMEMCNT for EXternal MEMory CoNTrol, presumably.
The v1 source code does also include some comments & options for DMA support (disabled), and support for non-2-byte aligned sector buffers (enabled). I would have assumed that sector buffers were usually/always 4-byte aligned. But going by that comments there might be a few .nds files having completely unaligned buffers.
It would indeed be very welcome to align buffers for performance. However, because the block you want to write might come from something else, with some poor padding before the useful data and so on, it is usually good practice for library-class code to be ready to face the odds of non-aligned input from client code rather than pushing the restriction down to the client code (we see that in memmove, and other similar things, iirc).
But as far as I know flashcards have adopted the idea as auto-install the driver everytime when booting a game, in worst case that's meaning scanning a whole 128Mbyte file - only to find out that it doesn't contain a slot for DLDI driver at all.
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. The rest of the file (for homebrews) is typically accessed through the DLDI driver. And when you want to run the binary, your flashcard has to load it all in memory anyway, so it can just scan as it loads.

I see that the FIX_ALL thing is puzzling you a lot. And indeed, it feels pretty weird to request that any occurence of a given 32-bit word would require it to be transformed. I can imagine that this was provision for driver writers who would not necessarily generate a "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. I think FIX_ALL might have been added to that to support hypothetical drivers written e.g. in low-level assembly. Clearly, before doing that (requiring the DLDI patcher to FIX_ALL), you would have to ensure that none of your constants/strings/opcodes accidentally enter the memory range where things are fixed.
But DLDI is for NDS, and that requires to transfer code from ROM to RAM before executing it.
At least that's so when reading from NDS slot (and in practice, it's almost always also done that way when reading NDS code from GBA slot).
Even when your linker (like the SuperCard) is a GBA-slot device, only a small part of its internal memory is used for accessing the SD card contents. Usually it will map some registers on the GBA bus, as well as a few sector-sized cache. But the content of the .nds file needs to be streamed from the SD card to the RAM through those on-GBA-slot-"ROM" areas. Which sector of the SD card to fetch and whether the underlying hardware is ready for that is the job of the other memory-mapped registers.
Only the SLOT-1 linker firmware (like a R4) will be streamed into RAM with the "normal" nintendo protocol when homebrew is involved (afaik).
Image - may the source be with you.
User avatar
PypeBros
Posts: 34
Joined: Sat Nov 10, 2018 7:35 am

Re: Reverse-engineering DLDI specs for NDS

Post by PypeBros »

but even with all that, you still have (imho) a valid point with the way the patching loops work. 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. I see it survived even in the newer "bootloader" function of 'hbmenu', though.

And no, in 10+ years of NDS development and DLDI patching, I've never encountered an invalid opcode that could be the responsibility of the DLDI process rather than to some silly loop of mine. Of course, if such mis-patching ever occured, it would be caught at the design house of the linkers vendors (as it doesn't patch the .nds, but the .dldi)

NOTE, that when advancing the patcher will keep reading the MSB of the patched pointer while ignoring LSB of the patched pointers and start considering LSB of the next pointer (or non-pointer), because of little-endianness of the NDS platform.
Image - may the source be with you.
Post Reply