Page 22 of 25

Re: Uzenet

Posted: Thu Oct 25, 2018 12:30 am
by uze6666
you don't know if the module is perhaps already in passthrough mode (Resetting the Uzebox does nothing to the state of the Wifi module it seems. So your game can boot up while the module is still in passthrough mode) nor do you know if it's even there!
Just re-read this bit and find it quite perplexing...the reset does not take you out of passthrough more? I can get out on the portable but that may be because I cycle the enable pin. Sucks I didn't think to add the pulldown to the CH_PD pin to the main pcb. :( I should probably make it standard on the new pcbs...what do you think? I would need to come up with a patch for those with the 1.3.1 rev...would need some trace cutting and wires. Would you apply it to your boards?

Re: Uzenet

Posted: Thu Oct 25, 2018 3:34 am
by D3thAdd3r
I would modify mine and I would guess it is relatively easy for anyone who can already build the kit. Doesn't seem too late IMO. A software fix seems easy too, but I don't recall the quirks of all that mode changing stuff, if any.

Re: Uzenet

Posted: Fri Oct 26, 2018 1:28 pm
by L4rry
uze6666 wrote: Thu Oct 25, 2018 12:30 am Just re-read this bit and find it quite perplexing...the reset does not take you out of passthrough more? I can get out on the portable but that may be because I cycle the enable pin. Sucks I didn't think to add the pulldown to the CH_PD pin to the main pcb. :( I should probably make it standard on the new pcbs...what do you think? I would need to come up with a patch for those with the 1.3.1 rev...would need some trace cutting and wires. Would you apply it to your boards?
Pressing the reset button does not take me out of passthrough mode no. However, if I call the following software reset code as present in the uzenet demo, then that seems to do the trick:

Code: Select all

void wifiHWReset(){
    //reset module
    DDRD|=(1<<PD3);
    PORTD&=~(1<<PD3);
    WaitVsync(1);
    PORTD|=(1<<PD3);
}
I neglected to use this initially. I wouldn't mind doing a hardware mod either, but will rely on this software call for now.

Re: Uzenet

Posted: Sat Oct 27, 2018 4:37 am
by uze6666
Yes Lee is right, software reset is *essential* in this case. :)

Re: Uzenet

Posted: Wed Dec 19, 2018 4:27 pm
by L4rry
So I've finally finished with Peer to Peer local networking support for Tank Fu. You can find the binaries for release v3.1 here at the top of the Tank Fu thread along with the release notes. So since I've pasted my networking demo earlier on in this topic, I've made the following changes based on testing and your feedback:
  • I've settled on a baud-rate of 19200 single speed mode
  • I'm using an Rx buffer size of 64 bytes and a Tx buffer size of 32 bytes. So more RAM tiles available
  • I've implemented a 'Send until Ack Received' for key network messages that should they get dropped, will break the game
  • In game messages are largely idempotent to minimize any impact of duplicate messages
  • Replaced floating point calculations with fixed point calcuations to allow for a snappy game loop, less RAM usage and less flash usage
  • Replaced PCM effects with wave table effects to reclaim flash
  • Ensure RESET pin stays low when Wifi is not in use
  • Wifi module is only enabled once 'Host LAN Game' or 'Join LAN Game' is selected. Not at startup anymore.
I can't find any more game breaking bugs and I feel I've reached the point of 'That's good enough'. Now I'm just looking forward to that Uzebox portable so I can play this as intended :)

Re: Uzenet

Posted: Sun Jan 13, 2019 12:44 am
by L4rry
Some Uzenet fun! Me recording my work colleagues duking it out in Tank Fu...


Re: Uzenet

Posted: Tue Jan 15, 2019 1:28 am
by D3thAdd3r
It looks to play ultra smooth, very exciting development there! 8-)

Re: Uzenet

Posted: Wed Jan 16, 2019 4:42 pm
by Jubatian
Huh, nice, so at least now we have a working networked game as well, and a very good game at that! :)

Re: Uzenet

Posted: Thu Jan 24, 2019 8:19 pm
by nicksen782
Feature request/question:

Could the ESP be modified to accept a command that would have it run a cURL script or wget? It would be a really cool idea if it could pull down a menu of games from a server which could then be downloaded (individually or in part) onto the SD card. Maybe something as easy as a JSON file or CSV that keeps an up to date list of all games and the urls to the remoteload.json files for each game. That file indicates where all the required files for a game are.

I've been asked before to create a downloadable zip of the Uzebox games. Still a good idea... but what if the Uzebox could go get those games for you? Like a bootloader to the bootloader. Go get the files, give control back to the Uzebox's bootloader. Bootloader sees the files, load the game, easy!

Is this possible? It would likely increase interest in the ESP? Another idea would be to create an Uzebox "game" that could control the ESP and get the files that way (minimal changes to the ESP I assume.) I really like the idea of being able to have an up-to-date Uzebox game collection on my device. The Online Player already has this and it is beneficial. We can apply the same benefit to the actual hardware.

If I could get some help with the ESP ( I have one in my Uzebox ) then I would be very interested in creating that Uzebox "game".

Re: Uzenet

Posted: Fri Jan 25, 2019 9:12 pm
by uze6666
It would be a really cool idea if it could pull down a menu of games from a server which could then be downloaded (individually or in part) onto the SD card.
That's a very neat idea and certainly feasible. If you can expose a REST endpoint to get a binary of some game, it can be downloaded directly to the SD card. I can't recall if we have write support in the SD library but worst case it's possible to use petitfatfs.

About tankfu, it's pretty awesome. :mrgreen: I have to test it this weekend, now that I have two devices with uzenet.