I've been looking at this code a couple of times, but I've never quite made the jump to implement this feature. My main interest is in adding support for local communication such as IPC to another instance or actually using the GPIO pins on a Raspberry Pi to talk to a real game boy.
This is orders of magnitude easier than networking, as game link is a synchronous protocol, which does not handle network latency of any sort. The way other emulators get around this is by pausing the emulator, which might be an invasive change... unless you just sit right there in the non-trivial-write function and do the blocking TCP transaction right then and there.
My main trouble with this code is that it appears to do some shifting of individual bits, but when I insert some print statements it always just does the whole byte. Is this just in case a well-timed read lands in the middle of a transaction?
The most simple API would be to just transfer a whole byte. But the more accurate API would probably handle individual bits, as the current code seems to do. The latter would be easy for a GPIO implementation, but disastrous for networking.
What you'd probably want is a class with several implementations (TCP, IPC, GPIO, etc.), which then need to be exposed as build options and selectable/configurable in the command line or GUI. In short, I'd like some input from the devs before I jump in and start writing code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it should be possible to only synchronise on actual changes, so that you may usually be able to transmit multiple bytes at a time -- speculative runahead with eventual rollback might also be worth investigating. It also may be a good idea to look at what other emulators have done (including eventual interoperability).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What do you mean "synchonise on actual changes"?
It's a full-duplex protocol, so if you send multiple bytes, what are you going to give as receive value?
Are you saying as long as the game does not read ff01, just pretend the transaction completed?
I'm not familiar with any other games besides Pokemon gen 1 and 2, but they do in fact transmit full-duplex. (I'm the author of http://pepijndevos.nl/TCPoke/)
This is what bgb does: http://bgb.bircd.org/bgblink.html
It could be worth trying to be compatible, but for my use case I'd like GPIO to a physical game boy (and maybe other implementations) to be supported too.
I wrote a Python script once to interface with bgb, but there seem to be some intricacies that caused bgb to pause after a while.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been looking at this code a couple of times, but I've never quite made the jump to implement this feature. My main interest is in adding support for local communication such as IPC to another instance or actually using the GPIO pins on a Raspberry Pi to talk to a real game boy.
This is orders of magnitude easier than networking, as game link is a synchronous protocol, which does not handle network latency of any sort. The way other emulators get around this is by pausing the emulator, which might be an invasive change... unless you just sit right there in the non-trivial-write function and do the blocking TCP transaction right then and there.
https://github.com/sinamas/gambatte/blob/b6ff2f24c144c1467380c4b3c149f4cdf087f73c/libgambatte/src/memory.cpp#L141
Basically I think it's as simple as adding a few well-placed calls here to read/write to an external source. The big question is what the API should look like, and how it would be exposed in the UI.
My main trouble with this code is that it appears to do some shifting of individual bits, but when I insert some print statements it always just does the whole byte. Is this just in case a well-timed read lands in the middle of a transaction?
The most simple API would be to just transfer a whole byte. But the more accurate API would probably handle individual bits, as the current code seems to do. The latter would be easy for a GPIO implementation, but disastrous for networking.
What you'd probably want is a class with several implementations (TCP, IPC, GPIO, etc.), which then need to be exposed as build options and selectable/configurable in the command line or GUI. In short, I'd like some input from the devs before I jump in and start writing code.
I think it should be possible to only synchronise on actual changes, so that you may usually be able to transmit multiple bytes at a time -- speculative runahead with eventual rollback might also be worth investigating. It also may be a good idea to look at what other emulators have done (including eventual interoperability).
What do you mean "synchonise on actual changes"?
It's a full-duplex protocol, so if you send multiple bytes, what are you going to give as receive value?
Are you saying as long as the game does not read ff01, just pretend the transaction completed?
I'm not familiar with any other games besides Pokemon gen 1 and 2, but they do in fact transmit full-duplex. (I'm the author of http://pepijndevos.nl/TCPoke/)
This is what bgb does: http://bgb.bircd.org/bgblink.html
It could be worth trying to be compatible, but for my use case I'd like GPIO to a physical game boy (and maybe other implementations) to be supported too.
I wrote a Python script once to interface with bgb, but there seem to be some intricacies that caused bgb to pause after a while.
*only synchronise on actual dependencies based on ff01/ff02 reads/writes (and buffer up as much as that allows for).