Play DC link cable games online - testing needed

[Xerxes3rd]

Got a capture from VO:OT! Baud rate is 260416, 8N1, no flow control. This capture is during gameplay- it looks like each system sends a 14-byte transmission at 60Hz; each is offset by 8ms. This likely means that it's sending a packet each display frame.

Gameplay, single "packet":

I also did a capture during the initial "handshake" and it looks like initially it's doing a request/response- probably the DNA system is requesting info from the RNA system. The RNA system responds very quickly- 114us on the captures I did. This could be why connecting can be iffy when sending the data over IP. The space between packets from a single system is still 16.66ms, so the same 60Hz rate. All the packets look like they're 14 bytes in length.

Handshake:

[Xerxes3rd]

Next up, Sega Tetris. This one is indeed strange, but I'm not sure it's using break conditions- it looks more like it might be using inverted logic, instead of the normal "active low" of UART.

It's possible that they're not driving the lines in UART-style communications at all, but instead basically bit-banging something. This is why the USB-Serial stuff won't work unless you can somehow put the PL2303 (or similar) into an inverted logic state. I tried this with the Pulseview UART decoder and it hasn't yielded anything yet.

[Xerxes3rd]

Some more general musings about Tetris:
- It looks like the shortest time between edges is 7.5us, which seems to happen at the start of a transmission. Following that, the shortest time between edges is 9us
- If this is being bit-banged (like the SPI driver does in KallistiOS), the total time for a transmission seems to be about 1521us- divide this by 9 and you get 169. If you assume this is the number of bits and the first bit is a start bit, that gets you 21 bytes (168/8 = 21)
- It appears that Tetris supports 4 players (2 per console), and it looks like there's space for player 2 after the player 1 transmission (assuming each transmission is for a single player)

@flyinghead - Do you happen to have any dumps of how Tetris accesses the SCIF registers? Looking at the KOS source here: https://github.com/KallistiOS/KallistiO ... scif-spi.c it looks like direct register access will let you control the lines directly, which could be what Tetris is doing.

Edit: the bitrate of this is pretty close to 115200, but not exactly.

[Xiden]

Some more general musings about Tetris:
- It looks like the shortest time between edges is 7.5us, which seems to happen at the start of a transmission. Following that, the shortest time between edges is 9us
- If this is being bit-banged (like the SPI driver does in KallistiOS), the total time for a transmission seems to be about 1521us- divide this by 9 and you get 169. If you assume this is the number of bits and the first bit is a start bit, that gets you 21 bytes (168/8 = 21)
- It appears that Tetris supports 4 players (2 per console), and it looks like there's space for player 2 after the player 1 transmission (assuming each transmission is for a single player)

@flyinghead - Do you happen to have any dumps of how Tetris accesses the SCIF registers? Looking at the KOS source here: https://github.com/KallistiOS/KallistiO ... scif-spi.c it looks like direct register access will let you control the lines directly, which could be what Tetris is doing.

Edit: the bitrate of this is pretty close to 115200, but not exactly.

Do you have access to Discord? The best way to contact flyinghead would be there https://discord.com/invite/X8YWP8w here's the invite link

[deluxux]

I built a "Crossover" serial link cable using the same "DC SD Adapter V2" devices that it looks like you're using. F355 worked fine, but VO:OT connects and works fine until the match starts, then it says "The Dreamcast VS Cable has been disconnected." Anyway, the next step is to add a logic analyzer to the setup to see actually what's happening on the wire, specifically with Tetris.
F355.jpg
VOOTDis.jpg

whoh dude what is that blue console? looks cool

[Xerxes3rd]

whoh dude what is that blue console? looks cool

Thanks, it's what I call my "CRTreamcast" - it's a 10" iPad display and a Dreamcast, stuffed into a shell that I designed and printed. Here's the thread I put over on BitBuilt: https://bitbuilt.net/forums/index.php?t ... case.6536/

I'm actually just using it as a display in that pic because on the DC inside there, I didn't leave access to the serial port! If this all works out though, I'll probably end up soldering in an ESP32 to handle the serial comms.

[Xerxes3rd]

For those interested, here are a couple more captures of Aero Dancing.

Aero Dancing F (28800 baud):

Aero Dancing i (38400 baud):

Interestingly, both these send packets every ~33ms, so they may be running internally at 30FPS.

Also, it looks like none of these games use hardware flow control, meaning that a serial link cable only needs 3 wires: Tx, Rx, and GND.

[Xerxes3rd]

Also, baud rates for all serial games (all are 8N1, no flow control):

• VO:OT: 260416
• F355: 223214
• Aero Dancing i: 38400
• Aero Dancing F: 28800
• Sega Tetris: 115200 with break conditions
• Maximum Speed: 223214
• Hell Gate: 57600

Sure would've been nice if they all used the same baud rate, but I guess that's asking too much!

Edit: I forgot about Maximum Speed (an Atomiswave game)! It uses 223214 baud, and one of the two consoles (probably the one set as "Master" in the options) sends pretty long strings of bytes (170 bytes or so at 60Hz) during gameplay. I assume it's sending a big "game state" message, and that occupies nearly half of the maximum available bits on the wire at that baud rate.

Edit 2: Finally did some Hell Gate captures, and it (of course) runs at a different baud rate- 57600. Like others said it doesn't really work anyway, but it should be supportable. It's handy that none of the games use flow control, so only Tx, Rx and GND are required for a link cable, and additionally 3.3v or 5v is available on the connector for microcontrollers.

[Xerxes3rd]

Alright, looking at this again with Flyinghead, it looks like Tetris is probably using 115200 and manual breaks in between every single packet. When doing serial to IP, the UART hardware will need to recognize the break condition and send this state over IP to the other side. Basically instead of just sending raw bytes, the IP protocol should include a status byte that has a bit indicating a break condition. The receiver should basically latch that break condition- in other words, if it's set, the receiver needs to hold its Tx line low until it gets another packet indicating that the break condition is "false".