Uze <3 Wiznet?

[D3thAdd3r]

I'd have to look but there should be an open source version of kaillera. The protocol is simple and >1000 people are using it right now to play these kinds of games online. I am pretty sure we can use RedPine it is just that the documentation is restricted? I just happen to have such documentation from an anonymous source anyhow. Now I just need hardware knowledge

[uze6666]

So what we want to do is to make a plug-in for the joystick ports, which contains an ethernet chip + attiny. Right?

Yes, that right. *Ideally* it should provide the Uzebox game a transparent interface to the dongle for regular Ethernet or WIFI. What I was thinking is that the dongle's MCU would handle the link configuration showing only a plain socket API to the Uzebox kernel. A special .HEX tool would be used to configure the WIFI stuff and store it in the EEPROM of the dongle. Anyway I say ideally. At this point, I'd say let's make it work with the WIZ820io (which I just ordered two ).

Do I understand right, if I think you mean that we will use the existing serial lines of the joystick ports? That we read the joysticks as usual, bitshifting, and then realize that the joystick is a uzenet-device. And then switch the direction of the DATA line to send data to the uzenet device? And switch direction back to receive, and so on?
Or did you mean that we would do hardware modifications, adding more pins to the joystick ports on the uzebox?

No hardware modifications to the consoles. We should not change pins directions (2 of 3 are shared between the two controller anyways). Here's a napkin quality idea of how the interface could look like:

This implies some sort of custom protocol between the uzebox and the dongle. In this design, having the SNES latch line active while clocking would be a special condition to indicate the ATiny to switch to "Ethernet mode". After that, the Latch line becomes functionally equivalent to the SPI MOSI pin, while the DATA line becomes the MISO line.

After reading more about it I'm all in for UDP for games in general. Some applications may (and will) need more reliable request/response, so TCP will have to work too.

As I said. If you do not want to use a central server, you could just install the server software on your computer, and then open NAT ports in your local router, and then the other guy could connect to you, by reconfiguring his "uzenet-stick".

I'm definitively seeing a central hub/server, only if it were to initially connect to and obtain/discover the IP of the current "game server" or the peers. In this case uzebox.org would seem the perfect place for this. Otherwise how can we put "Uzebox game servers" on fast nodes on the internet...without cost?

RedPine won't help you with NAT if you are going to connect client to client. In that case it needs to connect to a server. And you need to type in your opponents ip-address, etc. It would be very un-user friendly, imho. Also, uze6666 said that you need to sign an NDA to use RedPine, so I think it's out of the question.

Well, they can't prevent one from using their device freely sold on the open market and reverse engineering is usually legal. An interface library designed from scratch with 100% original code should not cause any issue, specially for a non profit project. That said, I agree that this makes RedPine look not so nice with their stance although they have a great product.

[lunatic]

So what we want to do is to make a plug-in for the joystick ports, which contains an ethernet chip + attiny. Right?

Yes, that right. *Ideally* it should provide the Uzebox game a transparent interface to the dongle for regular Ethernet or WIFI. What I was thinking is that the dongle's MCU would handle the link configuration showing only a plain socket API to the Uzebox kernel. A special .HEX tool would be used to configure the WIFI stuff and store it in the EEPROM of the dongle. Anyway I say ideally. At this point, I'd say let's make it work with the WIZ820io (which I just ordered two ).

Yes, then we agree. But I'm thinking, even something simpler than a socket api? Just an internal game-api. Where your only concern is to send data to your opponent, and receive data from your opponent. The attiny handles all socket/udp/retransmission, acking of packets, etc. So a pretty "high level" api. So uzebox doesn't know if it is a WIFI, or if its a WIZnet, or a ENC, or RedPine chip that is located in the game port. Only that it's a network-gaming device with a high level api.

Here's a napkin quality idea of how the interface could look like:

This implies some sort of custom protocol between the uzebox and the dongle. In this design, having the SNES latch line active while clocking would be a special condition to indicate the ATiny to switch to "Ethernet mode". After that, the Latch line becomes functionally equivalent to the SPI MOSI pin, while the DATA line becomes the MISO line.

I thought maybe that uzebox should "autodetect" the dongle before the user is prompted with multiplayer-options. But you're right, thats not needed. We could just try to initialize the attiny when the user selects multiplayer in the game menu. And give an error if we cannot get data from the attiny.

As I said. If you do not want to use a central server, you could just install the server software on your computer, and then open NAT ports in your local router, and then the other guy could connect to you, by reconfiguring his "uzenet-stick".

I'm definitively seeing a central hub/server, only if it were to initially connect to and obtain/discover the IP of the current "game server" or the peers.

So you do not want the actual game traffic to go through the game servers? We could try without this. But I know NAT is a bitch, and it might be very much problems with one-way-communication if we only post the ip-address of the peers. Not all routers automatically open a reverse udp-forward when you send udp traffic out on the net via a NAT router.

