ROM Hack Is there a way to patch an original ds cartridge?

[Kajitani-Eizan]

It's a nice idea from a legal perspective, but I really don't see any practical reason to do this instead of just dumping the ROM, hard patching it, and using a flashcart to play it. I'm pretty sure most governments and companies are not going to care that you are dumping the ROM of a game whose cartridge you own for the purposes of personal entertainment.

 

[RandomDSdevel]

AceKards do not, but Supercard DSTWOs do

Oh…I have an Acekard 2.1 for my original Nintendo DS.

 

[RandomDSdevel]

I think technically a few non iplayer/ismm/dstwo flash carts offload a tiny bit of CRC calculation for DLDI (and supposedly some aspects of general flash cart extras) to the cart itself which does get a nice speed boost. No chance of using such things for anything general purpose though.

As for the matter at hand sitting in between the game and the cartridge was what game genies used to do hence the rarity of the codes for them, the perceived difficulty in making them and why they are frequently more far reaching. The DS has an interesting aside in that the binary (as in ARM9.bin and co) ends up in writable memory and any files that aspire to do anything will do so as well which you can get to with conventional cheat engines; this is why cheats sometimes can bypass AP (you can patch the binary, which contains the checks, in RAM) and why some better cheats are almost gamegenie levels of change. Even ignoring that most AR engines have a limit of the amount of codes it can pull off I would hate to consider trying this for even a moderate file change and patching overlays is not much fun either (granted the "if - then" patch options of AR engines leave a lot to be desired for anybody that has the barest clue about programming which really does not help). Best case scenario you patch the game to read things from the GBA slot (32 megs of fast memory you control after all) but that is still not the nicest.

As others said though unless you are especially tied to your pokewalker then there is not a lot of point.

Just to add another thing to the pile- technically the passmes worked in such a manner. They were less patch 50 megs of ROM via onboard ROM reads and more patch a few kilobytes to get a jump to a user controlled location though. If I had to build such a device I would probably start with those (and maybe one of those blaze 3 game selectors).

I am tied to my Pokéwalker; that's the problem preventing me from just going to go get a ROM. Besides, I'm seriously considering ditching my flash cart for everything but development (I might ask later about how to do this with Xcode 4.6) and buying the cartridges for which I already have ROMs of questionable legality due to the fact that my 18th birthday is only four days away. And, considering the rest of your post, I don't have much programming experience and wanted to get started with my DS and C++11 (or C++14 if it has come out by the time I've started,) so I'm having some trouble understanding your post.

 

[RandomDSdevel]

It's a nice idea from a legal perspective, but I really don't see any practical reason to do this instead of just dumping the ROM, hard patching it, and using a flashcart to play it. I'm pretty sure most governments and companies are not going to care that you are dumping the ROM of a game whose cartridge you own for the purposes of personal entertainment.

Nintendo would care, obviously, and I want to develop for them either directly or, more likely, via association someday.

 

[RandomDSdevel]

Okay, going back to an earlier post of Rydian's gave me an idea:

You can't patch DS things on the fly (outside of something like an ARDSi that can patch reads but you'd have a hell of a time implementing an entire ROM hack in the form of AR codes), and retail carts are read-only.

