#17557 - Og_Readmore - Wed Mar 10, 2004 4:22 am
I am working on multi-player tunneling software for the GBA (much like Warp Pipe for the GC http://www.warppipe.com/), but I'm not sure of the connectivity offered by the GBA to PC connectors that are out there now. There has to be some way of fooling the GBA into thinking it is connected to another GBA and then you would have to capture the gamestate info so you could send it over the Internet. Has anyone thought of this before? Any ideas as to which connectors to look into?
#17558 - poslundc - Wed Mar 10, 2004 4:37 am
A multiboot cable connects a computer's USB to the GBA's communication port. I know next to nothing about GBA multiplayer and even less about multiboot, but my guess is that would be your best bet, or at least a good place to start.
(Multiboot cables have the additional advantage of being widely available and relatively cheap.)
If you ever get a working product, talk to me about porting your software to Mac OS.
Dan.
#17559 - tepples - Wed Mar 10, 2004 4:53 am
The GameCube's protocol runs on top of a traditional Internet Protocol v4 network, and games expect latency typical of Ethernet; LAN connections have a latency in milliseconds. A GBA, on the other hand, requires latency in the tens of microseconds at best.
Emulators, on the other hand, would have an easier job implementing LAN multiplayer. You could use a TGB Dual style configuration, wherein each PC emulates all linked systems and the PCs exchange controller data each frame. VBA doesn't do this because 1. Forgotten's PC probably isn't fast enough and 2. Forgotten doesn't have the time to implement it. Under the GNU GPL, you're free to fork VBA and add link support if you want.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#17583 - Og_Readmore - Wed Mar 10, 2004 6:53 pm
Would there be anyway to extend the window for link communication? Could I make the GBA wait longer before "it drops the packet"?
#17598 - Lupin - Wed Mar 10, 2004 9:46 pm
what about just reading out everything that comes from the port, send it via internet to the other PC and then write it to the GBA port :)
You just have to find some way to read the port... anyway, such a tunneling software would be great!
#17612 - tepples - Thu Mar 11, 2004 2:44 am
| Lupin wrote: |
| what about just reading out everything that comes from the port, send it via internet to the other PC and then write it to the GBA port |
Proprietary GBA games that use a normal multiplayer link wouldn't tolerate the latency. To make the GBA wait longer, you'd have to write your own games designed specifically to work with the tunnel. No, I can't help you patch existing proprietary games to work with a given tunnel.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#17645 - kma - Thu Mar 11, 2004 8:47 pm
Well..I've read those post wich start with a great idea !...Then first answers with market's stuff with usb and alllll! But I think we mustn't buy something we can do! Furthermore usb port is quite hard to program (well that's what I believe 'cause i tried but maby i suck!). Then good stuff with the latency needed for propreitary games..are you sure? How do you know the latency about 1microsec?
I think that a good hardware solution is to use the serial com port (as it was use for old modem 56k it can be easy use with gba...:...the gba port is a serial port!) of your computer, wich is easly programmable .
For software ..couldn't a program emulate the pseudo-clock needed by proprietary games? I mean it could be done by player's computers or by a server...
I'd like to bild a video to gba card and i need informations about stuff we can find in a tv and/or videocard (cf video and gba in beginners). I know that, if some only thinks buying, others keep their "macgyver spirit" ;)
#17653 - ampz - Thu Mar 11, 2004 11:13 pm
The GBA port in normal com mode is syncronous and bidirectional. That makes it impossible to tunnel it over anything.
1microsecond is accurate. The bitrate is 256kbit/s.. That is ~4microseconds for each bit. The turn-around latency _must_ be less than that. Preferably less than half of that.
#17669 - Og_Readmore - Fri Mar 12, 2004 5:03 am
Could you use keep-alive signals from the computer that is doing the tunneling? Maybe this wouldn't work for a game like Doom, but for something turn based like Advance Wars I don't see why this would be a problem. Keep-alive signals are used in networking all the time, why couldn't they be used here?
#17670 - poslundc - Fri Mar 12, 2004 5:07 am
Sure, you could use keep-alive signals in a game that you write. Unfortunately, most GBA games have already been written, and they were not written with forward-compatibility with a slower communications signal in mind.
Dan.
#17671 - Og_Readmore - Fri Mar 12, 2004 5:21 am
I see. This doesn't bode well for me guys. I am doing a project on this for my computer architecture class..... looks like I'm going to have to fake something.
#17675 - tepples - Fri Mar 12, 2004 9:16 am
All you have to "fake" is that you will have to write your own air-hockey game or something that's designed to run over a tunnel.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#17679 - Lupin - Fri Mar 12, 2004 3:16 pm
why are you all that sure about the latency rate? Maybe some commercial games don't have it... You should first of establish a basic connection and send something using your own rom and then if it works, just try with commercial roms, i don't think that every rom will have the latency check...
Well, this sounds really interesting to me, post it if you have something useable :)
#17682 - poslundc - Fri Mar 12, 2004 3:48 pm
| Og_Readmore wrote: |
| I see. This doesn't bode well for me guys. I am doing a project on this for my computer architecture class..... looks like I'm going to have to fake something. |
Why do you have to fake anything? Build the connector and present your findings as to why it won't work with most games. But then write a quickie program to show that it does, in fact, work.
Dan.
#17690 - ampz - Fri Mar 12, 2004 6:02 pm
| Lupin wrote: |
| why are you all that sure about the latency rate? Maybe some commercial games don't have it... |
Because the "normal" communication mode is synchronous and bidirectional. If you know a little about hardware, then you know that no latency can be added to this type of connection. Because the max total latency is the length of the clock period.
The GBA port can however be set to operate in UART mode. This communication mode can be tunneled over internet. (In fact, there are already programs available for this).
Problem is, all commercial games use the "normal" communication mode.
#17730 - kma - Sat Mar 13, 2004 3:09 pm
I don't know why it would nt be possible to have a Synchronous interface with a computer. Just have to use a Synchronous to Asynchronous converter (pic for exemple) which will make the clock signal you talk about ampz...but i'm pretty sur that usefull data for games are not needed every 4 microseconds...I agree with he fact that you'll obvously need to know the source of the program to "emulate" it...
Good luck!
#17733 - ampz - Sat Mar 13, 2004 4:44 pm
The fact that it is synchronous is not the problem.
The problem is that it is synchronous AND bidirectional. One bit is sent while another bit is recieved _simutaneously_.
#17754 - Cyberman - Sun Mar 14, 2004 5:28 am
| ampz wrote: |
The fact that it is synchronous is not the problem.
The problem is that it is synchronous AND bidirectional. One bit is sent while another bit is recieved _simutaneously_. |
Depends on the synchronise protocol used as well. I doubt they are using anything like CAN looked to me like SPI or microwire. If the latter two are the case, timing on a byte for byte basis can be critical depending on how the device is setup. There are a few USB chip manufacturers that make a USB USB 2.0 compliant chips with a synchonise serial interface that can perform these tasks. Then the issue becomes one of the responsiveness of the program forwarding data on the PC and the network.
Making an emulator support this is something Forgotten I think has skiped because mutliboot etc is very complicated and difficult to impliment.
Timing is of the essence, and it depends on the game as well. If most of the 'game' commands are issued asynchornisely over a synchronise bus, a little flexibility is there, if you have 4 programs operating simultaneously and want to see the EXACT same thing fed to each console, it won't work too well over anything less than a LAN, and if you have a high traffic LAN, forget it.
A skew of 16 to 33ms is likely more than sufficient. Namely those are often the number of times the display and game dynamics are updated.
Cyb
_________________
If at first you don't succeed parachuting is NOT for you.
#17763 - ampz - Sun Mar 14, 2004 1:37 pm
No, you don't get it.
It is not a bandwidth issue USB/LAN/... is irrelevant. And no, CAN is not a synchronous bus.
Yes, the synchronous transfer is similar to SPI. But you don't get the problem:
[Images not permitted - Click here to view it]
The CK and SO signals are driven by the master (player 1). SI is driven by the slave (player 2).
In this example, the data byte 0x05 is transmitted by the master to the slave while the slave transmitts the data byte 0xA0 to the master.
Each bit is read by the master and the slave on the rising edge of CK (marked with red arrows)
This simutaneous synchronous transmission of data in both directions is not possible to emulate if any latency is added.
When the master signals that a bit is to be transfered (by toggling the CK signal) the slave _must_ make the bit available on the bus before the CK line goes high. About 1 microsecond that is.
Last edited by ampz on Tue Mar 16, 2004 10:43 pm; edited 1 time in total
#17808 - Cyberman - Mon Mar 15, 2004 4:05 am
| ampz wrote: |
No, you don't get it.
It is not a bandwidth issue USB/LAN/... is irrelevant. And no, CAN is not a synchronous bus.
Yes, the synchronous transfer is similar to SPI. But you don't get the problem:
[Images not permitted - Click here to view it]
The CK and SO signals are driven by the master (player 1). SI is driven by the slave (player 2).
In this example, the data byte 0x05 is transmitted by the master to the slave while the slave transmitts the data byte 0xA0 to the master.
Each bit is read by the master and the slave on the rising edge of CK (marked with red arrows)
This simutaneous synchronous transmission of data in both directions is not possible to emulate if any latency is added.
When the master signals that a bit is to be transfered (by toggling the CK signal) the slave _must_ make the bit available on the bus before the CK line goes high. About 1 microsecond that is. |
I understood perfectly the first time, however it depends on how the hardware handles data. IE what data has to be exchanged. It's still possible to do as long as you know that you can send bogus fake or data that causes no changes back. This looks more P2P though. Are all the game systems daisy chained with this?
As in...
Master O -> Slave 1 in Slave 1 out -> Slave 2 in Slave 2 out -> Master In
I think the real problem deals with what's returned by the slaves. If it's daisy chained like this it would take 4 byte transmits to rescieve a response from each unit. I personally don't know enough of what is being sent at the low level to say yes you are right or no you are wrong. My initial guess is you are myopically looking at the problem. Yes you have to respond within microseconds that's a given, however I don't see that as a problem to be honest. Bogus or data stuffing or repeating last sent is probably an adequate pacifyer tell real data can be transmitted :) How do GBA games keep up? they are faced with the IDENTICAL problem unless the hardware directly maps the input information to the multiboot interface (which I doubt it would do, it's more likely to have a 'send when data is requested register which is QUITE easy to handle with the toys I mentioned).
Cyb - let's see what's up with it more before we draw conclusions that's my stance :)
_________________
If at first you don't succeed parachuting is NOT for you.
#17810 - torne - Mon Mar 15, 2004 4:48 am
| Cyberman wrote: |
| How do GBA games keep up? they are faced with the IDENTICAL problem unless the hardware directly maps the input information to the multiboot interface (which I doubt it would do, it's more likely to have a 'send when data is requested register which is QUITE easy to handle with the toys I mentioned). |
Nope, the hardware makes all data available as soon as it is received. No clever tricks, no asynchronous behaviour. If you don't read them before the next data arrives, you lose it. Thus, GBA games that use multiplayer *are* in a strict timing loop driven by serial interrupts. Specific game protocols may tolerate dummy data at certain times, but I would be suprised if you could find any game which did not require fully synchronous communication at *some* point.
#17840 - Miked0801 - Mon Mar 15, 2004 6:40 pm
At some point being at least twice a gameloop First for all data received ok because checkusms and error checking code says good. Second for all systems have moved to next loop you need to go as well.
![[Images not permitted - Click here to view it]](http://www.brolinembedded.se/misc/GBA_serial.png){kind=link}
![[Images not permitted - Click here to view it]](http://www.brolinembedded.se/GBA_serial.png){kind=link}