NDS Cartridge ROM specs

Discussion of development of software for any "obsolete" computer or video game system.
Post Reply
nocash
Posts: 1316
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

NDS Cartridge ROM specs

Post by nocash » Sun Nov 01, 2020 9:00 pm

What should be updated/clarified about NDS Cartridges in gbatek?

Some things are mentioned in this GBAtek addendum/errata: http://melonds.kuribo64.net/board/thread.php?id=13 - some of the ROM Transfer stuff is already updated in more recent gbatek versions (Arisotura, can you update the addendum/errata page, and mark topics as "Done"?)

For some details I am unsure if they are already clarified enough (is it required to mention that DRQ goes off after data reading? I can add some extra decription if the current description isn't clear enough).

The biggest unknown to me is the "WR" bit, it's presumably used for "Writing" data to flashcards (?) but I have no idea how it might work.
To start with, data reads are done via port 4100010h, but ports at 41xxxxxh are usually read-only... so writing is probably done using a different data register?

Gbatek does currently describe cartheader/timing values for "MROM" and "1T-ROM", but I do own only a handful carts/romimages.
People with bigger collections might know more different cartheader/timing values (in carthdr[60h], [64h], [6Eh])?
Retail games with writeable "NAND" are probably also having special timings for reading (and perhaps more special timings for writing)?

Some of the cartheader/timing values are apparently wrong (eg. those in SystemFlaw and BiggestLoser) so it might be better to use the ROM ChipID for timing detection (not really sure which bits to look at though).
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

Arisotura
Posts: 20
Joined: Sun May 19, 2019 7:01 am

Re: NDS Cartridge ROM specs

Post by Arisotura » Mon Nov 02, 2020 6:21 am

re: writing to cartridge.

I haven't researched it intensively, but I know that carts with NAND do use specific commands to write to the NAND, and transfer the data by writing to 0x04100010. flashcarts likely work similarly, too.

the WR bit doesn't seem to enforce a read/write direction, I know of some demos that set it for reading data. however, setting the WR bit suppresses the KEY1 delays.


re: the notes on the melonDS board. I'll look into it. some of it was also my own notes as I researched details of how transfers work.

nocash
Posts: 1316
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NDS Cartridge ROM specs

Post by nocash » Mon Nov 02, 2020 7:03 am

Are that official demos or homebrew demos with WR bit set for reading?

If WR can be set for reading... I don't know what distinguishes between reading and writing...
For reading, the hardware would transfer some bytes, and then set the DRQ flag, for passing on the data to CPU.
For writing, it should be vice-versa, the DRQ flag being set first, to request data from CPU.
Hmmmm, or unless writes are somehow done by writing the 1st data word before starting the transfer.

Does anybody have source code for writing to flashcarts or NAND carts?

About disabling delays/gaps: ROMCTRL.bit28 seems to do something like that, too. But I think that it doesn't really disable the delay (it just prevents CLK pulses being output during the delay).
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

nocash
Posts: 1316
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NDS Cartridge ROM specs

Post by nocash » Tue Dec 15, 2020 4:32 am

I've got told about "Pokemon Mystery Dungeon: Explorers of Sky... the game's odd savetype is a 128K EEPROM".

- It's a NDS game, right? Or GBA game?
- The size is 128Kbyte? Or 128Kbit?
- What is needed to detect/handle that chip type in emulation?
- What is the chip page size?
- What is the chip part number on the PCB?
- What is the chip ID value, when reading ID or Status regs?

I hope the first 3-4 questions can be solved (or are already solved by other emulators? The other details would be neat for gbatek.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

Arisotura
Posts: 20
Joined: Sun May 19, 2019 7:01 am

Re: NDS Cartridge ROM specs

Post by Arisotura » Tue Dec 15, 2020 6:34 am

it's a DS game. the save memory size is 128 kilobytes. the comm protocol is the same as for smaller EEPROMs, except with 3 address bytes instead of 2. I'm not sure about other details, I don't have a cartridge handy.

re: the WR bit. I know of a demo that sets it, but no official software.

assemblyx69
Posts: 4
Joined: Wed Oct 02, 2019 12:50 am

Re: NDS Cartridge ROM specs

Post by assemblyx69 » Fri Jan 22, 2021 11:13 am

Technical Documentation Mystery Dungeon NDS

https://projectpokemon.org/home/docs/my ... cture-r62/

nocash
Posts: 1316
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NDS Cartridge ROM specs

Post by nocash » Fri Feb 19, 2021 9:12 pm

I've got a "Walk with Me" cartridge - mostly because I was interested in the built-in infrared port & external pedometer - however, the SanDisk ROM chip is also pretty weird:

The 4th byte of the ROM's chip_id has bit6 set. That was believed to indicate a DSi cartridge. But, this is a NDS game (with cart.hdr unitcode=00h, and ROM reads via command B7h are returning garbage when trying to unlock DSi mode via command 3Dh).

The 3rd byte of the ROM's chip_id has bit0 set. That was believed to indicate presence of the IR port, which might be actually true, except that the IR port is wired to the SPI bus, not to the ROM chip.

Reading ROM data via command B7h does usually allow to read up to 1000h bytes. But with that SanDisk chip, I can only read max 200h bytes at once, reading 400h or more seems to fail. Is that a known problem? And is there a workaround?
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

nocash
Posts: 1316
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: NDS Cartridge ROM specs

Post by nocash » Sat Feb 20, 2021 10:27 pm

I've dumped the SanDisk ROM in Walk with Me. It's doing some uncommon things:
  • reads are forcefully 200h-byte aligned
  • attempts to read more than 200h bytes is padded with unencrypted FFh bytes
And, it's one of those super-slow cheap new ROMs. That chips could be more or less reasonably fast when reading large 1000h-byte blocks, but apparently SanDisk doesn't support that at all. This might be the most unfortunate slow ROM chip ever used in NDS/DSi carts. Well, anyways, I'll add a "slow-loading" feature for loading such ROMs in unlaunch.

And, here's the ROM pinout.

Code: Select all

SanDisk ROM (Walk with Me)
  1  GND
  2  GND
  3  NC?
  4  GND
  5  VDD33
  6  /ROM.CS
  7  GND
  8  VDD33
  9  GND
  10 GND
  11 GND
  12 GND
  13 GND
  14 CLK
  15 GND
  16 /RESET
  ---
  17 GND
  18 GND
  19 GND
  20 D0
  21 D1
  22 D2
  23 D3
  24 GND
  25 GND
  26 VDD33
  27 D4
  28 D5
  29 D6
  30 D7
  31 VDD33
  32 GND
There is no connection to the infrared hardware at all. Hmmm, but why's there that "Infrared flag" in the ROM chip_id...
  • to remind the factory that the chip requires a PCB with IR hardware? might be better to flag that in cart_header though
  • one of the VDD33 solder pads does set the chip_id flag when installing the ROM on a PCB with IR?
  • that flag isn't IR related at all? it's set in all IR games (but also in Jam with the Band, which has no IR hardware, as far as known)
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

Shonumi
Posts: 322
Joined: Sun Jan 26, 2014 9:31 am

Re: NDS Cartridge ROM specs

Post by Shonumi » Mon Feb 22, 2021 1:11 am

I can't help with the SanDisk ROM, but I have done some research on the NTR-031 (NDS IR cartridge), and the NTR-027 (the NDS pedometer aka Activity Meter). My notes were previously unorganized, but after reading this post, I figured they might be useful to you. I've compiled most of what I've found out last year. Hopefully it helps.

Code: Select all

***************************************************
A. SPI Protocol
***************************************************

All infrared communications on the NTR-031 happen via auxiliary SPI (AUXSPI). The NTR-031 can issue dedicated infrared commands or regular commands typically associated with cartridge backup. Game backup commands are so-called "Zero Commands", in that they may appear as if they are sending the cartridge backup command 0x00. The format of the "Zero Command" looks like this:

-------------------------------------------------
SPI Data		| CS
-------------------------------------------------
0x00			| LOW
0x00			| HIGH
Cart Command Byte	| HIGH
Cart Command Parameters	| HIGH
-------------------------------------------------

When CS is clocked LOW, then clocked HIGH, this typically signals the start of a new command byte via SPI. Ordinarily, the command sent here should be 0x00. On the NTR-031, however, the 0x00 byte is ignored, and the next byte becomes the backup command. IR commands, in contrast, follow the expected format that backup commands are supposed to use:

-------------------------------------------------
SPI Data		| CS
-------------------------------------------------
0x00			| LOW
IR Command Byte		| HIGH
IR Command Parameters	| HIGH
-------------------------------------------------

There are 2 IR commands that the NTR-031 uses to communicate with the NTR-027.

-------------------------------------------------
Command 0x01 - Receive IR Data
-------------------------------------------------
Byte 0x01 		| Length of IR data
Bytes 0x02...		| IR Data Packet
-------------------------------------------------

-------------------------------------------------
Command 0x02 - Send IR Data
-------------------------------------------------
Bytes 0x01... 		| IR Data Packet
-------------------------------------------------

If the NTR-031 returns a length of zero for the 0x01 command, this indicates that no IR communication took place. 

***************************************************
B. Infrared Protocol
***************************************************

The NTR-031 communicates with the NTR-027 using serial IR 8n1. Its infrared protocol is very similar to the NTR-PHC-01 (aka PokeWalker), albeit with several changes to make sure each device does not interfere with the operation of the other. Data is sent in packets between the NTR-027 and NTR-031. The NTR-031 automatically converts the serial stream of IR pulses into individual bytes, so the NDS need only concern itself with handling data via the IR commands. The packet format is described below:

-------------------------------------------------
IR Packet Format
-------------------------------------------------
Byte 0x00		| Packet ID
Byte 0x01		| Packet Parameter
Byte 0x02		| Checksum LSB
Byte 0x03		| Checksum MSB
Bytes 0x04...		| Packet Data
-------------------------------------------------

The Packet ID determines what kind of command should be processed. The Packet Parameter is often auxiliary data used to keep track of overall communications. For example, the NDS may use a starting seed value, and whenever it or the NTR-027 sends data, this seed is incremented by one.

The checksum is a 16-bit value of all data bytes in the packet. It is calculated as such with the following psuedo code:

SUM = 0
X = 0

WHILE X < SIZE_OF_DATA
	IF X AND 0x01
		SUM += DATA[X]
	ELSE
		SUM += (DATA[X] SHIFT RIGHT 8)
	X += 1

Before sending a packet, and after receiving a packet, ALL bytes after the Packet ID must be XOR'ed with the value 0xAA. For most packets, when one side sends a command, an echo packet is expected. This echo packet uses the same Packet ID, but the Packet Data is expected to match whatever command it is responding to. Naturally the Packet Parameter should be updated if used as tracking byte for IR communication.

Generally speaking, the sessions between the NDS and NTR-027 look something like this:

1) NDS waits for NTR-027 to send IR ping
2) NDS sends handshake (Command 0xFA)
3) NTR-027 sends handshake (Command 0xF8)
4) NDS requests various reads/writes for the NTR-027's EEPROM
5) NDS closes the session (Command 0xF4) 	