So thats why I was thinking of having several servers, as close to the users as possible, and probably better uplink between countries than your home-isp. And then send traffic through them. This works well with big pc games like Counter-Strike etc, which are relying a lot on low latency.

In this case uzebox.org would seem the perfect place for this. Otherwise how can we put "Uzebox game servers" on fast nodes on the internet...without cost?

My initial thought was to use DNS to add all the available "fast nodes" available on the internet. But I don't know how advanced DNS service you are using. One way would be to set "server.uzebox.org" to point to all the ip-addresses of the "main servers". And have the dongle ping all the servers to find a suitable one.

RedPine won't help you with NAT if you are going to connect client to client. In that case it needs to connect to a server. And you need to type in your opponents ip-address, etc. It would be very un-user friendly, imho. Also, uze6666 said that you need to sign an NDA to use RedPine, so I think it's out of the question.

Well, they can't prevent one from using their device freely sold on the open market and reverse engineering is usually legal. An interface library designed from scratch with 100% original code should not cause any issue, specially for a non profit project. That said, I agree that this makes RedPine look not so nice with their stance although they have a great product.

Sure, but I would not myself use RedPine as a starting point, I'd rather search for a more open choice, unless it has a crazy low price. I'll order a WIZ820io to start with myself, if I just find a close distributor. But we'll have a easy API that we will make via the attiny, and then more people can make several network-dongles based on different chipsets if they want.

[uze6666]

Yes, then we agree. But I'm thinking, even something simpler than a socket api? Just an internal game-api. Where your only concern is to send data to your opponent, and receive data from your opponent. The attiny handles all socket/udp/retransmission, acking of packets, etc. So a pretty "high level" api. So uzebox doesn't know if it is a WIFI, or if its a WIZnet, or a ENC, or RedPine chip that is located in the game port. Only that it's a network-gaming device with a high level api.

We are saying the same thing I think. A hi-level game API is good idea from the point of view of game and I'm all for it. However I'd see it sit on top of a socket API for flexibility. I already have in mind a couple cool apps I always wanted to do like a twitter and RSS feed reader, a chat gui and other web related interfaces. That would need a socket API and a generic one that would communicate with the dongle though a generic protocol that doesn't care about the module type on the other side. The Attiny would be responsible to translate. The protocol should allow for "custom/extension" commands if we want to make a custom .HEX file to configure the dongle's specific module.

I thought maybe that uzebox should "autodetect" the dongle before the user is prompted with multiplayer-options. But you're right, thats not needed. We could just try to initialize the attiny when the user selects multiplayer in the game menu. And give an error if we cannot get data from the attiny.

Well, yes, some form of autodetect could be implemented. Could work similarly to the SNES mouse protocol.

So you do not want the actual game traffic to go through the game servers? We could try without this. But I know NAT is a bitch, and it might be very much problems with one-way-communication if we only post the ip-address of the peers. Not all routers automatically open a reverse udp-forward when you send udp traffic out on the net via a NAT router.

You're right, my brain finally got it. Traffic would have to pass to a central server to avoid the hassles you mention. The problem is having such a server. The cheapest Virtual private server services I could found was around 15$ a month. Is there other solution to a VPS where we can deploy any application using any ports?

I'll order a WIZ820io to start with myself, if I just find a close distributor. But we'll have a easy API that we will make via the attiny, and then more people can make several network-dongles based on different chipsets if they want.

Btw, do you have a Uzebox/Euzebox? If not, I have a ton here waiting to be given for such work. PM me you address, I'll ship you one for free. Like that we could use the expansion port and use a plain and easy SPI interface to get the grips of the module before digging into the dongle stuff.

[uze6666]

Well, we now have a central server, at least for a couple months. I was curious about cloud stuff for a while a decided to check just how simple it is to get you own virtual private server. Quite fast and easy in fact. In 15 mins, I had registered with the host, choosed my OS (Ubuntu) and memory, paid and voila, 5 mins later I had my very own server in the cloud. I'm root admin on the "box" so I can do whatever I want, pretty cool. Already installed GCC, Java, SVN and other tools. Better yet, it's now binded to "uzebox.net"!

Ping is pretty good in north america, much slower in the EU. Check you location: http://cloudmonitor.ca.com/en/ping.php? ... ping=start

[lunatic]

Cool

And I have access to severs both in norway and in UK. We could host there too. I could add a user for uzebox so you would have access too.

Check the prices at linode.com too. They offer cloud servers at cheap prices, and specializes in linux.
I use them, and love them

[uze6666]

Yeah I check linode too, Rackspace was a couple $ less per month, so I picked it for now...

[lunatic]

No hardware modifications to the consoles. We should not change pins directions (2 of 3 are shared between the two controller anyways). Here's a napkin quality idea of how the interface could look like:

This implies some sort of custom protocol between the uzebox and the dongle. In this design, having the SNES latch line active while clocking would be a special condition to indicate the ATiny to switch to "Ethernet mode". After that, the Latch line becomes functionally equivalent to the SPI MOSI pin, while the DATA line becomes the MISO line.

