GBAtek is very inaccurate in regards to the "ROM chip ID/card ID."
It is mostly correct on the format of the ID, which goes as follows:
Card ID: xxxxssmm
- mm - Manufacturer ID (0x80 - Matrix Memory, 0xAE = OKI Semiconductor, 0xC2 = Macronix)
- ss - Chip size in megabytes minus 1 (eg. 0Fh = 16MB)
- xxxx - ID bit flags:
- Bit-0: Unknown (See: The Legend of Zelda: Spirit Tracks)
- Bit-13: Unknown (See: Dementium II, The Legend of Zelda: Spirit Tracks)
- Bit-14: Unknown (See: Dementium II, Foto Showdown, My Healthy Cooking Coach, System Flaw, The Legend of Zelda: Spirit Tracks)
- Bit-15: ROM speed select (0 = fastrom, 1 = slowrom)
Some additional notes on the the ID:
- The Manufacturer ID is defined by JEDEC. According to the standard, 0x80 is an invalid MFR. ID. However, I have a number of cards which claim exactly that. According to this awesome site, the SlowROM chip used in "Akachan wa Doko Kara Kuru no?" is manufactured by Matrix Memory.
- The only card I've seen that reports an MFR. ID of 0xAE is Dementium II. It's listed as OKI Semiconductor by the JEDEC standard, but I haven't been able to verify that. The SlowROM chip used in Dementium II is unmarked.
- Bit-14 almost looks like a DSi-mode flag. Except that Dementium II and Spirit Tracks also has it set, and neither game supports DSi-mode.
- The ROM speed select offers two capabilities, which I've dubbed "fastrom" and "slowrom"; see below.
GBAtek fails to mention all
of the following facts:
- FastROM cards are, well, pretty fast! They can be clocked at (or above!) 6.7 MHz. SlowROM cards can only operate stably at (or below) 4.2 MHz.
- SlowROM cards are "self-clocking".
- SlowROM cards *require* the timeout period specified in the ROM Header (which is a 2-byte value at offset 0x6E) in order to complete their self-clocking operation. FastROM cards don't care about the timeout.
- SlowROM cards require a slightly modified protocol to operate during the "TRM" phase; see below.
- SlowROM cards have a maximum read size of 512-bytes (0.5 KB). FastROM cards typically have a maximum read size of 4,096-bytes (4 KB). The NDS itself has a read size limit of 16,384-bytes (16 KB).
The "modified" protocol goes something like this:
- The TRM bit is not set.
- The blowfish-encrypted command is first committed to the card without reading any data back.
- Wait for the timeout period.
- The same blowfish-encrypted command is sent again, this time reading data back.
Pretty much every blowfish-encrypted command is handled in a manner similar to that described above on SlowROM cards. TRM is never enabled, meaning the card is not clocked to advance the blowfish state machine; the card does its own internal clocking during the timeout period. After the timeout lapses, the same command is sent again (I'll refer to these "duplicate" commands as dummy commands) but this time, it will actually read back the requested data (if any).
The secure-area bank reads are peculiar, since each secure-area bank is 4 KB in size (and SlowROM cards can only output 0.5 KB at a time). With FastROM cards, it's no problem: Just request which bank you want to read, and read the whole thing. But with SlowROM cards, after the command is committed and the timeout lapses, 8 dummy commands are sent, each reading back 512-bytes. (Remember, each dummy command is exactly the same as the committed command. There is no timeout wait for dummy commands; only after a command is committed.) SlowROM cards not only do their own internal clocking of the blowfish state machine, but they also advance an internal address pointer on their own after reading secure-area banks.
This is something that I mentioned about three years ago
but never truly analyzed until now.
Now you can see how far off GBAtek is on this matter:
2bbbbiiijjjkkkkkh (19B8h) - Get Secure Area Block
KEY1 encrypted command. Used to read a secure area block (bbbb in range 0004h..0007h for addr 4000h..7000h), each block is 4K, so it requires four Get Secure Area commands to receive the whole Secure Area (ROM locations 4000h-7FFFh), the BIOS is reading these blocks in random order.
Normally (if the upper bit of the Chip ID is set): Returns 910h dummy bytes, followed by 200h KEY2 encrypted Secure Area bytes, followed by 18h KEY2 encrypted 00h bytes, then the next 200h KEY2 encrypted Secure Area bytes, again followed by 18h KEY2 encrypted 00h bytes, and so on. That stream is repeated every 10C0h bytes (8x200h data bytes, plus 8x18h zero bytes).
Alternately (if the upper bit of the Chip ID is zero): Returns 910h dummy bytes, followed by 1000h KEY2 encrypted Secure Area bytes, presumably followed by 18h bytes, too.
Aside from above KEY2 encryption (which is done by hardware), the first 2K of the Secure Area is additionally KEY1 encrypted (which must be resolved after transfer by software).
The first inaccuracy in this quote (which is only one of *two* mentions of the ROM speed bit in the card ID. The other mention just says, "4th byte - Bit7: Secure Area Block transfer mode (8x200h or 1000h)" ... hardly enough information to properly handle a SlowROM card) is that "the upper bit of the Chip ID set" is "Normal"! For the record, no, it is not normal. SlowROM cards are the exception; FastROM cards are far more common.
Second, it goes on to explain the normal protocol, while claiming it's what happens when "the upper bit of the Chip ID set".
Third, the "alternate" protocol is just plain wrong; it never reads a full 4 KB bank in one go.
Fourth, it "presumes" the mythical 4 KB read is "followed by 18h bytes, too". This is bad information because the data is never followed
by "18h bytes". In fact, those dummy bytes precede
the data. And the number of dummy bytes is specified by the L2 parameter of the card control flags.
Fifth, 'bbbb' can be in the range 0004 - FFFF. It's not really useful to use secure-area reads on banks outside of the secure-area, because they are slower than normal reads (it takes a lot of time to clock the blowfish state machine). But it is possible! Reading a bank lower than 4 will read (bank + 8). For example, attempting to read bank 1 will return data for bank 9. Reading a bank number above the upper boundary of the ROM will read from bank 8.
Sixth, because the protocol for SlowROM cards is so different, it takes a great deal more than just "four Get Secure Area commands to receive the whole Secure Area (ROM locations 4000h-7FFFh)". It actually takes: (1 commit command + 8 dummy commands) * 4 banks = 36 commands.
I think that about covers it, for now.