***************************************************
C. Packets
***************************************************

-----------------------------------------------
Command Packet 0x0A - EEPROM Read #1
-----------------------------------------------
Byte 0x00		| 0x0A
Byte 0x01		| Packet Parameter
Byte 0x02		| Checksum LSB
Byte 0x03		| Checksum MSB
Byte 0x04		| EEPROM address MSB
Byte 0x05		| EEPROM address LSB
Byte 0x06		| Length of bytes to read
-----------------------------------------------

Sent from the NDS. Reads from EEPROM via 16-bit addresses. The NTR-027 should reply with an echo packet. The Packet Data is the requested EEPROM data of the specified length. It is unclear how this differs from the 0x22 command.




-----------------------------------------------
Command Packet 0x22 - EEPROM Read #2
-----------------------------------------------
Byte 0x00		| 0x0A
Byte 0x01		| Packet Parameter
Byte 0x02		| Checksum LSB
Byte 0x03		| Checksum MSB
Byte 0x04		| EEPROM address MSB
Byte 0x05		| EEPROM address LSB
Byte 0x06		| Length of bytes to read
-----------------------------------------------

Sent from the NDS. Reads from EEPROM via 16-bit addresses. The NTR-027 should reply with an echo packet. The Packet Data is the requested EEPROM data of the specified length. It is unclear how this differs from the 0x0A command.




