NDS Cartridge ROM specs
Re: NDS Cartridge ROM specs
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.
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.
Re: NDS Cartridge ROM specs
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...?
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...?
Re: NDS Cartridge ROM specs
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.
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.
Re: NDS Cartridge ROM specs
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.
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 146 times
Re: NDS Cartridge ROM specs
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):
Activity Meter replies (to NDS):
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...?
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)
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...?
Re: NDS Cartridge ROM specs
Got some PCB photos per email...
https://legendarypkmn.net/2009/11/26/po ... -teardown/
The activity meter's pedometer is probably the stuff with the white/blue paint.
About the Wii U Fit meter: I've seen PCB photos of it, it's definitely a RL78/G13 CPU: (HUGE 3024x3024 JPGs):And some more photos here...
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
https://legendarypkmn.net/2009/11/26/po ... -teardown/
The activity meter's pedometer is probably the stuff with the white/blue paint.
Re: NDS Cartridge ROM specs
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.
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 132 times
-
- Read_Steps_NDS.txt
- (1.75 KiB) Downloaded 138 times
Re: NDS Cartridge ROM specs
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...
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:
Apart from the 8bit/16bit/24bit step values, that ringbuffers do additionally contain some special tags:
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...
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).
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
;------------------
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
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 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)
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.
Re: NDS Cartridge ROM specs
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.
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.
Re: NDS Cartridge ROM specs
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!
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!
Re: NDS Cartridge ROM specs
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...
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.
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 ;
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 125 times
Re: NDS Cartridge ROM specs
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+.
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+.
Re: NDS Cartridge ROM specs
Tomodachi Collection also features Miis, though it's not released outside Japan, so it may not count.
Re: NDS Cartridge ROM specs
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...
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...
Re: NDS Cartridge ROM specs
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.
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).It's a wonder they didn't call it Walk with Mii though...