As far as I know, the DATA line is individual for the game ports. So changing the direction of this pin, should be just fine?

I just thought, if some SNES controller hack. Like the wireless controller maybe doesn't like you to fiddle with the latch line (which is shared with both controllers, right?).
Then the approach of changing direction of the DATA line would be much less intrusive.

But thats just a thought. I guess it should be pretty bad design if something breaks because of "out of order" toggling of the latch pin. But since some guy said he had problems with the wireless controller, I thought maybe there is some 3rd party controllers that are designed so bad that we should take as less intrusive way as possible.

Also it would be possible to read the controller while we transfer data to/from the uzenet dongle, but I guess it is clocked so fast that a person wouldn't be able to click in between transmissions.

I have started designing some ideas for the protocols between the uzebox and uzenet dongle, and a uzenet udp protocol. My initial documentation consists of writing the server while I figure out the protocol, as I will come up with problems and fixes easier this way. I'm trying to keep it very simple, and low amount of bytes, for speed and simplicity of the dongles and uzebox communication.

The idea is that the uzenet dongle will have a simple api to find servers, and connect to them, and send joypad data, and simple extra data blobs. We might try udp hole punching first, and fallback to "through server" if there are problems. This could be up to the dongle-implementation to decide.
And also a socket API for normal sockets. (UDP/TCP).

And about that. You said we would want to have access to real sockets via a custom socket api between uzebox and uzenet. Is it enough to support 1 socket of UDP/TCP? Or should we have support for more than one socket concurrently? I guess the WIZ820io device for example, has support for 8 concurrent connections/sockets. But I think this will complicate the API a lot. And this will make it harder both to use it in your uzebox game/app, and to develop new dongles with other "chipsets".

What do you think?

[stache]

Hi Guys, I was just over at hackaday and read an article about someone who was working on a similar ethernet adapter for the SNES system. From what I can tell the implementation looks similar to what you guys have been discussing, so I thought I would post the link to the article. Enjoy and keep up the great work!

hackaday article: http://hackaday.com/2013/09/14/snesoip- ... ore-102895
github project: https://github.com/mupfelofen-de/SNESoIP

[lunatic]

I have not had very much time for Uzebox lately. I'm suddenly a father of two kids and stuff P

But I have time to time been thinking of this network idea. And as far as I can remember, the last state is that I pushed some network code to the repository (for the server side). But on the client/uzebox side, we never did decide on how to progress.

As for the first dongle design, I have some thoughts.

I have been using the W5100 chip with arduino for a project at work. This chip has one giant flaw. In raw or udp mode, it dies randomly, and needs to be hard-reset to continue functioning. It suddenly hangs while you wait for response from the chip. So all the W5100 arduino shields is also flawed, since they share the reset line with the main processor. (Which is of course moddable, but if you buy the "Arduino Ethernet", which is arduino+ethernet on a board. It's hardwired in the circuit board. (just mentioning in case we would make a "make a network-dongle with a arduino board" project, it could be a cheap first-intro to ethernet dongles for uzenet)

So pro-cons for different chips:

W5100
- Cheap arduino boards, also easy to buy chip in bulk on ebay.
- UDP/Raw is flawed, must use TCP
- Easy usage, tcp stack inside chip, no need to build ethernet frames. (layer 3 abstraction inside chip)
- SPI speed: 4mhz

ENC28J60
- Cheap, easy to buy in single/bulk
- Needs a lot of ram/progmem for handling IP/TCP (its a layer-2 chip)
- Since you work with layer2, UDP is quite simple, just read the ethernet packets, and extract data, etc.

W5200
- A little more costly arduino boards, harder to find. Should be easy to buy in bulk though.
- UDP/TCP should be simple
- Very fast SPI bus (up to 80mhz)

The SPI speed is irrelevant to this project though, since the bottleneck would probably be the latency of the internet-connections. But I think maybe it would be easiest to make the first network-dongle by using arduino hardware, as they tend to be cheap. And I do have a lot of extra arduino boards and ethernet shields lying around. (With all the mentioned ethernet chips).

W5100 is kind of out of the question of we want to be able to do P2P data transfer, because of the way NAT'ing works. I would like to keep away from needing people to alter their routers to add nat rules to be able to play p2p. And doing upnp with router adds a alot of code and memory/progmem usage of dongles. And upnp is not enabled on routers that often either, by experience. So the best bet would be using UDP, since most NAT routers open ports when you "port-knock" with udp. This means that clients that want to play together talk with our server, and the server disclose the ip address and ports of the clients, and they send packets towards eachother, "knocking a hole" in their firewall, letting the packets flow in both directions. They would need to send a "idle" packet at regular interval to keep the hole/connection open.

So the best bet without having to modify anything would be the two other chips.

I'm not sure about the price of the chips i mentioned, I'm currently sitting on the train to work, and the train has a bad internet connection. So I took the price "comparison" from the top of my head. I might update this post later, when I have done more digging. I just wanted to post this to check if there is still some interest in this project.