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.
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...?
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.
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.
- (6.06 KiB) Downloaded 35 times
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, 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...?
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://legendarypkmn.net/2009/11/26/po ... -teardown/
The activity meter's pedometer is probably the stuff with the white/blue paint.
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.
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 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+data[40h] FDA5 ir_tx_hdr_len db 00h ;\memorized TX len+hdr 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 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).
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.
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!
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.
- (8 KiB) Downloaded 21 times
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'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...
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...