Uzenet

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

uze6666 wrote: I was playing on my Nintendo DS the other day and noticed the wifi configuration is not part of the games but seems to be delegated to the BIOS which present a generic config screen.
One nice feature of the ESP8266 is that it is very easy to send a few commands in a dedicated rom to do that stuff, but more importantly if you remove power from it and power it up the next day it will automatically connect to the last wifi point it was connected to(and it can BE an access point while simultaneously having all the same capabilities, at least they say).
uze6666 wrote:More over, if the network interface differs between wifi or wired Ethernet, config will differ and more code/flash will be required. Which begs the question: In this era of wireless "internet-of-thing", do we care about wired Ethernet anymore? Do we agree to only go wi-fi? That will simplify things.
I have no experience with ethernet chips but I THINK we could have either version supported transparently. If it was a hassle I would be in favor of forgetting about wired and focus on wifi. I am convinced from online FPS play that wired does have a more consitant/lower latency, but if we have wifi working I doubt I would be interested enough to worry about making a driver for ethernet and I'd wager others feel the same.

Since we are discussing how settings, firmware, etc might work this is a hack I threw together for fun when relearning sockets got me frustrated. Just a concept, but I have a pretty good idea of how the module would do any of that with the master server already and it's less difficult than the actual Uzebox<->Module code. I thought, browsing for a game, doing settings, getting roms etc could all be done in a program. Then the helper MCU has all that and know which game we want so when we reset and load the game, the addon does it's thing transparently. Uzebox game just asks "are we connected" and blissfully eats the data it has no idea where is coming from.

PS. it's very quickly thrown together. If you get stuck just reload the rom to check out other stuff ;)
PPS. please anyone pull up a command prompt and type ping 104.128.230.11 -n 10 and let me know what your average latency is.
Attachments
browser.hex
(85.57 KiB) Downloaded 448 times
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

One nice feature of the ESP8266 is that it is very easy to send a few commands in a dedicated rom to do that stuff, but more importantly if you remove power from it and power it up the next day it will automatically connect to the last wifi point it was connected to
So once configured, it basically appears like a wired interface from a client perspective. That's perfect then. The redpine module worked the same. So we could simply have a dedicated config rom that you only run occasionally.
I have no experience with ethernet chips but I THINK we could have either version supported transparently. If it was a hassle I would be in favor of forgetting about wired and focus on wifi. I am convinced from online FPS play that wired does have a more consitant/lower latency, but if we have wifi working I doubt I would be interested enough to worry about making a driver for ethernet and I'd wager others feel the same.
With the preceding statement I agree. Though I'm pretty sure, wifi will cover our needs well enough. Moreover it's smaller, less expensive than any wired modules (no MagJack) and you don't need to be close to your router. What's not to like. :lol:
PS. please anyone pull up a command prompt and type ping 104.128.230.11 -n 10 and let me know what your average latency is.
I have 24ms in Montreal.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

uze6666 wrote:With the preceding statement I agree. Though I'm pretty sure, wifi will cover our needs well enough. Moreover it's smaller, less expensive than any wired modules (no MagJack) and you don't need to be close to your router. What's not to like.
I'm sold. Ethernet cable coming out of an Uzebox is ridiculous/annoying and where do you even put that port gracefully. I was the only devils advocate speaking up for it it, and I am against it so I'd venture that it wont happen :lol: Less variables to consider is better if we want to get this done.
uze6666 wrote:I have 24ms in Montreal.
That actually surprised me how low that is. Your data packet would hit that server(1gb/s in New York) before your frame was done rendering(if the 8266 is low latency as I hope). I am going to get the WIP master server up there for testing at some point.

I'd especially appreciate European/Australian users to report their ping :P

Edit-BTW I guess it's not hitting gigabit but I think it will be enough ;)
20141219_015211_resized.jpg
20141219_015211_resized.jpg (8.88 KiB) Viewed 8059 times
User avatar
Harty123
Posts: 467
Joined: Wed Jan 12, 2011 9:30 pm
Location: PM, Germany
Contact:

Re: Uzenet

Post by Harty123 »

Thats the result of my test
Ping_test.png
Ping_test.png (51.68 KiB) Viewed 8016 times
In my opinion Uzenet is a very good name ;-)

About the server: There are many cloud services for IoT devices available - some of them are free. Perhaps it's possible to use one of these services for our purposes...

I like also the idea of an additional module with integrated microcontroller to minimize the effort for the ATMEGA644. The Gamebuino uses a very interesting concept. They are using I2C for a local connection between several devices. It would be nice to use a similar concept for the Uzenet:

