r4isdhc: resupport old type

[d3m3vilurr]

Related #95

if console platform already on the KEY2 state, original code no more detects old type carts. it'll make problem at the injection timing

AFAIK, 0x68 command only can support newer flashcart, but 0x66 command can support both type carts.

so we should check supporting result before checking the 0x66.

[angelsl]

I just tested this and it seems 0x68 in KEY2 mode only works on DSi. If you force the 3DS to init to KEY2 and then try 0x68, it fails. I can only guess that this is because the DSi is peculiar in the sense that it is in KEY2, but the flashcart has already been initialised beforehand (by the kernel).

In other words:

• 0x68 in KEY2 from clean init fails
• 0x68 in KEY2 taken over from the flashcart kernel works

I am inclined to have another platform configuration stating if we assumed control from the flashcart kernel, but I think you won't like that, and I know that such a flag is only going to matter in this very specific case of cannot-reset and launched-from-flashcart-kernel.

So, in summary this change won't affect platforms that can reset at all; it makes DSi try to detect new carts and fallback on old cart, instead of just going with new cart all the time, but this only works on DSi, and not in the general case of a platform starting in KEY2 but cannot reset — such a platform will always end up detecting an old cart.

It doesn't really change any functionality in the end (it was never a problem to treat an old card as a new one — see below) so I'm OK to merge this.

Please see my comments. I will merge once they are resolved.

Thanks.

---

The only difference between the new and old carts (type 1 and type 2, as you call it) is that the new cart supports 0x68 in RAW, so we can skip the whole encryption dance if we are in RAW, and that the new carts have a ROM => NOR map in the NOR (the old cart's map is probably in the FPGA). Flashing commands are identical.

I know for a fact that writing the ROM map in the old cart does not affect its operation, because that part of the header is unused. That is why I was fine with not detecting old carts in DSi mode. On the other hand, writing the ROM map in the new cart is also optional (it just affords us a slightly larger payload size limit).

If you are concerned about writing the ROM map in the old cart, then we can simply choose to only write it if we init by 0x68 (meaning we don't write it even for a new cart if we init by 0x66).

[d3m3vilurr]

0x68 work is totally same in RAW state, and yes it just adding fallback code for detection old card.

if really not exist any issue about the old card regard to newer one, we can remove old_cart flag on the codeset. and it'll be cleaner. but original code set (and current also same), use this flag at the injection. so I thought, this flag can make trouble on the old card.

anyway this pr is truly checked in my issue and all users just passed at the step1(0x68 command) not the step2, (but yea, I'm not tested with this codebase, so I could make the mistake something) so actually not tested with 0x66 command. (I guess, you tested about that anyway)

[angelsl]

0x68 work is totally same in RAW state

Only because the DSi flasher starts from the flashcart's own kernel — it won't work if you reset the cart, bring it into KEY2, and send 0x68.

Of course this doesn't affect any device we know of right now, but ..