Battle Chip Gate Compatibility (via third-party tools)

[DeCoded-Void]

The battle chip gate accessory have already been implemented in mGBA and GBE+.

Thanks to community efforts, there are a good amount of online resources related to the accessory. [1] [2] [3] [4]
It is currently easy to reproduce chips through Copper Etching on a 2mm copper clad or through a PCB fabrication service for cheap.

My current goal is to use real chips for mGBA utilizing a cheap microcontroller and a card reader. Since there aren't any information on the card-reading port of the accessory, I 3d modeled a working one which uses donor pins from another edge connector.

Shonumi's implementation of the chip gate in GBE+ leverages TCP connections though their implementation of SIO with the gate, which allows for easy interaction by having a script send 3 bytes through that connection. Thanks to how its handled internally, its fairly easy to create tools such as a wireless version through a wifi-enabled microcontroller without the worry of handling the integrity of the emulated serial communication.

Based on shonumi's blogpost, my thought process for mGBA is to capture the start signal via Lua to observe the values of the addresses of serial transfers and using that to simulate the gate's transfer sequence and writing the hex of the chip id on the next transfer cycle.

Using the attached lua script here and reviewing the SIO Normal Mode and SIO Multi-Player Mode documentation, I am getting these as the values:

SIOMULTI0 (SIODATA32_L)
1. 0x0000
2. 0xA3D0
3. 0xA3D0
4. 0xA3D0
5. 0x8FFF
6. 0x0000

SIOMULTI1 (SIODATA32_H)
1. 0xFFC6
2. 0xFFC6
3. 0xFFC6
4. 0xFFC6
5. 0xFFC6
6. 0xFFC6
7. 0xFFC6

I was expecting the SIODATA32_L to have the same sequence as in the blog, however it seems like the 6th value of mine is 0x0000 while I was expecting another AxA3D0. At the same time, SIODATA32_H is indefinitely repeating the accessory's ID. The debug console shows the correct sequence of values.

I'm not too familiar with serial transfers and manipulating it though memory, so my interpretation is probably incorrect. What I was looking to do is to have the Lua script handle the transfers themselves by looping them to keep the communication alive while accepting socket data to be used in the next available transfer cycle to prevent the emulator + game thinking that the accessory is disconnected.

I wrote this just to see if I am approaching this the wrong way, a limitation of mGBA's Lua feature, or if it is a limitation of the current gate implementation.

[DeCoded-Void]

It seems like the following addresses are updated when a chip is inserted, the values here needs to be written in a particular order while the game acknowledges the gate accessory

+-------+------------+
| Frame | Address    |
+-------+------------+
| 1     | 0x0200F832 |
| 2     | 0x0200F904 |
| 10    | 0x0200F900 |
| 11    | 0x0200F902 |
+--------------------+

Writing to those in that order makes it work.

Its a workaround but its working, I am keeping this issue open and letting you decide if you want to enhance the feature or not.

[endrift]

I'd like to add support for just sending the data via a proper function call in the scripting API at some point. It's low priority compared to other features though.

[BlaXun]

I am really interested on this. Is this now possible using the scripting API?

[DeCoded-Void]

DeCoded-Void/DIY-Megaman-Battle-Chip-Gate

I posted my repository here and added you. The implementation depends on memory rather than simulated GBA link which is what is wanted to be created by the dev. It would open up a few things such as potentially making it easier to communicate with a real gba via an emulator and easily emulator other gba accessories without having to micromanage the memory, a method for researching such a thing can be done with a logic gate analyzer. More insight into this can also be found by a project done for pokemon gen 1/2 to gen 3 communication here. So the expectation is to translate the raw data of these signals into code to be used in a newer version of the mGBA api once the feature is implemented there.

I have done a logic gate analysis on battle network 4 after I posted the issue, which will be posted to the repository whenever I am free.