Views: 6,703,612 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 03-29-24 03:03 PM
Guest:

0 users reading Bluetooth cart + keyboard | 1 bot

Main - Development - Bluetooth cart + keyboard Hide post layouts | New reply


Arisotura
Posted on 10-06-17 09:15 PM (rev. 5 of 10-07-17 02:29 AM) Link | #380
Comes with game "Pokémon Typing Adventure" or whatever the name is.


I'll post reverse-engineering notes in this thread.



Init

Game sends the following data via the aux SPI bus:

FF 01 00 00 04 01 03 0C 00

It doesn't read the response. A test on the cart returned all zeros.

There has to be something else the game is expecting but not getting.


The cart sends an IRQ (IREQ_MC) when receiving data over SPI. Regular carts don't do that (and respond all FF instead of 00 when sent the command above).

The IRQ is sent after the first SPI command byte is sent. No idea if there are specific values that don't trigger the IRQ, or if it has a "write zero to get to the backup memory" thing like other Pokémon carts (attempt at sending a RDID command read zeros).

Emulating it doesn't do shit, though.

Also: IREQ_MC triggers on both CPUs, regardless of EXMEMCNT. In the case of Pokémon, though, it's only enabled on the ARM9.


Cart ID

The cart returns an ID of 0x80007FC2.

Bit 31 there causes the BIOS to load the secure area differently: for each block, the command is repeated 9 times, first time with a zero length, next 8 times with 0x200.

It's not too clear how this should work, and melonDS doesn't emulate it, so such an ID causes firmware boot to fail (secure area is loaded wrong, which doesn't bode well).

The game itself seems sensitive to the cart ID. It behaves differently when bit31 is set, but... it doesn't try to do anything...? Nope.

____________________
Kuribo64

Arisotura
Posted on 10-07-17 10:59 PM (rev. 2 of 10-08-17 02:42 AM) Link | #385
Function at 0x0206DEC4 refers to the following strings:

Sending to unknown dest
Send - buffer linked


Similar strings are found, for example, here: https://android.googlesource.com/platform/external/libnfc-nci/+/jb-mr1-dev/halimpl/bcm2079x/gki/common/gki_buffer.c#681


So I guess our cart is using a Broadcom Bluetooth controller, and they've been using one of those open-source drivers. Interesting.


More on this.

https://github.com/mozilla-b2g/platform_external_bluetooth_bluedroid/blob/master/stack/btu/btu_task.c

Driver sitting between the game and the hardware seems to be a stripped-down version of this.

____________________
Kuribo64

Arisotura
Posted on 10-10-17 09:30 PM Link | #390
Triggering another IRQ after the first SPI command is finished causes the game to send another SPI command.

(and things go wrong, because the command starts with a 02 and melonDS mistakes it for a regular savemem command. I need to rework that code)


I need to acquire a cart slot, so I can hook the cart to a raspi and test it. Issue with testing on the DS is that, I guess, when swapping carts, the new cart doesn't get a reset signal. May not be a big deal for regular savemem, but this cart embeds what seems to be a Broadcom controller that can do several things.

____________________
Kuribo64

Arisotura
Posted on 04-20-21 05:31 PM Link | #3603
FF 01 00 00 04 01 03 0C 00


FF: starter byte presumably

01 00 00 04: header
01 00: command??
00 04: length of payload

01 03 0C 00: payload

____________________
Kuribo64

Arisotura
Posted on 04-21-21 10:13 PM (rev. 3 of 04-21-21 11:12 PM) Link | #3606
UPDATE on this matter


the game does something weird during SPI comm:

1. set SPICNT to A040
2. send FF byte
-> cart sends IRQ, which is ignored
3. set SPICNT to 0043
4. small delay
5. set SPICNT to A040
6. send header and payload (SPICNT set to A000 before last byte, as normal)
-> cart sends IRQ at the end of the payload


it's weird because just sending the first byte with SPICNT=A000 does not replicate this

as if normal 'clear hold after last byte' just told the cart to reset SPI comm, and next byte is considered a 'first byte' again

but the weird reset done by setting SPICNT to 0043 somehow behaved different, deselecting the SPI thing but with a different timing? that somehow tells the cart 'but wait, there's more'

prolly that setting stops the BT controller from getting a SPI clock, which it can detect SPI clock is supposed to only work during a transfer

____________________
Kuribo64

Arisotura
Posted on 04-22-21 08:03 PM (rev. 3 of 04-22-21 08:05 PM) Link | #3607
CONTENTS OF THE POKETYPE CART

* typical Macronix ROM
* STMicroelectronics M25PE10 SPI FLASH memory, presumably 128K
* Broadcom BCM2070 Bluetooth controller
* 26MHz crystal oscillator

____________________
Kuribo64

Arisotura
Posted on 04-30-21 12:43 AM Link | #3641
Kuruma de DS (UZCJ) also has a BT controller

____________________
Kuribo64


Main - Development - Bluetooth cart + keyboard Hide post layouts | New reply

Page rendered in 0.047 seconds. (2048KB of memory used)
MySQL - queries: 28, rows: 87/87, time: 0.016 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.