It is the intention that this protocol keeps being used, with negotiation for new features as necessary, to maintain back and forward compatibility with older BGB versions (>= 1.4) and 3rd party implementations. If this is no longer possible, the protocol version will be changed, and compatibility broken.
bgb game link works over TCP/IP. one side listens, the other side connects. When the initial handshake is complete, until the connection is broken, a plugged in link cable is emulated.
The TCP_NODELAY setting should be set on the socket to avoid extra delays in the OS. Also, keep in mind that due to the nature of TCP, packet boundaries are not guaranteed: multiple commands may be in a single TCP packet, and a command may be split over multiple TCP packets.
When individual bits are referred to, bit 0 is the lowest bit. Literal values are decimal, or $ prefixed hexadecimal.
All communication is in the form of 8 byte packets.
ofs size description 0 1 b1, command 1 1 b2 2 1 b3 3 1 b4 4 4 i1, timestamp (little endian)
b2=1 b3=4 b4=0 i1=0
Any bits and fields other than the ones used for a purpose MUST be 0 when sending, and MUST be ignored when receiving.
b2=joypad change bit 0-2: button number bit 3: 1 if button is pressed, 0 if button is released bit 4-7: 0 (due to a bug in previous bgb versions, these bits can't be used in the future and must remain 0) b3=0 b4=0 i1=0
b2=data value. b3=control value. bit 0: 1 bit 1: high speed bit 2: double speed bit 3-6: 0 bit 7: 1 b4=0 i1=timestamp
b2=data value b3=control value, $80 b4=0 i1=0
Sent in response to a received active transfer when not doing a passive transfer:
b2=1 b3=deprecated b4=deprecated i1=0A synchronization (sending timestamp) that is not a transfer:
b2=0 b3=deprecated b4=deprecated i1=timestamp
b2=flags bit 0 ($01): statusflag_running: is running bit 1 ($02): statusflag_paused: is paused bit 2 ($04): statusflag_supportreconnect: support automatic reconnect and "wantdisconnect" (new in BGB 1.5.2) b3=0 b4=0 i1=0
Used to indicate to not automatically reconnect after the connection is broken, for user initiated disconnect. All fields must be 0 on sending, and must be ignored on receiving
Usage of this command depends on having seen statusflag_supportreconnect set in a "status" message in this session:
If YES: On a user initiated disconnect, one SHOULD send the "wantdisconnect" message. If the link was broken without having seen a "wantdisconnect" message, one MAY automatically reconnect. If the link is broken and the message was seen, one MUST NOT automatically reconnect.
If NO: One MUST NOT send the "wantdisconnect" message. If the link is broken, one SHOULD NOT automatically reconnect.