NDS Cartridge ROM specs

Discussion of development of software for any "obsolete" computer or video game system.
nocash
Posts: 1365
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: 25
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: 1365
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: 1365
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: 25
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: 1365
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: 1365
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: 331
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.

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

Re: NDS Cartridge ROM specs

Post by nocash » Fri Feb 26, 2021 4:29 pm

I am still working on that, too. I've dumpted the 38600 ROM (in the walk with me cartridge), and now I am currently writing a disassembler for it. The SPI memory access commands can be quite easily spotted when doing some random writes and checking the responses:

Code: Select all

  00,cmd,param...         savedata command with 00h prefix
  01,len,data             infrared rx
  02,data                 infrared tx
  03,msb,lsb,data         cpu write 8bit
  04,msb,lsb,data         cpu read 8bit
  05,msb,lsb,data,data    cpu write 16bit
  06,msb,lsb,data,data    cpu read 16bit
  07                      ?
  08..FF                  ?
The main problem were the crappy SPI transfer timings. Poro had warned me that it works only at max 1MHz transfer clock (probably related to the 3.68MHz CPU clock). And, one must insert a huge delay after each byte (about one thousand ARM7 clocks)... without that delay... it merely looked as if "there might be some pattern" in the returned data... but actually it was just total garbage ; )

I haven't yet tried to dump the ROM in the Activity Meter, but I hope that there is a memory read command (and/or a RAM write command). Did you already find anything like that?

What is the EEPROM? I haven't yet checked if the Activity Meter forgets all data & user IDs upon battery removal, but I thought that the 38602 CPU in the Activity Meter contains only ROM and RAM? Or is there an external EEPROM chip in the Activity Meter?
I am still unsure about the 8pin chip in the Activity Meter... either it's a Accelerometer with fewer pins than usually, or an SPI FLASH/EEPROM chip... but then I don't know which other components could be used as pedometer step sensors.

I am almost sure that chip select for the FLASH chip in the cartridge is active LOW, not active HIGH. And, the FLASH command prefix does use only one 00h byte, not two 00h's.

Checksum... yeah, probably works like so, but probably using SHIFT LEFT (not RIGHT) for the MSBs?

For the newer pedometer version, there's this http://dmitry.gr/?r=05.Projects&proj=28.%20pokewalker webpage with F38606 FLASH ROM disassembly and interesting (but highly confusing) technical description. Going by that, the pedometer is fully reverse engineered, except, still unclear how to read the damn step counters ; )
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

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

Re: NDS Cartridge ROM specs

Post by nocash » Fri Feb 26, 2021 4:45 pm

PS. Here are the component lists, extracted from the Walk with Me cart and Activity Meter (and photos of the pokewalker thing) (plus warning about risk of injury and electrocution from the official booklet).

Code: Select all

Gamecart for Walk with Me/Laufrhythmus
  PCB "DA A-4  IRU01-10" (two layers) plus "IRL01-01 "(brown extra film layer)
  U1 32pin  "S906748-1, SanDisk, 11014-64B, P0A837.00, 0843, NTR-IMWP-1" (ROM)
  U2 32pin  "38600R, A06V, AH00167, 0832" (CPU, ROM 8Kbyte, RAM 0.5KByte)
  U3  5pin  "?" (OR-gate? flipflop?) (for forwarding SPI /CS to FLASH /CS)
  U4  8pin  "45PE80VG, HPAMZ V5, KOR 833X, ST e3" (SPI FLASH 1024 Kbytes)
  U1' 7pin  "5  S.. 9" IR photodiode/phototransistor (on brown film layer)
  X1  6pin  "737Wv"
  R1,R2,RA1 resistors
  C1,C2,C3,C4,C5,C6 capacitors
             .----.
  /FLASH.CS -|    |- GND
             | U3 |- /SPI.CS (from NDS)
      VDD33 -|    |- U2.pinxxx
             '----'

Activity Meter (Actimeter in german) (Nintendo, 2008-2009)
NTR-IMWJ Aruite Wakaru Seikatsu Rhythm (JP)
NTR-IMWE Personal Trainer: Walking (US)
NTR-IMWP Walk with Me (EU) (Laufrhythmus in german)
NTR-IA8P Active Health with Carol Vorderman (EU)
  PCB "NTR-DHC-01" (in water resistant case)
  Ux  32pin Side-A "38602R, F22V, AH04731, 0834" (CPU, ROM 16Kbyte, RAM 1KByte)
  U2  8pin  Side-B "564X, 48H3, 30" (maybe accelerometer? or spi eeprom???)
  U3  7pin  Side-B "1  S.  9" IR photodiode/phototransistor or so
  Ux/Qx     Side-A many small chips with 3-6 pins and few markings
  Xx  3pin  Side-A "CB825"
  Yx  6pin  Side-A ":i] 3.68t"
  C1..C34   Plenty capacitors
  R1..R28   Plenty resistors
  BTI 2pin  Side-B Battery holder (for CR2032 H, 3V)
  Button    Side-A Push button (communication button)
  |<  4pin  Side-A Two color LED
