It is important for all of us to remember that this Flash kit world we all love could come crumbling down rather quickly. All it takes is a few smart coders to understand exactly what they need to do in order to slip in a small security device.
We have no proof right now that this was an attempt to fool flash kits but understanding how the Micro SD, Flash kits, and the auto patching functions work, it appears that it was deliberate.
For those of you that don’t understand this here are the basics. Currently manufactured Micro SD cards can seek and distribute data at 12 micoseconds. The NDS already has a feature that randomly requests data from the game cart in 4 microsecond intervals. If the data can not be spit back in the time limit the game will not function. This check is completely random and can be implemented in the code of the game cart. The different Flash kit manufacturers have combated this issue by integrating on-the-fly patching into their various firmwares. When the NDS queries the cart for the data, the firmware simply spoofs the data and in most cases spits back garbage. This allows the game to go on playing because as far as the NDS is concerned the “real” cart spit back a response in time, so it can’t be a ROM. It appears that the smart coders over at Square are checking to make sure the data is actually correct. So when the firmware spits back garbage the game fails and we are presented with the now famous “thank you for playing” screen.
It is my understanding that the CycloDS can run ROMs in a clean mode that does not require any patching. While I have not researched how this might be possible the better solution is that the “no patching” method is actually a *smarter* patching algorithm. There is no way that data can be pulled off of the current Micro SD cards at a faster rate. One has to assume that some type of smart patching is buffering data or perhaps storing chunks of data into memory, RAM or something of the like.
The fix for this problem, if indeed this is a new security check, would be to include onboard RAM per Flash kit, the size of the maximum reported ROM. This way the entire clean ROM could be loaded into RAM and run as though it was on a retail cart. Thus the NDS could query all it wanted and receive the correct data off of a much faster RAM solution. Again this is not perfect and would probably require firmware and software emulation to spoof the NDS as the RAM read speed is more like 8 microseconds.
A great bit of homebrew was released to see if your Slot1 is auto patching. The important thing about this homebrew is the conversation and information the original thread spawned. The coder has some great insight and I recommend it as a read for those trying to wrap their heads around the FFCC issue.
Code:
http://gbatemp.net/index.php?showtopic=42742
Now let us all stop fighting over the speculation of why this ROM does not play, what flash kits it plays on, and why it does so. Let us instead hope that this “security” feature is not sold and bundled with more games. Because if it is then the next generation of Slot1 Flash kits (which will no doubt have to include some type of internal storage) will most likely be very expensive!
*cheers*
-AW
@
Quincy:
@
K3Nv2:
@
BigOnYa:
