Link cable support

[Shatur]

I saw this was mentioned in #94, but the issue was closed.
So I decided to open a dedicated issue.
I'd love to contribute, but I don't have enough experience with embedded. Maybe someone else will be interested 🙂

[0xdeadd0d0]

Hi, i was going to create a ticket for this but you did it before me, the ticket can be assigned to me if you want ^^
I already started the link cable support, i have a good background in embedded, i'm using agb to learn Rust.
I'm starting by the serial multi player mode, then i think i will try to add the others modes supported by the hardware 🙂

[Shatur]

Great!
If you want testing - ping me, I'll try your branch 🙂

[gwilymk]

Sounds awesome!

Our eventual ideal with multiplayer support is to have a unified API for both the wireless adapter and the wired link cable. But we've stalled on the API design since neither of us have any experience writing multiplayer games yet.

We're happy to make changes to agb to support a library to be built on top of it for multiplayer while you experiment with APIs and usage? Then once the API looks good and solid, we can push it into the main agb crate?

But I think this will require a bit of experimentation to see what the API should look like and to make a game which uses it to prove out that the API works in practice too since multiplayer is one of those relatively awkward. With this and the async support, would it make sense to have an agb-nursery repo or similar which has less branch protection to allow you to put the changes there without us needing to keep it up to date with the latest clippy lints / compiler updates until it's all ready to go?

[Shatur]

We're happy to make changes to agb to support a library to be built on top of it for multiplayer while you experiment with APIs and usage? Then once the API looks good and solid, we can push it into the main agb crate?

I maintain a high-level networking crate https://github.com/simgine/bevy_replicon, which supports no_std (we even test compilation on CI for thumbv6m). The crate is built for Bevy, but the engine can also be used on the GBA through https://github.com/bushrat011899/bevy_mod_gba (which uses agb under the hood).

My crate doesn't include any I/O. Instead, it relies on various backends. To make it work with agb, I only need the ability to send and receive bytes (no async needed). Once that's available, I can implement a backend for it (about 200 lines of code or so), and all high-level functionality will work.

[gwilymk]

If the only thing you need is the ability to send and receive arbitrary bytes, then, given that agb doesn't currently use those registers and there won't be any worry about it overwriting the values you set, you can do something similar to the gba_rumble crate. So something similar to the bevy_mod_gba crate could be done to provide the underlying logic.

Not sure how that looks while interacting with the wireless adapter though? I assume it would need to make some connection first and then pass it over as the backend for the replicon crate?

One of the annoying things about the state of multiplayer on the gba currently is that there isn't great support for playing over the network in emulators with friends. So you'd either need to both be in the same location with physical consoles (and rust isn't the best for writing multiboot applications so you'd both need flash cards or similar) or running on the same computer with some strange input set up. Hopefully in future, emulators will give us the ability to really play multiplayer, but that's be the main reason for the lack of motivation from our part to get stuck into this so far.

We'd love a nice API for managing this though since if it's easy to add networking to any game, then you're incentivised to do so which makes more multiplayer games which is always nice!

[Shatur]

I probably phrased it poorly. Yes, I could work with the registers directly, but I assume there's some protocol.
So I'll need an abstraction provided by agb where I can read and write messages (probably "bytes" was the wrong word, but messages are in bytes form), and also have connection information (assuming such exists). Essentially, I'm looking for a HAL. I assume that's what @0xdeadd0d0 is working on. Most networking crates provide an API like this.
This way users will be able to send and receive arbitrary data. The data usually encoded with something like serde and a binary format like postcard.

For a more high-level API (such as automatic state replication) agb is a bit low-level. This is where Bevy comes in. Once we get the messaging API, I'll wrap it for a nice access in bevy_mod_gba and create bevy_replicon_gba crate that pipes messages with connection information from to bevy_replicon.

Yeah, I hope emulator support for networking in GBA improves in the future 🙂

[0xdeadd0d0]

@gwilymk yes i agree this will require a bit of experimentation to see what the API should look like. My idea is to start with a low level api (kind of hw driver) internal to agb to do all the basics operations supported by the serial link (multi player mode / SPI / UART). Then use it trough an abstraction layer so we can make one API for serial link and wireless link).

My plan is to focus on the serial multi play mode. That include:

• Low level api (init, blocking / async transactions, master/child's handling, interrupt, ...)
• abstraction Layer (Connect/disconnect, Number of players connected, send/receive async or blocking, get_player_Id, ...)

I already started the low level api to access the registers and configure the serial in multi player mode

For the multiplayer abstraction I look at what has been done with the save to abstract sram, eeprom and flash. But i don't know if this pattern can work for the multiplayer use case. If you have any advice on how to do the abstraction in agb you can tell me :)

@Shatur , Yes i think what you need is the abstraction layer

[Shatur]

Yep, that's exactly what I need and your approach seems reasonable to me 🙂

[0xdeadd0d0]

Hi @Shatur

i have a first working draft if you want to have a look 🙂: https://github.com/0xdeadd0d0/agb/blob/feature/serial/agb/examples/serial_basic.rs
There is still a lot of stuff to do and API will move.
The m-gba emulator is really not accurate for the Serial multi play mode, i have to continue the dev on real hardware. But the serial link support looks better on the top of master of the repo mgba, my example only work on the top of mgba.

[Shatur]

Looks awesome!
Are you planning to provide an API to send a slice of bytes (instead of just u16) or do you think the GBA hardware won't be able to handle something like this?
I developed bevy_replicon for modern hardware, but since it's no_std, it's fun for me to try to run the library on something like GBA. Not very practical, of course 🙂
Looking forward to the API stabilization, I'll definitely play with it.

[0xdeadd0d0]

Yes exactly, the u16 is specific to the serial multiplay mode. The user shall not deal with this limitation. The user API is not freeze at all. I think only the sync() function will not move. ^^
Now i have the plumbing my priority is to have good perf and a stable communication on real hardware :)