Then what I need/want is something that can automatically convert a ROM hack into a set of Action Replay (that's what you mean by AR–Action Replay, not augmented reality–right?) codes that I can use! But…I don't have an Action Replay. Wait: my Acekard 2.1 supports Action Replay codes! So I still need a DS card slot-splitting device that will allow my Acekard to start running before the other, retail cartridge…could I stick the retail cartridge into my 3DS, not launch it, and load the Acekard's Action Replay code-implementation system in over DS Download Play via the 3DS's backwards-compatibility wireless mode such that it can launch the main DS cartridge?

 

[Rydian]

Then what I need/want is something that can automatically convert a ROM hack into a set of Action Replay (that's what you mean by AR – Action Replay, not augmented reality – right?) codes that I can use! But…I don't have an Action Replay. Wait: my Acekard 2.1 supports Action Replay codes! So I still need a DS card slot-splitting device that will allow my Acekard to start running before the other, retail cartridge…could I stick the retail cartridge into my 3DS, not launch it, and load the Acekard's Action Replay code-implementation system in over DS Download Play via the 3DS's backwards-compatibility wireless mode such that it can launch the main DS cartridge?

1 - There is nothing to make this into AR codes automatically that will actually work. The hack will have to be analyzed and all the codes will have to be manually created. Somebody will need to make codes to patch all the ROM/resource reads on-the-fly.

2 - The Acekard 2.1 won't work in the 3DS.

3 - There is no cart-splitting device.

4 - The only way to use a flash cart to apply cheats to retail ROMs is with the NitroHax homebrew, which requires cart-swapping, and cart-swapping does not work on anything past the DS Lite.

5 - NitroHax needs to load all the AR codes to apply into the DS's RAM to store it during the cart swap, so you're limited to ~3.5MB or so of codes (the DS only has 4MB of RAM), and each AR code made for each ROM difference will be larger than the difference itself, and the JUS patch appears to already be 5MB to begin with...

Get a flash cart, rip/download the ROM, patch it, and you can play it just fine.
Anything else is a stupid waste of time/money for the same or lesser effect.

 

[RandomDSdevel]

1 - There is nothing to make this into AR codes automatically that will actually work. The hack will have to be analyzed and all the codes will have to be manually created. Somebody will need to make codes to patch all the ROM/resource reads on-the-fly.

2 - The Acekard 2.1 won't work in the 3DS.

3 - There is no cart-splitting device.

4 - The only way to use a flash cart to apply cheats to retail ROMs is with the NitroHax homebrew, which requires cart-swapping, and cart-swapping does not work on anything past the DS Lite.

5 - NitroHax needs to load all the AR codes to apply into the DS's RAM to store it during the cart swap, so you're limited to ~3.5MB or so of codes (the DS only has 4MB of RAM), and each AR code made for each ROM difference will be larger than the difference itself, and the JUS patch appears to already be 5MB to begin with...

Get a flash cart, rip/download the ROM, patch it, and you can play it just fine.
Anything else is a stupid waste of time/money for the same or lesser effect.

1 and 2.) Only the real cartridge (Pokémon SoulSilver) has to work on the 3DS, and that system's backwards compatibility with the Nintendo DS allows me to make that cartridge run just as well as a 3DS cart (well, okay: it takes a little longer to boot into the backwards-compatibility mode I was only wondering if I could somehow stick my Acekard 2.1 in my original DS and use it to send code to my 3DS via its backwards compatibility with DS Download Play.

3.)Fast6191 mentioned something about a 'Blaze 3 card selector,' and something like that would, if it were cheap, eliminate any need I might have had to shuttle code back and forth between two systems on the fly via wireless communications.

4 and 5.)Could I modify NitroHax to work with my above two ideas, eliminating the card-swapping mechanism; or do I have to do it the old-fashioned way and bring the 'HG/SS – Kris as Female Protagonist' hack in first?

 

[Rydian]

1 and 2.) Only the real cartridge (Pokémon SoulSilver) has to work on the 3DS, and that system's backwards compatibility with the Nintendo DS allows me to make that cartridge run just as well as a 3DS cart (well, okay: it takes a little longer to boot into the backwards-compatibility mode

Obviously you've never actually TRIED it, because no, it doesn't work.
http://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/
The DSi and 3DS introduced a whitelist to prevent flash carts from booting, which is why newer flash carts (like the Acekard 2i) need to fake themselves as a game in order to run. The Acekard 2.1 doesn't do that, and so won't boot on the DSi/3DS.

I was only wondering if I could somehow stick my Acekard 2.1 in my original DS and use it to send code to my 3DS via its backwards compatibility with DS Download Play.

No.

