Hm, I can't really find any simmilar chips between the GC and the Nitro units. Got a tip which chips do the video out?

The Gamecube actually supported RGB in europe. So it might actually have that depending on the type of GC chips they used.
_________________________
GitHub - Kuribo64 - YouTube

Yeah, all N64s and NTSC GCs have Composite/S-Video only.
_________________________
GitHub - Kuribo64 - YouTube

Hmm, I wonder why they used a non RGB VC? Like Gericom said they could've used a European chip.

I doubt it was for cost.

No one would probably use it anyways.

Considering all prior consoles in the regions where the Nitro units were disributed from (NOA/NOJ) did not support RGB it was a logical step for them to use the video chips form these regions I assume. Also RGB was never an established standard in the US.

Also yeah, did some more research and it'S confirmed that they do Composite and S-Video only.
_________________________
GitHub - Kuribo64 - YouTube

True, didn't think about the framerate.

I've done more testing about writing commercial ROMs to gamecards, because I could only get it to work when changing the game code to "NTRJ, which seemed weird to me.

There's some interesting info in this thread (needs login, PDF)

To summarize:
- There is extra "encryption data" in the ROM region at 0x0200 - 0x3fff.
- Cards don't allow you to read out the encryption data, so this region is zerofilled in commercial ROM dumps.
- Cards NEED the encryption data to encrypt communications.

This encryption data is calculated from the game's code with Nintendo's Secret Algorithm that game developers didn't have access to. To allow devs to write their games during development, the is-nitro-debugger software has the security data for NTRJ game code embedded, and silently writes it for you when you write a NTRJ game to a card. THIS is why it worked only with NTRJ game code.

ndstool does have the algorithm to generate the encryption data! But it still doesn't work, why? Turns out ndstool has a bug, it writes some of the data to the wrong offset.

The bug is that it writes the "sbox data" to 0x2800 instead of 0x1c00. Note that the sbox data is 0x1000 bytes long, so ndstool is afterwards overwriting half of it when writing the test data at 0x3000. Due to that, encrypting with the current ndstool, then using an hex editor to move the data from 0x2800 to 0x1c00 is not going to work! You need to compile ndstool from source with the fix.

I sent a pull request. With that fix, encrypting and writing a ROM gives you a working flash game card!

Yay!

IS-NITRO-WRITER Teardown!

Top, with 8 DS slots.


Side, with power, DIP switches, USB.


Bottom, with serial sticker and option sticker. The "BACKUP" option allows you to write (or read?) the game card backup memory too (for game saves).


Taking out the cover reveals the structure: there are 4 boards with 2 slots each, plugged into a "main board".


Removing the 4 slot boards shows the connector board, with some huge heatsinks.


It can be unscrewed and taken out, revealing a NEC v850 CPU board.


The bottom of the case is just the 5 stand off screws soldered.


NEC V850 cpu board up close. It looks VERY similar to the one in the IS-NITRO-EMULATOR. Probably same design with different layout. Also interesting is it has space for another of these white huge connectors, unpopulated.


Slot adapter board. FPGAs and some RAM?


And finally, the slot boards. They have these black wires for grounding soldered into the slots' covers, that go to the grounding pin at the back of the case.

From what I understand, the DS encryption generates some data tables from the gamecode, then uses them to encrypt/decrypt commands. This data is what's in the rom at 0x1600 and 0x1c00.

You can see the details at gbatek key1 encryption details. This data is called "keybuf" there.

I can think of 2 reasons they did it this way.

1: efficiency. This way the card doesn't need to calculate the table, and doesn't need temporal ram to store it. Why require extra ram if the data never changes, and you have plenty of rom storage already?

2: more security: By doing it this way, deva never needed to encrypt/decrypt anything in their machines, so Nintendo's tools didn't need to have code for that, protecting it from getting reverse engineered.

Nintendo would assign the gamecode to the game, then give the deva the encryption data for that gamecode and the first 0x800 bytes of the secure area, already encrypted for the gamecode too (what they call the "syscall library").

Also interesting is that doing it this way didn't give devs info useful to pirate/dump other games than their own.

Yeah, the arm7 bios has the algorithm and the key data, this is how the DS was originally cracked.

Do you know exactly how much on-board RAM is there? It would be interesting to know how much they had.

Since it's RAM, this means if their game is in memory, and say a power surge were to happen, all memory would be lost, correct?,

It looks like you've discovered all this too =)

An implication of this discovery is that it implies that almost all DS cartridge dumps are bad. The rare exceptions are Contra 4 prototype (as you discovered) and Virtual Console titles. Retail carts have the game-specific Blowfish tables at 1600-1647 and 1C00-2BFF, but there is no known way to dump them. Attempting to read this area on cartridges will just return mirrors of other parts of the ROM. Both retail and dev DS carts have this behavior.

We can't simply regenerate the data. While 1600-1647 and 1C00-2BFF are algorithmically generated, 1000-15FF, 1648-1BFF and 2C00-2FFF appear random with no known source. If you corrupt these seemingly unused areas of a cartridge and flash it to a dev cartridge, the dev cartridge still works. The random garbage might be chaff to make it less likely that hackers found it. But the annoying part is that it means we can't simply generate this data and attach it to existing dumps.

However, a ray of hope exists: if you flash a cartridge with corrupted unused data, it will work fine, but if you then ask the IS-NITRO-EMULATOR (etc.) to verify the dump, it will say that the flash is bad. Try again with the hacked image and it will say that it's correct. In other words, something is able to read the security data.

This is not visible in the USB communication with the IS devices. Whatever is happening has to be on the device's side. I don't have the electronics know-how to set up a logic analyzer on the cartridge protocol bus to see what's involved with verifying.

It's quite possible that only dev cartridges respond to whatever the IS devices are sending. But this is a ray of hope for correct dumps.

One more thing I should mention: DSi-enhanced games have a second security data block, before the second secure area. The data that the IS dev software burns to DSi flash carts for NTRJ does not have the Blowfish tables - something on the cartridge or IS device must be munging it. The actual format is the same, relative to the beginning of that area: Blowfish tables at +0600-+0647 and +0C00-+1BFF and byte pattern at +2000-+2FFF. The Blowfish tables are generated slightly differently, but GodMode9 has the correct algorithm.

Is it that important if that data is entirely 100% useless though?


Very interesting. Maybe Gericom's REing of the nitroemu firmware can shed some light in this too? I'd be very very interesting to see how the dev card protocol works, for flashing, erasing and verifying. Maybe it's possible to program them from regular DS's if it's just special commands (as opposed to special voltages or weird stuff?)


This is what I fear too, yup. It's very likely, otherwise it'd probably mean you can use that to break encryption...