-----------------------------------------------
Command Packet 0xF4 - Disconnect
-----------------------------------------------
Byte 0x00		| 0xF4
Byte 0x01		| 0x00
Byte 0x02		| 0x00
Byte 0x03		| 0xF4
-----------------------------------------------

Terminates an active IR session. This is often sent from the NDS after all data has been transferred for a given task, such as completing the initial player registration. It is also issued by the NDS if there are any errors in IR communication. It has a data payload of zero bytes, and since the Packet Parameter does not change, this packet is "hardcoded" to 4 specific bytes. No response is expected.




-----------------------------------------------
Command Packet 0xF8 - NTR-027 Handshake
-----------------------------------------------
Byte 0x00		| 0xF8
Byte 0x01		| 0x00
Byte 0x02		| 0x00
Byte 0x03		| 0xF8
-----------------------------------------------

Sent by the NTR-027 after receiving a 0xFA command. It has a data payload of zero bytes, and since the Packet Parameter does not change, this packet is "hardcoded" to 4 specific bytes.




-----------------------------------------------
Command Packet 0xFA - NDS Handshake
-----------------------------------------------
Byte 0x00		| 0xFA
Byte 0x01		| 0xBB
Byte 0x02		| 0xBB
Byte 0x03		| 0xFA
-----------------------------------------------

Sent by the NDS after receiving a 0xFC command. It has a data payload of zero bytes, and since the Packet Parameter does not change, this packet is "hardcoded" to 4 specific bytes. The NTR-027 is expected to reply with the 0xF8 command.




-----------------------------------------------
Command Packet 0xFC - IR Ping
-----------------------------------------------
Byte 0x00		| 0xFC
-----------------------------------------------

The very first command sent, and used to establish a connection. This command does not use checksums or parameter bytes, and it has a data payload of zero bytes. Generally sent from the NTR-027 to the NTR-031, as the pedometer initiates communications once the player presses the button. The NDS is expected to respond with the 0xFA command.
This much at least is enough to get somewhere when attempting to emulate the NTR-027 for Walk With Me or Active Health (the only other NDS game that uses the pedometer). I stopped research after I hit a brick wall in emulation. Something about my implementation must be off, as I get communication errors in Walk With Me when finalizing the player registration.

Anyway, the above documentation is very WIP. I have a hardware setup that can intercept all IR transfers from both sides (the NDS and the pedometer) but I haven't finished investigating the protocol or stuff like some of the EEPROM values. I intend to pick it up again soon, so let me know if there's any information I can contribute.

Post Reply