-
-
Notifications
You must be signed in to change notification settings - Fork 750
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Battle Chip Gate Compatibility (via third-party tools) #3212
Comments
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
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. |
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. |
I am really interested on this. Is this now possible using the scripting API? |
DeCoded-Void/DIY-Megaman-Battle-Chip-Gate 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. |
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:
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.
The text was updated successfully, but these errors were encountered: