Ah! That does explain it. Reminds me that there's also a "DSLink" flashcart with support for "GBA game linking" (whatever that means).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.
With Bung Game Doctor in mind, I wonder if it had transformed to saying "you use sound if your doctor is too old".
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.PypeBros wrote:EXMEMCNT for EXternal MEMory CoNTrol, presumably.
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).
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.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.
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.
Yeah, looks so.PypeBros wrote:I see that the FIX_ALL thing is puzzling you a lot.
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).
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:I think FIX_ALL might have been added to that to support hypothetical drivers written e.g. in low-level assembly.
Do you know more about that GOT (and GLUE) tables?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.
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?
Good to know that it had worked. Then, I guess your driver doesn't use FIX_ALL, right?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.
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).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.
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).
But, with FIX_ALL, only if the header-patching and double-patching were fixed.PypeBros wrote:Of course, if such mis-patching ever occured, it would be caught at the design house
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 :)