a) simple wired network (I2C or RS485) with simple protocols for local multi player session (e.g. expos)
b) additional module (compatible to a) with own micrcontroller for enhanced IP connections (Ethernet or wireless)...
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I am not sure what kind of latency we could expect with a free cloud service, but as long as it let you run a custom program it would work fine for the master server(there are no real important performance requirements for it). It could be there are cloud service that have really excellent latency too, worth looking into but I have that one sitting there doing nothing but running a doom2 server right now. I was hoping those photons would make it to Germany a little faster than that, but it's not too bad and would definitely be playable. I can't really think of a better location that is more centered geographically. Not sure if you guys have tried emulators online but I see no reason we can't match that performance. I have played mame32(Samurai Showdown 4!!) against people with 140 ping and it worked pretty well. Played a lot of SNES emulators and stuff with Kaillera which of course can only do padstates since those games weren't designed for it. 40 ping is the best but I think even 200 is ok for some games.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

About the server: There are many cloud services for IoT devices available - some of them are free. Perhaps it's possible to use one of these services for our purposes...
Interesting! Do you have some of those services names in mind?
I like also the idea of an additional module with integrated microcontroller to minimize the effort for the ATMEGA644. The Gamebuino uses a very interesting concept. They are using I2C for a local connection between several devices. It would be nice to use a similar concept for the Uzenet:
a) simple wired network (I2C or RS485) with simple protocols for local multi player session (e.g. expos)
b) additional module (compatible to a) with own micrcontroller for enhanced IP connections (Ethernet or wireless)...
Yeah, I saw that I though it was neat since I2C is a good protocol to address several devices on a 2 wire bus. Alas, for us the pins on the 644 are taken for the DAC. In any cases, since the probability of having another Uzebox owner close is pretty dim, the ethernet/wireless approach is the pretty much a no brainer. :P
User avatar
Vitis
Posts: 24
Joined: Thu Jul 10, 2014 7:00 pm

Re: Uzenet

Post by Vitis »

Could the SPI bus pins used with the SD card interface also potentially be used for Uzenet? I wonder if the SD MMC connections can be put in a high impedance state so that the same bus could be used for Uzenet SPI.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

Vitis wrote:Could the SPI bus pins used with the SD card interface also potentially be used for Uzenet? I wonder if the SD MMC connections can be put in a high impedance state so that the same bus could be used for Uzenet SPI.
Good question, I assumed yes, the bus should normally be sharable, but I didn't test that yet. Another thing I'm not sure is what happen if we deassert the SD card in the middle of transfers for other bus participants.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I have no clue if it is sharable, but if it is, the program could just ensure all SD transfers are complete before re-enabling Uzenet. SD card stuff is so cycle intensive I can't see doing that and also updating network data simultaneously unless I misunderstood.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

So I've been slacking on getting anything done for quite a while. I did end up making a master server that is more or less working but I shot myself in the foot by trying to make it do everything and the complexity got out of hand and made me lazy. I am working on breaking it apart into separate programs just so that it isn't so complicated and can be understood more easily to maintain it in the future. The servers I imagine are: Chat, File(.UZE/.DAT, download, upload with password protect),Active Game List,Game Server,Time(available in different string formats, giving us a RTC even if it's jittery),Streaming MOD/MIDI/PCM etc much later on.

Each one just has a different listen port and is designed to require as little code on the actual Uzebox as possible to interface with it. For instance the Time server accepts any connection and waits for a s format specifier like: 0x01,0x05 where the first byte specifies if it should be a long string like "Saturday January 27 2015 16:22:02 CENTRAL time" or something like "01/22/15 4:22p" and the second byte would represent a timezone the console is in to customize it to that location.

I'm working on that chat server now, and I thought if we wanted to in the future, we could utilize the multiple connection available on the 8266. You could have connection0 for gameplay but the game also has, say push SELECT, a chat window that pauses the game. The connection1 is paused on the chat server until the Uzebox gives an unpause command and then the chat server sends all the text since last update to the Uzebox(and all servers respect not sending too much data too fast). This way the Uzebox can have in game chat without having to keep a huge buffer around and it might be coordinating games. We could also tunnel the room into real IRC rooms on the server side. I will try and get a working chat server running for now then a separate program that is the file server. File server should be easier than chat and it could just be a Uzebox program using FATFS that writes received rom/dat files to the SD card so there is no need to track down the latest versions of anything manually.
Post Reply