Activity Meter Instruction Booklet, 310 pages: "Do not disassemble or attempt
to repair the Activity Meter yourself. Doing so could result in injury or
electrocution."

P-Walker (Nintendo, 2009)
NTR-IPKx/NTR-IPGx P-letter HeartGold/SoulSilver
TWL-IRBO/TWL-IRAO P-letter Black/White
TWL-IREO/TWL-IRDO P-letter Black/White 2
  PCB "NTR-PHC-01" (with green solder stop & unconventionally black text layer)
  U1  32pin Side-B "F38606, F04V, AK04052, 0942" (CPU,FLASH 48Kbyte,RAM 2KByte)
  U2  4pin  Side-A "?"
  U3  4pin  Side-A "?"
  U4  4pin  Side-A "M_RA"
  U5  7pin  Side-B IR photodiode/phototransistor or so
  U6  8pin  Side-A "Sxxxx, xxxx" (maybe SPI EEPROM?)
  U7  12pin Side-B "043, A939, 021" (accelerometer?) (Bosch BMA150 ?)
  U8  5pin  Side-A "?"
  Q1  6pin  Side-A "Z4"
  D1  3pin  Side-A "?" dual diode or so
  X1  3pin  Side-B "EAJJ"
  Y1  6pin  Side-B "3.68"
  BZ1 2pin  Side-B wires to piezo speaker (aka buzzer)
  CN1 14pin Side-A LCD connector 14pin? or 2x14pin? maybe with/out backlight?
            (with SSD1854 display controller inside of LCD screen)
            (96x64 2-bit greyscale screen) (reportedly with SPI bus)
  BT+/-     Side-B Battery contacts for removeable battery (for CR2032, 3V)
  C1..C29   Plenty capacitors
  R1..R22   Plenty resistors
  SW's      Side-A Three buttons (left, center, right)

Game cartridge for above thing:
Unknown, maybe same/similar as Walk with Me?

