NDS Cartridge ROM specs

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

Re: NDS Cartridge ROM specs

Post by nocash » Mon Mar 01, 2021 3:53 am

Yes, that's interesting, keep posting! The log is nice, although, it's only the replies, without the commands (and without the 16bit read addresses from tne red commnds).

Command 0Ah is a generic memory read (command 22h probably too).. It returns 16K ROM at 0000h-3FFFh, the ROM is also mirrored at 4000h-7FFFh. When reading more data, it does somehow hang at B5xxh (EDIT: That was due to checksum error, when command chksum exceeds 16bit FFFFh range). Yet higher addresses can probably read from RAM, which is battery backed, and that makes me doubt that there is any EEPROM in there - unless they wanted to store an ID or other data that survives battery changing, but what would that be good for?

I have originally tried reading 80h bytes (plus 4 byte header), but that did hang after the first read command (maybe because the reply length byte is also counted, so it would be 85h bytes total. I have now changed it to read only 40h bytes at once, and ROM dumping worked fine with that. I'll start to disassemble it later today... it's a good bit bigger than the ROM in the cartridge.
Last edited by nocash on Mon Mar 01, 2021 11:22 am, edited 1 time in total.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

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

Re: NDS Cartridge ROM specs

Post by nocash » Mon Mar 01, 2021 10:43 am

Hmmm, the ROM is vandalizing the SPI bus with insane/unrolled functions for accessing an EEPROM. Yeah, okay, right, there is really an EEPROM in there. It's using the usual WREN, RD, WR, RDSR commands, the 8pin chip with marking "564X" is probably something alike "ST M95640-W" (the 8Kbyte EEPROM used in some NDS carts).

There are no other bigger chips with more than 6 pins, and the ROM doesn't contains any further SPI or I2C functions. So there doesn't seem to be an accelerometer in there (at least none with serial bus). The ROM does contain some A/D converter functions... could that be used for some kind of pedometer sensors?

There are about ten tiny chips/transistors/diodes with 3,4,5,6 pins, and two large 2pin capacitors (or whatever), and some semi-transparent blue magic ink... one (or more) of those components must be the pedometer hardware...?
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 10:54 am

I completely forgot to mention the DS TV (NTR-016) is another cartridge with specialty components inside. Works with 1seg broadcasts, and it's still functional in Japan as far as I know.

I'll have the other log finished in a few hours after work. Some of the memory locations being read from the Activity Meter during player registration for Walk with Me aren't consistent, so I want to double-check what's going there before posting anything.

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

Re: NDS Cartridge ROM specs

Post by Shonumi » Tue Mar 02, 2021 12:57 am

Here's the log from the NDS to the Activity Meter. There are some new commands (08h, 20h, and 24h) but I have not had a chance to try and analyze them. If you're disassembling the Activity Meter's ROM now, you may already know what they do by the time you read the log. My guess is that 08h and 20h are write commands, given the type of responses from the Activity Meter (which look like simple acknowledgement packets).

Some of the memory locations accessed during player registration in Walk with Me appear to change. That is to say, they seem to increment every time I make a new log. Maybe the Activity Meter is keeping track of how many times it has registered user data and it using different "slots" to store new data. Perhaps you'll see something like that in the disassembly?

At any rate, the two logs I posted should give a good idea of the IR protocol during player registration. I'll move on to logging data when checking steps in the game itself.
Attachments
LOG_B3.TXT
(6.06 KiB) Downloaded 35 times

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

Re: NDS Cartridge ROM specs

Post by nocash » Tue Mar 02, 2021 3:15 am

Thanks, very good to know which commands are actually used in practice, and with which parameters!

Here's a summary of the commands/replies found in the disassembly:

Activity Meter commands (from NDS):

Code: Select all

  08,xx,cc,cc,msb,lsb,data[..]   CPU Memory Write               ;Reply=08
  0A,xx,cc,cc,msb,lsb,len        CPU Memory Read                ;Reply=0A
  20,xx,cc,cc,msb,lsb,data[..]   Serial EEPROM Write            ;Reply=20
  22,xx,cc,cc,msb,lsb,len        Serial EEPROM Read             ;Reply=22
  24,....           ??? (includes set RTC time)                 ;Reply=24
  26,xx,cc,cc       Deadlock  ;\both same (probably triggers    ;Reply=26, 80 ?
  28,xx,cc,cc       Deadlock  ;/ Watchdog/reboot)               ;Reply=26, 80 ?
  2A,....           ??? (whatever)                              ;Reply=2A
  2C,LL,cc,cc       Toggle LEDs ?                               ;Reply=2C
  F4,xx,cc,cc       Disconnect                                  ;Reply=None
  F6,xx,cc,cc       ??? sets a flag... maybe keep alive or so?  ;Reply=None
  FA,xx,cc,cc       Connect                                     ;Reply=F8
  FE,xx,cc,cc       Ignored     ;\ignored, without cpu wake up? ;Reply=None
  FF,xx,cc,cc       Ignored     ;/                              ;Reply=None
  xx,xx,cc,cc       Reserved    ;-ignored, with cpu wake up?    ;Reply=None


Activity Meter replies (to NDS):

Code: Select all

  08,ss,cc,cc           Reply to Cmd 08 (CPU Memory Write reply)
  0A,ss,cc,cc,data[..]  Reply to Cmd 0A (CPU Memory Read reply)
  20,ss,cc,cc           Reply to Cmd 20 (Serial EEPROM Write reply)
  22,ss,cc,cc,data[..]  Reply to Cmd 22 (Serial EEPROM Read reply)
  26,xx,cc,cc           Reply to Cmd 26 and 28 (Deadlock reply)
  24,xx,cc,cc           Reply to Cmd 24 (???) (includes set RTC time)
  2A,xx,cc,cc,...       Reply to Cmd 2A (???) (whatever)
  2C,xx,cc,cc           Reply to Cmd 2C (LEDs?)
  80,FF,cc,cc           CPU Rebooting (probably appears as 2nd Deadlock reply?)
  F8,00,cc,cc           Reply to Cmd FA (Connect reply)
  FC,xx,cc,cc           ??? (longer advertising with 4 bytes?)
  FC                    Advertising Msg (after pressing button) (single byte)
The command/reply from/to NDS are intended to be transferred as so, but things could go wrong if there are multiple consoles or activity meters (all trying to process the same message, or even mistreating replies as commands). The infrared range (distance/angle) is unknown.
NB. command F8 doesn't exist (there is only a reply with that number, no cmd).

The LED command seems to use the upper 4bit and lower 4bit from hdr[1], and checks if that 4bit nibbles are zero or nonzero. One nibble seems to select which LED to change (red or green), and the other nibble selects what to do with it (switch on or off). Ie. to change both LEDs, one would need to send two separate commands.

EEPROM addresses should be 0000h..1FFFh, assuming that it is really an 8Kbyte EEPROM (the page size is 32 bytes, which does also match up with 8Kbyte EEPROMs) (no need to care about crossing page boundaries, the code is taking care of that automatically).

RAM addresses should be FB80h..FF7Fh (the stack is at FECEh..FF7Fh). And ROM at 0000h..3FFFh.

The Connect command isn't required, CPU Memory Read worked fine wihtout connecting (just press the button to wake up the IR hardware, and then wait for the FCh byte; just sending commands right away without checking FCh might work, too).

Btw. roughly related... does somebody have photos of the Tilt Sensors in older GBA cartridges? Or photos/schematics/info for similar sensors in other old hardware, dated around 2008 or older?
I am still trying to figure out where the pedometer is... maybe the two larger smd "capacitors" are actually two 1-axis analog sensors...?
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

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

Re: NDS Cartridge ROM specs

Post by nocash » Tue Mar 02, 2021 4:10 am

Got some PCB photos per email...
About the Wii U Fit meter: I've seen PCB photos of it, it's definitely a RL78/G13 CPU: (HUGE 3024x3024 JPGs):
https://cdn.discordapp.com/attachments/ ... image0.jpg
https://cdn.discordapp.com/attachments/ ... image1.jpg
Info for the "R5101EEA" chip,
https://www.renesas.com/us/en/products/ ... plications
compare with Pokewalker PCBs (1800x2100 JPG):
https://i.imgur.com/sKtUz3b.jpg
https://i.imgur.com/6EO7OIJ.jpg
And some more photos here...
https://legendarypkmn.net/2009/11/26/po ... -teardown/
The activity meter's pedometer is probably the stuff with the white/blue paint.
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 » Thu Mar 04, 2021 2:18 am

Managed to grab a log of when Walk with Me checks the step count. Apparently the battery isn't dead after all in my flashcart, so I can save a bunch of data relatively easily now. Haven't done much analysis yet, but it's not sending any new commands. Hopefully it's more readable in this format.

I'll have to make more logs with different step counts. Once those are compared, it should be easy to narrow down what areas of memory store the step count and the timestamp the Activity Meter records when you start/stop walking.

EDIT: There was some corruption for the data in Read_Steps_NDS.txt (specifically all of those 40h byte reads). It should be fixed now.
Attachments
Read_Steps_Activity_Meter.txt
(3.79 KiB) Downloaded 30 times
Read_Steps_NDS.txt
(1.75 KiB) Downloaded 30 times

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

Re: NDS Cartridge ROM specs

Post by nocash » Fri Mar 05, 2021 7:01 am

I've disassembled most of the Activity Meter ROM (except the logic for low-power modes, and maths for converting the analog X/Y inputs to pedometer steps). Anyways, here's the RAM and EEPROM memory map. That should explain most of the IR memory read/write commands...

Code: Select all

                 ;------------------
                 ;Activity Meter RAM and EEPROM memory map, 5th Mar 2021 nocash
                 ;------------------
                 .ram
                 org 0FB80h
                 ;---
                 memfill_dst_start:        ;len=336h
                 another_memfill_start:    ;len=190h
FB80             button_flags            db 00h  ;bit7=curr.state, bit6=newly.pressed, bit5=old.state
FB81                 ...                 db 00h       ... cleared if memread src was unique_id (and other cases)
FB82                 ...                 db 00h         ... sys/power mode ?
FB83                 ...                 db 00h  ;adc_mode, or power_save? ... disables A/D scaling... and maybe affects more low-power stuff ?
FB84                 ...                 db 00h     ... clock change request
FB85                 ...                 db 00h     ... led_extra_mask  ... (this is never CLEARED, except at memfill, or maybe via IR writes?)
FB86             adc_array_index         db 00h  ;index in ADC array X/Y (wraps in range 00h..3Fh)
FB87                 ...                 db 00h         ... entrysize of current data in ringbuf (per newest TAG) or so?
FB88             spi_error_flag          db 00h   ;SPI overrun error (probably nonsense, since SPI master could hardly get outrun by it's own clock)
FB89              defs 1  ;unused
FB8A             num_steps_curr_minute   db 00h  ;tiny 8bit per minute counter (max FCh, to avoid confusion with tags FDh,FEh,FFh)
FB8B             rtc_event_flags         db 00h    ... RTC event flags (bit0=minute, bit1=hour, bit2=day, bit3=also.hour)
FB8C                 ...                 db 00h    ... timing offhold for various stuff
FB8D             some_shift_amount       db 00h    ;READ via IR    ... some shift amount
FB8E             goal_reached_flag       db 00h  ;daily goal reached flag (aka LED color) (bit0=reached, bit1=???)
FB8F                 ...                 db 00h     ... timing for LED step pulses?
FB90                 ...                 db 00h     ... timing for LED step pulses?
FB91                 ...                 db 00h     ... flag for LED step pulse state?
FB92             new_day_hour_three      db 00h    ;READ via IR  (HOUR when new DAY starts, usually/always 03h)
FB93                 ...                 db 00h     ... some flag for inactivity low-power mode ?
FB94             led_animation_number    db 00h    ;select a special LED animation number (1..5, or 0=none)
FB95              defs 1  ;unused
FB96             new_day_flag            db 00h    ;new_day_flag
FB97             fixed_led_mask          db 00h     ... led_mask (this is a "fixed" setting from EEPROM)
                 compare_ctrl_values:               ;\
FB98             compare_ctrl_0          db 00h     ; memfilled 2 bytes (set to 89h, for "Compare Control" HW registers)
FB99             compare_ctrl_1          db 00h     ;/
FB9A             new_goal_flag           db 00h    ;new GOAL flag
FB9B              defs 1  ;unused
FB9C             unique_id:              defs 28h  ;READ via IR ;"IDENTITY DATA"
FBC4             adc_current_x           dw 0000h  ;16bit
FBC6             adc_current_y           dw 0000h  ;16bit
FBC8             adc_array_x:            defs 80h  ;40h x 16bit
FC48             adc_array_y:            defs 80h  ;40h x 16bit
FCC8             adc_scale_factor_x      dw 0000h  ;16bit
FCCA             adc_scale_factor_y      dw 0000h  ;16bit
FCCC             adc_scale_unused_z      dw 0000h  ;semi-unused (written, but never read)
FCCE             adc_scale_unused_t      dw 0000h  ;semi-unused (written, but never read)
FCD0             ringbuf_mm_index        dw 0000h  ;READ via IR followed by two EEPROM reads from variable addr   ;eeprom_0020h ... 16A1h-1
FCD2             ringbuf_hh_index        dw 0000h  ;READ via IR followed by one EEPROM read from variable addr    ;eeprom_16A1h ... 1C43h-1
FBD4              defs 2  ;unused
FCD6             ringbuf_dd_index        dw 0000h  ;READ via IR followed by one EEPROM read from variable addr (with skipped locations)
FCD8             num_steps_curr_hour     dw 0000h  ;short 16bit step counter for current hour
FCDA             ringbuf_stepback_index  dw 0000h  ;result from cmd_2Ah (which can be then read via RAM read, cmd_0Ah)
FCDC             adc_inactivity_timer    dw 0000h  ;time since last pedometer step
FCDE             spi_error_count         dw 0000h  ;spi overrun error (which could hardly happen on spi master)
FCE0              defs 2  ;unused
FCE2             adc_current_sum         dw 0000h     ;sum of eight A/D conversions
FCE4             seconds_counter         dd 00000000h ;seconds since 1st? Jan 2001 (?)  ;(eg. 2021 is about 20*365*24*60*60 = 630720000 = 25980600h) ;(initially 0D2B0B80h = 2nd? January 2008)
FCE8             num_steps_lifelong      dd 00000000h ;lifelong TOTAL steps
FCEC             num_steps_today         dd 00000000h ;step counter (for current day)
FCF0             daily_goal              dd 00000000h ;written via IR (default in NDS cart is 00000BB8h = 3000 decimal)
FCF4             new_goal_steps          dd 00000000h ;somewhat reload value for daily goal?
FCF8              defs 18h ;unused
                 ;- - -
                 another_memfill_end:
                 another_memfill_size equ another_memfill_end-another_memfill_start  ;=190h
                 ;- - -
FD10             main_callback          dw 0000h  ;main_adc_button_callback, or to_to_ir_callback
FD12             ir_tx_data:            defs 40h  ;for Memory & EEPROM reads
FD52             clk_callback           dw 0000h  ;clk_whatever_callback or 0=none
FD54             ir_callback            dw 0000h  ;ir_active_callback, or ir_dummy_callback,
FD56             ir_timestamp_last_byte dw 0000h  ;timestamp for last byte (for sensing GAPs aka end-of-packet)
FD58             rx_chksum_from_hdr     dw 0000h  ;chksum, from hdr[2]
FD5A             rx_chksum_calculated   dw 0000h  ;chksum, from calculation
FD5C             ir_timestamp_last_xfer dw 0000h  ;timestamp for last successful transfer (for sensing LONGER INACTIVITY aka entering sleep mode)
FD5E             defs 1  ;unused
FD5F             ir_rx_len              db 00h
FD60                    ...semi_blah    db 00h   ;semi-unused (set to 00h?) (but never read)
FD61             ir_rxtx_buf:           defs 44h  ;hdr[4]+data[40h]
FDA5             ir_tx_hdr_len          db 00h   ;\memorized TX len+hdr[4]
FDA6             ir_tx_hdr_copy:        defs 4   ;/(never actually used)
FDAA             bad_chksum_count       db 00h   ;num_bad_chksums (give up sending bad_chksum replies after 3 errors)
FDAB             bad_chksum_flag        db 00h   ;request reply_FCh (bad_chksum)
FDAC                    ...             defs 0Ah    WORDs ;\
FDB6                    ...             defs 76h    WORDs ;
FE2C                    ...             defs 0Ah    WORDs ; analog sine/cosine
FE36                    ...             defs 76h    WORDs ; stuff for converting
FEAC                    ...             dd 00000000h      ; adc to step counter?
FEB0                    ...             dd 00000000h      ;
FEB4                    ...             db 00h            ;
FEB5                    ...             db 00h            ;/
                 memfill_dst_end:
                 ;---
                 memcopy_dst_start:  ;below initialized from "memcopy_src_start"
FEB6,3C38 0000       ...                dw     0000h     ;callback.counter (incremented in main_adc_button_callback, but not used elsewhere)
FEB8,3C3A 00      defs 1  ;unused                                      ;\maybe meant to be
FEB9,3C3B 00     tx_sequence_number     db     00h       ;sequence.no  ; 4-byte tx hdr, but
FEBA,3C3C 0000    defs 2  ;unused                                      ;/only hdr[1] used  (increasing seq.no for memory read/write replies)
FEBC,3C3E 0000       ...                dw     0000h       ;\WORD ARRAY...
FEBE,3C40 0000       ...                dw     0000h       ;/  <-- accessed as 0FEBEh directly, and as 0FEBCh+2
FEC0,3C42 0200       ...                dw     0200h       ;\WORD ARRAY...
FEC2,3C44 0200       ...                dw     0200h       ;/  <-- accessed as 0FEC2h directly, and as 0FEC0h+2
FEC4,3C46 0200       ...                dw     0200h       ;\WORD ARRAY
FEC6,3C48 0200       ...                dw     0200h       ;/  <-- second word of above "array"
FEC8,3C4A 0200       ...                dw     0200h       ;\WORD ARRAY
FECA,3C4C 0200       ...                dw     0200h       ;/  <-- second word of above "array"
                  ;---
                 stack_bottom:
FECE              defs 0B2h   ;stack area
                  ;- - -
                  ;weirdly, the stack occupies the most valueable RAM area
                  ;at FF00h..FF7Fh, preventing short addressing via "[FFnnh]"
                  ;and single bit operations via "[FFnnh].bitno".
                  ;also weirdly, the last word at [FF7Eh] holds a bogus retadr.
                  ;- - -
FF80             stack_top:
                 ;------------------
                 ;EEPROM memory map:
                 org 0
                 ;---
                 ee_erase_area_start:   ;<-- for UNUSED erase function
                 ee_write_test_addr:    ;<-- for UNUSED test function
                 ;---
EEPROM:0000      ee_id_nintendo:     defs 9   ;ID "nintendo",00h (9 bytes)
EEPROM:0009       defs 17h ;unused
                 ;---
                 ;note: when doing "stepback" in below ringbuffers,
                 ;wrapping occurs when being "unsigned below start address",
                 ;so "start address" must be bigger than the stepping offset
                 ;(else wrapping from 0000h to FFFFh would derail the maths)
                 ;---
                 ee_start_of_ringbuffers:
                 ;---
                 ee_ringbuf_mm_start:
                 ee_ringbuf_mm_size equ 1681h
EEPROM:0020       defs 1681h ;large ringbuf, size=1681h, eeprom_0020h ... 16A1h-1  ;via [0FCD0h] ringbuf_mm_index ;steps per MINUTE of last 4 days  ;(24*60*4-1)*8bit  ... mixed with timestamp/buffer.end TAGs
                 ee_ringbuf_mm_end:
                 ;---
                 ee_ringbuf_hh_start:
                 ee_ringbuf_hh_size equ 5A2h
EEPROM:16A1       defs 5A2h  ;small ringbuf, size=5A2h,  eeprom_16A1h ... 1C43h-1  ;via [0FCD2h] ringbuf_hh_index ;steps per HOUR of last 30 days   ;(24*30+1)*16bit   ... also with TAGs ?
                 ee_ringbuf_hh_end:
                 ;---
                 ee_ringbuf_dd_start:
                 ee_ringbuf_dd_size equ 9Ch
EEPROM:1C43       defs 9Ch   ;tiny ringbuf,  size 9Ch,   eeprom_1C43h ... 1CDFh-1  ;via [0FCD6h] ringbuf_dd_index ;steps per DAY of last 52 days    ;(52)*24bit        ... also with TAGs ?
                 ee_ringbuf_dd_end:
                 ;---
EEPROM:1CDF       defs 1     ;unused (padding ringbuf's to 20h-byte-boundary)
                 ee_end_of_ringbuffers:
                 ;---
EEPROM:1CE0       defs 200h ;unused
                 ;---
                 ee_erase_area_end:   ;end of erase area (in unused function)
                 ;---
                 ;... begin of double buffered area... (at 1EE0h and 1F40h)
EEPROM:1EE0,1F40 eee_adc_scale_values:   defs  8+1    ;read 2x               ;RAM: 0FCC8h+0..7  ;scale values
EEPROM:1EE9,1F49 eee_adc_sum_limit:      defs  2+1    ;read 3x, written 3x   ;RAM: temp/stack   ;limit for SUM of three A/D conversions?
EEPROM:1EEC,1F4C  defs 3  ;unused
EEPROM:1EEF,1F4F eee_num_steps_lifelong: defs  4+1    ;read 2x, written 2x   ;RAM: 0FCE8h ;num_steps_lifelong
EEPROM:1EF4,1F54 eee_fixed_led_mask:     defs  1+1    ;read 1x               ;RAM: 0FB97h ;fixed_led_mask
EEPROM:1EF6,1F56  defs 2  ;unused
EEPROM:1EF8,1F58 eee_some_shift_amount:  defs  1+1    ;read 1x               ;RAM: 0FB8Dh ;some_shift_amount
EEPROM:1EFA,1F5A eee_daily_goal:         defs  4+1    ;read 1x, written 1x   ;RAM: 0FCF0h ;daily_goal
EEPROM:1EFF,1F5F eee_new_goal_steps:     defs  4+1    ;read 1x, written 1x   ;RAM: 0FCF4h ;new_goal_steps
EEPROM:1F04,1F64 eee_unique_id:          defs  28h+1  ;read 2x               ;RAM: 0FB9Ch ;unique_id   ;"IDENTITY DATA"
EEPROM:1F2D,1F8D  defs 13h  ;unused
                 ;... end of double buffered area...
                 ;---
EEPROM:1F40      eee_backup_copies: defs 60h ;backup's of above, see 1EE0..1F3F
                 ;---
EEPROM:1FA0      ee_errcode             dw 0000h  ;errcode
EEPROM:1FA2      ee_reboot_counter      db 00h    ;reboot counter
                 ;---
EEPROM:1FA3       defs 5Dh ;unused
                 ;------------------
The easiest way to read the stepcounter would be reading the "num_steps_lifelong" variable (and subtract the value from previous reading if desired). And, the thing is logging steps in three ringbuffers in EEPROM:

Code: Select all

  ringbuf_mm: 8bit steps for each MINUTE of last 4 days
  ringbuf_hh: 16bits steps for each HOUR of last 30 days
  ringbuf_dd: 24bits steps for each DAY of last 52 days
Apart from the 8bit/16bit/24bit step values, that ringbuffers do additionally contain some special tags:

Code: Select all

  FDh marker for 32bit timestamps (stored as 10-digit BCD with REVERSED digit-ordering, eg 1234567890 is stored as 5-byte 09,87,65,43,21)
  FEh marker for end of buffer (aka newest entry)?
  FFh unused free space?
The logging is supposedly paused during inactivity, and the timestamps are used to indicate when logging has resumed.

The ROM has some code to stepback to the Nth FDh marker in the ringbuffer's, I am not sure if or how that's working. The BCD timestamp bytes are of course 00h..99h. The 8bit values in the MINUTE array are limited to 00h..FCh, so they can't be confused with FDh,FEh,FFh markers. However, the 16bit/24bit values in the other arrays don't have that limit.
Don't know... there might be also length values saying that the next N values are step counters (to avoid confusing them with markers).

And, some update on the IR commands and replies...

Code: Select all

Activity Meter commands (from NDS):
  08,xx,cc,cc,msb,lsb,data[..]  CPU Memory Write    (len=3Eh max)  ;Reply=08
  0A,xx,cc,cc,msb,lsb,len       CPU Memory Read     (len=40h max)  ;Reply=0A
  0A,xx,cc,cc,FB,9C,len         CPU Memory Read FB9Ch with ClrFlag ;Reply=0A
  20,xx,cc,cc,msb,lsb,data[..]  Serial EEPROM Write (len=3Eh max)  ;Reply=20
  22,xx,cc,cc,msb,lsb,len       Serial EEPROM Read  (len=40h max)  ;Reply=22
  24,00,cc,cc,ss,ss,ss,ss       Update Ringbuf_mm    ;\            ;Reply=24
  24,01,cc,cc,ss,ss,ss,ss       Update Ringbuf_hh    ; and set     ;Reply=24
  24,02,cc,cc,ss,ss,ss,ss       Update Ringbuf_dd    ; 32bit       ;Reply=24
  24,03,cc,cc,ss,mm,hh          Set RTC hh:mm:ss     ; seconds     ;Reply=24
  24,04,cc,cc,ss,ss,ss,ss       Raw Set ssssssss ?   ;/            ;Reply=24
  24,xx,cc,cc,ss,ss,ss,ss       Invalid (same as 24,04)            ;Reply=24
  26,xx,cc,cc                   Deadlock   ;\both same (maybe      ;Reply=26
  28,xx,cc,cc                   Deadlock   ;/Watchdog/reboot?)     ;Reply=26
  2A,xx,cc,cc,00,nn             Stepback Ringbuf_hh  ;\go back nn  ;Reply=2A
  2A,xx,cc,cc,01,nn             Stepback Ringbuf:mm  ; entries,    ;Reply=2A
  2A,xx,cc,cc,02,nn             Stepback Ringbuf_dd  ;/see [FCDAh] ;Reply=2A
  2A,xx,cc,cc,xx,..             Invalid                            ;Reply=2A
  2C,LL,cc,cc                   Toggle LEDs ?                      ;Reply=2C
  F4,xx,cc,cc                   Disconnect                         ;Reply=None
  F6,xx,cc,cc                   Force "Bad Chksum" reply           ;Reply=FC
  FA,xx,cc,cc                   Connect                            ;Reply=F8
  FE,...                        Noise      ;\ignored, noise        ;Reply=None
  FF,...                        Noise      ;/                      ;Reply=None
  xx,xx,cc,cc                   Invalid    ;-ignored, invalid cmd
 ;Reply=None

Activity Meter replies (to NDS):
  08,sq,cc,cc           Reply to Cmd 08 (CPU Memory Write reply)
  0A,sq,cc,cc,data[..]  Reply to Cmd 0A (CPU Memory Read reply)
  20,sq,cc,cc           Reply to Cmd 20 (Serial EEPROM Write reply)
  22,sq,cc,cc,data[..]  Reply to Cmd 22 (Serial EEPROM Read reply)
  26,xx,cc,cc           Reply to Cmd 26 and 28 (Deadlock reply)
  24,xx,cc,cc           Reply to Cmd 24 (Update, or Set RTC time)
  2A,xx,cc,cc           Reply to Cmd 2A (Stepback, with result at [FCDAh])
  2C,xx,cc,cc           Reply to Cmd 2C (LEDs?)
  80,FF,cc,cc           CPU Rebooting (probably appears as 2nd Deadlock reply?)
                          Actually above repeats in ENDLESS AGONY after crash?
                          Though maybe gets terminated by watchdog?
  F8,00,cc,cc           Reply to Cmd FA (Connect reply)
  FC,xx,cc,cc           Reply to Cmd's with Bad Chksum (and Cmd F6)
  FC                    Advertising Msg (after pressing button) (single byte)
All of the commands with "24,xx,cc,cc,ss,ss,ss,ss" are setting the 32bit time value, here as big-endian-hex-value (that's the same seconds timer used in the EEPROM ringbuffers, but there it's stored as reversed-10-digit-BCD-number).
The 32bit time seems to be seconds since at 1st January 2001, and the ROM initializes it to 2nd Janualy 2008.
Hmmm, or maybe it is seconds since 31th December 2000, with inital value 1st January 2008.
If somebody wants to solve the exact time base... compare the NDS RTC time with activity meters "seconds-since-whatever" values.

Note: The "24,03,cc,cc,ss,mm,hh" command does set the activity meters own RTC (which mostly used for new-day, new-hour, new-minute) It's unrelated to the seconds-since timestamp... except, confusingly, the ss,mm,hh bytes are copied to the upper bits of the 32bit seconds-since value (that's a weird bug, and one must send another "24,xx,cc,cc,ss,ss,ss,ss" command to repair the 32bit value).
Last edited by nocash on Fri Mar 05, 2021 7:45 am, edited 1 time in total.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

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

Re: NDS Cartridge ROM specs

Post by nocash » Fri Mar 05, 2021 7:15 am

PS. Without seeing it in the intrared packet log, I wouldn't have believed that anybody would store BCD values in reversed order ; )

Oh, and the Walk with Me GUI messages about pressing the button "one whole second" or even "three whole seconds"...
I guess that's just nonense, and it's also working when just tapping the button?

The ROM doesn't have code for measuring how long the button is pressed, it does just react to "newly pressed" transitions.
One could use the IR memory commands to read [FB80h]=button_flags (or [0FFDEh]=Port_B_Data).
But I don't think that Walk with Me is doing any such thing.
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 Mar 05, 2021 8:24 pm

Great work! This should be more than enough to fully emulate the Activity Meter. Not sure it'll help at this point, but I can still post some additional IR logs for the step check if you're interested.

Any plans to support this in no$gba? I've been having trouble getting the player registration working in my emulator. After the NDS reads the Identity Data a second time, something goes wrong. If a new version no$gba can get farther than that, it'd be nice for debugging things on my end.

Regardless, I look forward to seeing GBATEK get an update!

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

Re: NDS Cartridge ROM specs

Post by nocash » Sun Mar 07, 2021 2:53 pm

Hmmm, emulating the Activity Meter? Well maybe - but no - it's pretty impossible to imagine people in wheelchairs enjyoing "Walk with Me" in emulators. But yeah, it could be useful for testing if the transfer protocol really works as expected - and maybe for getting more packet logs including initial initialization. Emulating the ringbuffers could be a bit difficult though, I haven't fully figured out what is stored where and when.

Do you have the final checksum adjusted with MSW+LSW, plus CARRY-OUT from that addition? Like so...

Code: Select all

 adds  r3,r3,r3,lsl 16   ;MSW+LSW*10000h                ;
 addcs r3,10000h         ;MSW+CY*10000h                 ;
 mov   r3,r3,lsr 16      ;to LSW                        ;
The Activity Meter ROM contains a factory reset function that seems to be activated by one of the test points. It's doing some tests on EEPROM, RTC, and ADC, and erases the whole EEPROM (FFh-filled), and does then store a ADC calibration value (in range 021Bh..0326h, plus appended checksum byte) at EEPROM address 1F49h and 1EE9h.
Apart from that calibration value, the whole EEPROM is empty (even the unique_id is FFh-filled, and does supposedly get initialized with some random value when first-time connection to the NDS cartridge).
After the factory reset, and before connecting to the cartridge, there are some more EEPROM entries initialized, the "nintendo",00h string, the ringbuffers, and several other bytes (so you will never see a completely empty EEPROM in practice).2

I've dumped the EEPROM from my Activity Meter thing, that's probably giving a bigger picture than looking at IR transfer snippets. The MINUTE ringbuffer is using some sort of run-length compressing (00h,NNh means NNh minutes with 0 steps, where NNh is max FCh) (and 01h..FCh means 1 minute with that many steps, and FDh,FEh,FFh are the special markers). The HOUR and DAY ringbuffers don't have that run-length compression.
Attachments
dumpIrMeterEeprom.bin
(8 KiB) Downloaded 21 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 » Sun Mar 07, 2021 8:45 pm

My main interest in emulating the Activity Meter is mostly video game/software preservation. Using the Activity Meter is the only way to access anything in Walk with Me, otherwise you're stuck to viewing just a few menus. I suppose you could always copy the save file from a real cartridge, but making that initial save file would still require someone to use the Activity Meter. Walk with Me in particular is an interesting piece of software because it is the only NDS game that features Miis, so for historical purposes it would be great to see the Activity Meter emulated in some form, which is my motivation and goal. I do agree though, outside of academics, there's really nothing fun or enjoyable about emulating pedometers (e.g. see Ubisoft's Thrustmaster and its corresponding NDS "game") ;)

I will double check my checksum calculation. My earlier notes neglected to detail the carry out operation, but I added code for that last year. The checksums match what I found in the IR logs exactly, but I'll take another look. It reads the Identity Data several times just fine during the initial connection (where the Activity Meter talks on and on forever before you choose a Mii). It only fails in my emulator after that, when the Activity Meter has to be pinged a second time in order to set the RTC stuff. When it tries to read Identity Data then, I get a connection error in my emulator. I know GBE+ isn't exactly a mature NDS emulator, so it's possible another bug is interfering.

So far, the sections where the Identity Data is sent are the only times the checksum needs the carry out operation, so I'll investigate what's going on in GBE+.

User avatar
Gilbert
Posts: 466
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: NDS Cartridge ROM specs

Post by Gilbert » Sun Mar 07, 2021 10:37 pm

Shonumi wrote:
Sun Mar 07, 2021 8:45 pm
Walk with Me in particular is an interesting piece of software because it is the only NDS game that features Miis
Tomodachi Collection also features Miis, though it's not released outside Japan, so it may not count.

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

Re: NDS Cartridge ROM specs

Post by Shonumi » Sun Mar 07, 2021 11:10 pm

Indeed, my mistake! Apparently there are other Japanese NDS exclusives besides Tomodachi Collection that use Miis in other capacities as well. Guess I learned something new today.

I'm still fascinated by Walk with Me, as its Mii creation on the NDS is a rarity and something worth preserving. It's a wonder they didn't call it Walk with Mii though...

User avatar
Gilbert
Posts: 466
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: NDS Cartridge ROM specs

Post by Gilbert » Sun Mar 07, 2021 11:31 pm

According to Wikipedia there is at least one Final Fantasy game not exclusive to Japan that uses Miis, so there are some more games to test in case emulators do support Mii functions.
It's a wonder they didn't call it Walk with Mii though...
Considering the fact that the game was only called Walk with Me in PAL region and it's the last version to be released (according to Wikipedia) I think Nintendo just didn't care. If they had thought of such a pun in the first place they should also use the same name in the US version (I still sometimes don't get the need of different English titles in different regions, apart from obvious reasons such as copyrights and cultural differences).

Post Reply