3.)Fast6191 mentioned something about a 'Blaze 3 card selector,' and something like that would, if it were cheap, eliminate any need I might have had to shuttle code back and forth between two systems on the fly via wireless communications.

Passme and such ran code from the GBA slot, and the 3DS does not have a GBA slot. While in theory older cart-swapping tricks could be used, cart-swapping does not work on the DSi/3DS. In addition there were some passthrough devices that would run from slot-1, but they would only fake the header and leave all the booting and actual code running to the plugged-in cart (and they were blocked by the DSi/3DS flash cart checks and never updated since they weren't needed by that time anyways).

4 and 5.)Could I modify NitroHax to work with my above two ideas, eliminating the card-swapping mechanism; or do I have to do it the old-fashioned way and bring the 'HG/SS – Kris as Female Protagonist' hack in first?

Here's how NitroHax works.

1 - Start it up on a flash cart (which means you need a flash cart that works in that DS model in the first place).

2 - Take the flash cart out.

3 - Put the real cart in.

4 - Tell it to start the game.

Notice steps 2 and 3? That's cart-swapping, and does not work on the DSi/3DS. In addition, since the homebrew cart is removed, once the game is inserted no more codes can be loaded from the original flash cart, which is why the size of the code list needs to be small enough to fit into RAM.

The only way to play ROM hacks on a DSi/3DS is to use a flash cart.

 

[RandomDSdevel]

Obviously you've never actually TRIED it, because no, it doesn't work.
http://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/
The DSi and 3DS introduced a whitelist to prevent flash carts from booting, which is why newer flash carts (like the Acekard 2i) need to fake themselves as a game in order to run. The Acekard 2.1 doesn't do that, and so won't boot on the DSi/3DS.

No.