Fit Meter (for Wii Fit U) (2013?)
Unknown hardware, case resembles DS walker. Unknown if it supports IR, too. Unknown if it uses a 386xx CPU, too.
One postive thing about the SanDisk ROM: The package is quite small. The ROMs in most other NDS carts are much bigger (and wouldn't have any space for the infrared components).

Btw. I am wondering if there are more NDS cartridges with "whatever special hardware", like built-in sensors etc? For example, these...

Code: Select all

  ROM Chip ID         Maker    Notes
  80h,7Fh,00h,80h NDS SanDisk  128MB ROM (DS Zelda, NTR-AZEP-0)
  80h,FFh,80h,E0h NDS SanDisk? 256MB ROM (Kingdom Hearts - Re-Coded, NTR-BK9P)
  ECh,7Fh,01h,88h NDS Samsung? 128MB NAND+What? (eg. Jam with the Band, UXBP)
The first two have SanDisk ROMs (if they have small packages, too, then that would leave space for extra hardware).
The last one has the 01h in 3rd ID byte (which would usually indicate infrared support, but that game doesn't support IR, or does it?)
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

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

Re: NDS Cartridge ROM specs

Post by Shonumi » Fri Feb 26, 2021 11:01 pm

nocash wrote: The main problem were the crappy SPI transfer timings. Poro had warned me that it works only at max 1MHz transfer clock (probably related to the 3.68MHz CPU clock). And, one must insert a huge delay after each byte (about one thousand ARM7 clocks)... without that delay... it merely looked as if "there might be some pattern" in the returned data... but actually it was just total garbage ; )
It only works with the 1MHz clock? Interesting, I would have not guessed that at all. That probably explains why my attempts to get NDS homebrew to work with the NTR-031 failed. I knew that some kind of gap/delay had to be used, but I was always using the 4MHz clock for SPI transfers... I did manage to get it to acknowledge IR signals, but there was no usable data.
nocash wrote: I hope that there is a memory read command (and/or a RAM write command). Did you already find anything like that?
So far, just one (maybe two??) different EEPROM read commands. I'll have to pick up my research again and start digging this weekend. I'll try to post a log of all the bytes sent from each side. I'm actually using an AGB-006 (GBA infrared adapter) to intercept IR communications between the DS and the pedometer. My GBA flashcart battery is dying, so I'll have to come up with a way of exporting large amounts of data.
nocash wrote: What is the EEPROM? I haven't yet checked if the Activity Meter forgets all data & user IDs upon battery removal, but I thought that the 38602 CPU in the Activity Meter contains only ROM and RAM?
Pretty sure the Activity Meter is very similar to the PokeWalker, so both devices should have EEPROM. It could be some other type of storage on the Activity Meter, but I think it does save data. I believe I've observed the NDS both reading and writing stuff via IR. It's small amounts of user data, as I understand it. I'll have to make a more thorough log of the communications when registering a Mii.

I could be wrong, however. It's an assumption at this point. My investigation so far has been preliminary at best.
nocash wrote: Checksum... yeah, probably works like so, but probably using SHIFT LEFT (not RIGHT) for the MSBs?
Oops! Yes, SHIFT LEFT, not RIGHT. Silly mistake! :oops:

Additionally, I disassembled some of the code the game uses when building a packet to send to the pedometer, and that should be the way it works. Also manually checked some of the result packets from both the pedometer and NDS.
nocash wrote: For the newer pedometer version, there's this http://dmitry.gr/?r=05.Projects&proj=28.%20pokewalker webpage with F38606 FLASH ROM disassembly and interesting (but highly confusing) technical description. Going by that, the pedometer is fully reverse engineered, except, still unclear how to read the damn step counters ; )
Yes, a fascinating article! It's a nice guide that helps understand the Activity Meter in some regards. I've noticed that the Activity Meter shares some similarities as well, such as reading $28 bytes of "unique identity data" that should be specific to each pedometer. It's probably safe to say that many of the commands on the PokeWalker and Activity Meter are the same. However, I suspect some of the command IDs on PokeWalker and Activity Meter will be totally different.
nocash wrote: Btw. I am wondering if there are more NDS cartridges with "whatever special hardware", like built-in sensors etc? For example, these...
Only 2 come to mind. The first would be the Bluetooth stuff in Learn with Pokémon: Typing Adventure / バトル&ゲット!ポケモンタイピング. The second would be the NTR-030 used for 星空ナビ (aka "Starry Sky Navigation" -> NTR-UEIJ-JPN), which has ????? used as an azimuth.

lidnariq
Posts: 10547
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: NDS Cartridge ROM specs

Post by lidnariq » Fri Feb 26, 2021 11:24 pm

Shonumi wrote:
Fri Feb 26, 2021 11:01 pm
NTR-030 used for 星空ナビ (aka "Starry Sky Navigation" -> NTR-UEIJ-JPN), which has ????? used as an azimuth.
At the very least, a 2-axis accelerometer; more likely a full 6-axis "IMU" (meaning +gyroscope) or 9-axis (meaning +magnetometer).

The big sticky-outy flange lends the 9-axis IMU hypothesis some credence (in order to get it away from anything conductive disturbing the earth's magnetic field around the sensor)

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

Re: NDS Cartridge ROM specs

Post by nocash » Mon Mar 01, 2021 12:11 am

Here's the disassembly for the 38600 chip from "Walk with Me" cart, attached below. Some findings...
  • Command 07h returns the number of written SPI bytes (maybe it was intended to return remaining infrared TX bytes, but it doesn't do so)
  • Command 08h..FFh are simply ignored (the chip keeps awaiting a command to be transferred in next SPI byte)
  • Infrared TX packets starting with F2h (aka encrypted 58h when using XOR AAh) are refused to be sent.
  • Infrared RX/TX is limited to max 84h bytes, there seems to be no support for "streaming" longer packets (by appending more data during transfer)
  • One could upload custom code to unused memory, then change one of the 16bit callbacks, that would allow to overcome the above Infrared restrictions
  • The chip is badged 38600R, but has twice as much ROM/RAM as specified in the datasheet (ie. it seems to be a rebadged 38602R or even F38602) (the extra memory isn't used by the software)
Checksum for "Walk with Me": ROM CRC32=58051390 for 2000h-byte official ROM size (or CRC32=64B40D8D for 4000h-byte whole ROM size).
Does somebody have other Infrared NDS cartridges and can check if they do contain the same ROM?
I can make a "download ROM and do CRC check tool" if needed.

Well, and next would be trying to dump the Activity Meter ROM.

PS. thanks for the info about the Bluetooth and Sky Navigator carts!
Attachments
3860X.txt
(53.1 KiB) Downloaded 45 times
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

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

Re: NDS Cartridge ROM specs

Post by Shonumi » Mon Mar 01, 2021 1:50 am

nocash wrote:
Mon Mar 01, 2021 12:11 am
Infrared RX/TX is limited to max 84h bytes, there seems to be no support for "streaming" longer packets (by appending more data during transfer)
It should be noted that all supported software performs a length check as well. If something went wrong and somehow more than 84h bytes are returned via SPI, they'll ignore the packet as invalid. The 84h limit effectively means you can have a packet consisting of a 4 byte header, and 80h bytes of additional parameters/packet data.

I have a log of all the bytes sent from the Activity Meter to the NDS during the initial player registration of Walk with Me. I've annotated it a bit. I'm still working on getting a proper log for the other side (what the NDS sends to the Activity Meter). I still don't have a decent method of exporting data from my GBA flashcart, so I have to transcribe all of these by hand for the time being.

Some of the 22h commands might actually be reading from RAM. I'm fairly certain 0Ah is for reading EEPROM, since that's where the 28h byte "unique ID" data is supposed to be stored on the PokeWalker, so likely the same for the Activity Meter. The "unique ID" does indeed vary between different pedometers. At least, the two I have gave me two distinct IDs. It looks like parts are supposed to be written or changed. At least 1 byte (a flag of some sort) was observed to change after player registration. There are a couple of responses towards the end of registration that look like acknowledgements. These seem to be when the NDS sends write commands, if I had to guess.

Let me know if any of this is actually useful. I've been focusing on the infrared protocol more than the actual cartridge stuff, so I wouldn't want to clutter this thread with irrelevant details.
Attachments
LOG_A2.TXT
(5.45 KiB) Downloaded 38 times

Post Reply