Passme and such ran code from the GBA slot, and the 3DS does not have a GBA slot. While in theory older cart-swapping tricks could be used, cart-swapping does not work on the DSi/3DS. In addition there were some passthrough devices that would run from slot-1, but they would only fake the header and leave all the booting and actual code running to the plugged-in cart (and they were blocked by the DSi/3DS flash cart checks and never updated since they weren't needed by that time anyways).

Here's how NitroHax works.

1 - Start it up on a flash cart (which means you need a flash cart that works in that DS model in the first place).

2 - Take the flash cart out.

3 - Put the real cart in.

4 - Tell it to start the game.

Notice steps 2 and 3? That's cart-swapping, and does not work on the DSi/3DS. In addition, since the homebrew cart is removed, once the game is inserted no more codes can be loaded from the original flash cart, which is why the size of the code list needs to be small enough to fit into RAM.

The only way to play ROM hacks on a DSi/3DS is to use a flash cart.

Regarding your first and second points, I have an original (phat) DS as well as a 3DS. Additionally, why couldn't I create a version of NitroHax that uses two systems instead of cart-swapping? After all, removing a game card while your system is on would probably make the cartridge involved lose data, and that is something that I do not want to risk.

 

[Rydian]

Regarding your first and second points, I have an original (phat) DS as well as a 3DS.

And you can play the patched ROM in the Acekard 2.1 in the original DS.

Additionally, why couldn't I create a version of NitroHax that uses two systems instead of cart-swapping?[/quite]If you had the skills/ knowledge, you wouldn't be here asking such stupid questions, to be blunt.
Whatever's in the system's RAM during Download Play is wiped when you launch a cart anyways.

After all, removing a game card while your system is on would probably make the cartridge involved lose data, and that is something that I do not want to risk.

The cart you remove to swap is the flash cart, not the game cart.

 

[RandomDSdevel]

The cart you remove to swap is the flash cart, not the game cart.

But wouldn't I still lose data? Isn't it simply bad to remove a cartridge from a console during its operation in general?

Whatever's in the system's RAM during Download Play is wiped when you launch a cart anyways.

Has anybody ever figured out a way around this? I thought that maybe the Download Play software could load the cartridge, not the DS firmware.

 

[Rydian]

But wouldn't I still lose data? Isn't it simply bad to remove a cartridge from a console during its operation in general?

Lose what data? Save files for DS games are stored on the game carts themselves, not your system, and you won't be pulling your your game cart while it's on (just the flash cart). In addition Nitrohax prepares itself for being removed by suspending I/O.

Of course this is assuming you even get somebody to make custom AR codes for you implementing the patch, which I'm pretty sure is not possible for a patch of that size/complexity.

Has anybody ever figured out a way around this? I thought that maybe the Download Play software could load the cartridge, not the DS firmware.

This is not a viable approach for so many reasons I can't even be arsed to type them out.

Just use a goddamned flash cart. You're wasting your time with this.

 

[qaz00]

But wouldn't I still lose data? Isn't it simply bad to remove a cartridge from a console during its operation in general?

On systems like the Game Boy/GB Colour/GB Advance, yes, as the cartridge is part of the system address space (code executes directly from it, remove it and a crash is *almost* certain), and is directly connected to the address and data buses of the processor. On the DS, etc. the cartridge is on a separate interface, and is not directly part of the address space. To execute code from a DS cart, it must be loaded into RAM first (like an SD card). Removing the DS card during operation is fine, providing no I/O requests or commands are being processed by the cartridge interface, and even your save data will be fine.

Anyway, regardless of this, I fail to see any reason why you cannot use a flashcart. The only reason I can see you have given is this:

Nintendo would care, obviously, and I want to develop for them either directly or, more likely, via association someday.

Somehow, I doubt that Ninty would be too pleased to find out you have been playing patched/modified versions of their copyrighted content, regardless of method. Quite frankly, I fail to see the difference between you dumping your own legitimate cartridge , patching it and playing it with a flashcart; versus getting a legitimate cartridge and building a device to modify the encrypted comms between the DS and cartridge. In the end, the DS should see the same data being returned in response to its commands, and whichever method you choose, you own a license to the original content (but not a license to modify it, therefore both methods are as legal/illegal as the other).

I agree with the final line of Rydian's post, unless another reason can be given.

 

[RandomDSdevel]

On systems like the Game Boy/GB Colour/GB Advance, yes, as the cartridge is part of the system address space (code executes directly from it, remove it and a crash is *almost* certain), and is directly connected to the address and data buses of the processor. On the DS, etc. the cartridge is on a separate interface, and is not directly part of the address space. To execute code from a DS cart, it must be loaded into RAM first (like an SD card). Removing the DS card during operation is fine, providing no I/O requests or commands are being processed by the cartridge interface, and even your save data will be fine.

Anyway, regardless of this, I fail to see any reason why you cannot use a flashcart. The only reason I can see you have given is this:

-snip-

Somehow, I doubt that Ninty would be too pleased to find out you have been playing patched/modified versions of their copyrighted content, regardless of method. Quite frankly, I fail to see the difference between you dumping your own legitimate cartridge , patching it and playing it with a flashcart; versus getting a legitimate cartridge and building a device to modify the encrypted comms between the DS and cartridge. In the end, the DS should see the same data being returned in response to its commands, and whichever method you choose, you own a license to the original content (but not a license to modify it, therefore both methods are as legal/illegal as the other).

I agree with the final line of Rydian's post, unless another reason can be given.

Thanks for clarifying how older, but not newer, Nintendo consoles use their cartridges as active memory whereas newer, but not older, Nintendo consoles use cartridges more like SD cards (they even look kind of like them!) As for why I want to modify my SoulSilver cartridge the hard way, I consider this method safer, legally speaking, because of how Nintendo did not respond to the Super Smash Bros.: Project M level editor hack; Nintendo doesn't seem to care about user modifications if they are executed only at runtime in a manner that does not modify their precious hardware.

 

[FAST6191]

I still contend this is a very hard to pull off concept with no real gains at the end of it. Doubly so as you can just run a hacked ROM image.

In the entirety of ROM hacking there has been precisely one case concerning level mods or indeed mods of any form ( http://www.theregister.co.uk/2005/02/10/tecmo_sues_xbox_game_hackers/ ), two if you count the utter nonsense that was hot coffee and that does not apply here as it was Rockstar that got troubled by morons. During the entirety of ROM hacking there have been many games, including many Nintendo games and games from big companies with proper lawyers, that have been nearly entirely rewritten (we even have a classification for the style of hack - it is called total conversion).

If we must return to the pokewalker I would say use cheats instead but if things must happen and simple save transfers are not the order of the day then perhaps I will reconsider the blaze game selector- the pokewalker sits behind a selection chip on the save bus so it may be entirely possible to run the ROM on one cart and pass through various save options via a few wires. I am not sure what power is drawn from where though so things may get tricky if you have to try powering two DS carts at once, especially if one is a flash cart as those things are a bit juice happy at the best of times.

 

[qaz00]

Thanks for clarifying how older, but not newer, Nintendo consoles use their cartridges as active memory whereas newer, but not older, Nintendo consoles use cartridges more like SD cards (they even look kind of like them!) As for why I want to modify my SoulSilver cartridge the hard way, I consider this method safer, legally speaking, because of how Nintendo did not respond to the Super Smash Bros.: Project M level editor hack; Nintendo doesn't seem to care about user modifications if they are executed only at runtime in a manner that does not modify their precious hardware.

Since you seem to be dead set on doing this - go take a look at how the PassMe/PassMe2 worked, as they intercepted the header comms between the cartridge and DS and patched the entrypoint in the header. Another useful reference would be GBATEKs "DS Cartridges, Encryption, Firmware" section. Simply put, you will have to design a device similar to a PassMe, but with a large amount of storage attached. The device will have to watch KEY1 and KEY2 being enabled, and remember the keys. It will then have to decrypt every command sent, check if it is the command "Encrypted Data Read", if it is, check a lookup table to see if it needs to be patched, if so encrypt and return the patched response - if not pass the cartridges response through. All other commands should be passed through, although all encryption commands should be sniffed (so your devices encryption state is the same as the real cartridge). Good luck! (post pics, circuit diagrams and source code when (if?) you get it to work)

If we must return to the pokewalker I would say use cheats instead but if things must happen and simple save transfers are not the order of the day then perhaps I will reconsider the blaze game selector- the pokewalker sits behind a selection chip on the save bus so it may be entirely possible to run the ROM on one cart and pass through various save options via a few wires. I am not sure what power is drawn from where though so things may get tricky if you have to try powering two DS carts at once, especially if one is a flash cart as those things are a bit juice happy at the best of times.

The only issue I can see occurring with this is if the flashcarts SD interface is using the save lines to perform some function, at which point I suspect all hell might break loose (wiped save on real cart, crashed game, etc.)

 

[Normmatt]

Since you seem to be dead set on doing this - go take a look at how the PassMe/PassMe2 worked, as they intercepted the header comms between the cartridge and DS and patched the entrypoint in the header. Another useful reference would be GBATEKs "DS Cartridges, Encryption, Firmware" section. Simply put, you will have to design a device similar to a PassMe, but with a large amount of storage attached. The device will have to watch KEY1 and KEY2 being enabled, and remember the keys. It will then have to decrypt every command sent, check if it is the command "Encrypted Data Read", if it is, check a lookup table to see if it needs to be patched, if so encrypt and return the patched response - if not pass the cartridges response through. All other commands should be passed through, although all encryption commands should be sniffed (so your devices encryption state is the same as the real cartridge). Good luck! (post pics, circuit diagrams and source code when (if?) you get it to work)



The only issue I can see occurring with this is if the flashcarts SD interface is using the save lines to perform some function, at which point I suspect all hell might break loose (wiped save on real cart, crashed game, etc.)

You could use an official ards with some custom asm code to read data from the sd card. But that would essentially make it into a flashcart.

 

[RandomDSdevel]

Since you seem to be dead set on doing this - go take a look at how the PassMe/PassMe2 worked, as they intercepted the header comms between the cartridge and DS and patched the entrypoint in the header. Another useful reference would be GBATEKs "DS Cartridges, Encryption, Firmware" section. Simply put, you will have to design a device similar to a PassMe, but with a large amount of storage attached. The device will have to watch KEY1 and KEY2 being enabled, and remember the keys. It will then have to decrypt every command sent, check if it is the command "Encrypted Data Read", if it is, check a lookup table to see if it needs to be patched, if so encrypt and return the patched response - if not pass the cartridges response through. All other commands should be passed through, although all encryption commands should be sniffed (so your devices encryption state is the same as the real cartridge). Good luck! (post pics, circuit diagrams and source code when (if?) you get it to work)

Actually, I was wondering if you guys could point me to some other sites where I could get additional advice on how to build the kind of device which we have been discussing. I am unfortunately almost a complete newbie when it comes to building hardware and then programming it. I own some electronics kits (most of the Snap Circuits line of products from Elenco, as well as a micro-controller kit from Thames and Kosmos) and have wielded a soldering iron before, but of course want to gain more experience, especially with the latter (the facts that I have low vision and that using a soldering iron requires intense quality control and multiple hands doesn't help, so does anybody know about a good workspace magnifier and/or clamp setup that might make things easier in that context?) I also want to know how to program the stuff I make with the Mac integrated development environment known as Xcode (the latest version is 4.6, I believe, though it might still be in beta…) in C++ which I believe is the programming language most commonly used within the gaming industry. I've read some books, but I've found that they don't quite match up to the good, old-fashioned coding experience which I have not yet been able to acquire (I'm still trying to get my Dad to lend me a spare hard drive on which I can install a separate copy of OS X 10.8.2+ Mountain Lion as an install base for Xcode 4.6 so as to prevent any thing that goes wrong with it from jeopardizing the rest of my large family's data.) However, I will try to make this project as open-source as possible; I'll tell all of you how to find the attached resources when they go live. All in all, thanks for the support.

 

[Coto]

I am tied to my Pokéwalker; that's the problem preventing me from just going to go get a ROM. Besides, I'm seriously considering ditching my flash cart for everything but development (I might ask later about how to do this with Xcode 4.6) and buying the cartridges for which I already have ROMs of questionable legality due to the fact that my 18th birthday is only four days away. And, considering the rest of your post, I don't have much programming experience and wanted to get started with my DS and C++11 (or C++14 if it has come out by the time I've started,) so I'm having some trouble understanding your post.

what he basically said is, you jump from the ROM(Nintendo cartridge) to the writable area(user area connected to DS ram, -intercepted- at that offset), so if you were to reach there, you'd "jump" into a rewritable area (not a nintendo cartridge), and do what you really want.
-
You want to patch entirely a ROM, the DS expects to run the code engine it was supposed to, and maybe a bit more, so no "room" there for even, loading what you'd love to see in action, unless you already know arm assembly and redirect the game's engine code(only as ROM), to put your code (rewritable) [on RAM, and you'd need to know what every cycle does, running on different parts of the DS].

I don't know how a flashcard works 100%, but i'm sure they handle on a CPU and a small portion of RAM (onboard the flashcard), all the "read stuff from micro sd, apply the neccesary patches so when the code reaches the DS cpu which was already manipulated by the flashcard's CPU stays patched, else unpatched. [you'll see below what i'm trying to explain]


Why? Because every ROM chip and the code logic inside is strictly tied each other[from the logic's heart, or the code], where as the flashcard needs to "redirect -> rebuilt game code" each time a ROM is loaded [logically, because a flashcard loads different yet, strictly coded ROM routines]--> on top of that, from a removable storage media.

if you don't get it, then don't insist, because we're trying to explain this in a good manner.

 

[FAST6191]

DS flash cart internals are not my forte but it runs as follows

The way DS binaries run has been covered already- things are catapulted into the memory when the game is launched and the code runs from there. The actual DS cart with the level data, sounds and whatever else is not visible directly in memory but it can be accessed via a relatively complex (compared to all that came before it anyway) system. qaz00 already linked up a nice explanation at http://nocash.emubase.de/gbatek.htm#dscartridgesencryptionfirmware and http://files.darkfader.net/ds/files/cartridge.txt takes care of most of the rest.
The flash cart has three jobs
1) Sit on the DS pins and convert normal DS calls into something it can read from a memory card and feed it back quickly enough to be useful on to the DS. Later on fake this functionality in a more in depth manner (originally they did it all but that is not the way the DS works and so Nintendo made this "deficiency" an anti piracy method- see "below 8000h").
2) Sit on the DS pins and convert normal DS calls concerning save data into something it can make sense of. Unlike just about every other DS game pokemon stuck something extra here (a selector switch leading to a IR port or the normal save stuff- hence the normal save dumping tools doing nothing here). Various methods were employed to sort this out by different flash cart teams.
3) Where conversion fails or it is otherwise beneficial then apply patches, be they automated or designed by the flash cart menu developer, to the binary at runtime. This could be anti piracy, cheats, soft reset and other bonus functionality like savestates, text readers and cheat searching tools.

Flash cart developers took 3) several steps further and made a menu that loaded as the initial game, then redid the game loading procedure with a ROM the user selected (and any additional patches).

To accomplish all this the flash cart developers used many things. Pretty much all DS flash carts use complex programmable chips of either the FPGA or CPLD class of devices. By the way you will have to learn how to program these devices and though they are very nice to their friends (being programmable they can be taught to whatever you like rather than go to the expense of building something or hoping someone else built a chip that does what you need- I am sure you can see why this is invaluable to those wishing to be an electrical engineer*) they are noted for being somewhat picky as to what they call friend.

*you will likely also benefit from some fairly high end electrical engineering skills here and in the project at large.

Your hypothetical device would then do most of that but pass over any requests for the game that did not need to be modified to the original cart and pass things back (rather than just doing the far simpler method of handling the SD card like a normal flash cart), also the same for the IR side of things and probably any saves. This is a fine method if you are trying to develop an initial hack (see the passme and how it worked) or otherwise can not be bothered to spend the time developing a full hack for whatever reason (hack that works one in 20 but with stuff you have there to hack any fool that can operate the copy and paste commands and read a 200 word guide can do is quite a leap). Given all that in the case of the DS is long long in the past it is a lot of pointless work for no gain, not even a nebulous legal one.

That said there is no "homebrew" DS flash card (and I do not believe the R4 makers kit that was being sold on various Chinese underground markets ever leaked), between the woodRPG source, things like http://www.natrium42.com/projects/serial.php and a lot of reading you might be able to get something done though.

On xcode- I am not sure C++ is a suitable language for much of this (you are probably better off with C, especially if you are developing electronics) and xcode is fine I guess but it is not a magical thing and a simple text editor (or more likely one that is slightly more geared for programming- aside from messing around developing for idevices I have no special need to play there so I am not sure what goes on apple stuff) will serve most of your purposes. Similarly if you find yourself programming for nice FPGA/CPLD devices beyond xcode being a glorified text editor at its heart it would probably actually be more difficult to code for your new chips (I doubt the dev tools of your would be chip and xcode speak to each other that well).

Once again though I say give up and get a flash cart: they can do what you need quite happily and ignoring what follows in the next sentence it requires a lot of effort, some fairly rare skills and most likely a considerable expense (if you are having to scrape to find a hard drive then far more than that). If all you want is a pokewalker I still say use cheats instead (question- would you ever shake it to fake the pedometer, if so we have cheats for a reason and if not you lie) but you could probably rip the IR guts out of a copy of the game (or replicate them- they are not that complex from what I have seen) and solder it in; this is where I was heading with the cart selector idea but it is probably dismissed for power reasons if not the possibility of flash carts themselves using the save pins as a comms channel (I do not think this was the case but it is an appealing idea that will have to be investigated further).