Uzenet adapter V2

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet adapter V2

Post by uze6666 »

Maybe I've got a bigger connector or header (oh err) or maybe a thicker Uzebox PCB than you but I've done a visual check with my case and even if I removed the DIP and soldered the other components as near to the Uzenet PCB as I can, it'd still be too tall to fit in the case.
Well I can confirm that the V2.0 module does not fit the case. I though about mounting the trough hole parts on the reverse side but, nope, the reset button overlaps the esp8266. :( The only solution would be to reorganize the PCB in the following way:
DSC00070.jpg
DSC00070.jpg (114.51 KiB) Viewed 2736 times
DSC00068.jpg
DSC00068.jpg (87.47 KiB) Viewed 2736 times
And then either mount through hole part on the reverse side or have surface mount parts or footprints for both. I'm considering a rev 2.1 of the pcb.
Uze had included 2 SPI chips so I swapped it for the spare and now the Apps show up and the About menu option works too.
Well if I sent you 2, check carefully the part number since I think they are not the same. One should be 64K (23LC512) and the other 128K (23LC1024). I should have mentioned it because the addressing is different between the two (sorry!). The reason I sent a 64K will come soon. ;) But in essence, the 64K SPI RAM is 25% faster for random accesses since you need to send one less address byte. 64Kb should be enough for anyone after all no?
How are we supposed to configure the wifi of the ESP? It seems there isn't a Uzebox app for this and nor can I find a guide for it on the wiki.
Good point, because there is none! But I can hack one quickly, stay tuned.
I think Tank Fu is the only game that uses Uzenet currently right? Does it actually work? Has anyone tried multiplayer Uzenet Tank Fu recently?
I played two players locally last week. I didn't remember it has Uzenet support, will have to check how it works! EDIT: Doh, I had an old version in my ROMs folder! I tried the latest and the network code fails. Could be a lot of things. Older ESP8266 came out configured a 9600 bauds by default while the newer ones are at 115200. I also upgraded the firmware on my modules to ESP8266_AT_Bin_V1.7 because of some bugs in previous versions. Larry used an older version for his game.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet adapter V2

Post by uze6666 »

Primarily there isn't a defined standard I'm aware of, but IMO it makes sense to choose an official FW we all like, and make the saved default baud rate at 4800.
Well, the ESp8266 defaults to 115200 bauds out of the factory. So that's what I was planning to use in the uzenet library. It's fast and the Uzebox has no issues catching up. The only upside to slower speeds is you need a smaller receive buffer. 115200 baud yields 12800 Bytes/s so that's 213 bytes per frame. Since the buffer size must by a power of 2, a 256 bytes buffer is required so you don't loose anything during frame rendering.

With all this said, RAM is a precious commodity on the Uzebox so a slower default speed makes sense (but perhaps not too slow). Here's the buffer sizes required per speed for 8N1 serial transfers (bytes = (baud/(8+1)) /60 ):

4800: 16 bytes
9600: 32 bytes
19200: 64 bytes
38400: 128 bytes
57600: 128 bytes
115200: 256 bytes

Any thoughts about a slower default speed...perhaps like 9600?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet adapter V2

Post by D3thAdd3r »

uze6666 wrote: Fri Mar 03, 2023 11:41 pm But in essence, the 64K SPI RAM is 25% faster for random accesses since you need to send one less address byte. 64Kb should be enough for anyone after all no?
Whoa, that's huge! I never thought of that, and that's a bit of a dilemma as I see it. Something like that could be expected to increase something like UzeboxUI performance a lot. It would probably be fine with half the windows/VMs. However I'm working on something where 128K is just barely enough and the bulk of the work is sequential.

Would there be another pin available to select between and use 2 x faster SPI RAMs? Or would it be ok just to have 2 variations and user software can check if it needs one of the other?
uze6666 wrote: Fri Mar 03, 2023 11:41 pm The reason I sent a 64K will come soon. ;)
I just got a reading off that :shock: ....I will shut my mouth and see if it's correct :lol:
uze6666 wrote: Sat Mar 04, 2023 12:16 am Any thoughts about a slower default speed...perhaps like 9600?
9600 Seems reasonable, but I could see 115200 too. If we say games should just give up if the 8266 doesn't respond at the Uzebox official startup baud(instead of changing timing/baud to figure it out), it's way simpler and doesn't matter that much. Even a game with only enough buffer space for 4800, can just let Rx overflow, and send the command to change baud to 4800 where it wont.
User avatar
danboid
Posts: 1930
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzenet adapter V2

Post by danboid »

"One should be 64K (23LC512) and the other 128K (23LC1024)"

Aha!

What happens if the user has soldered some SPI RAM onto their mobo then they attach the Uzenet with some more SPI RAM? Does the Uzebox still work? If so, which one gets preference? Can it address both or does it ignore both?

We need to update/re-write this page https://uzebox.org/wiki/SPI_Ram to mention the 64K option and answer my questions about the various potential SPI RAM configs and which work. I presume only having one SPI chip works?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet adapter V2

Post by uze6666 »

Would there be another pin available to select between and use 2 x faster SPI RAMs? Or would it be ok just to have 2 variations and user software can check if it needs one of the other?
It would be tricky to have more than one chip since there's only one SPI interface. You'd have to bitbang the second one at the same time has the SPI transfer. Doable in assembler but it seem that would only work reliably inside an interrupt. Btw, You can indeed easily check in software which one is installed and it becomes transparent for the main program.
9600 Seems reasonable, but I could see 115200 too. If we say games should just give up if the 8266 doesn't respond at the Uzebox official startup baud(instead of changing timing/baud to figure it out), it's way simpler and doesn't matter that much. Even a game with only enough buffer space for 4800, can just let Rx overflow, and send the command to change baud to 4800 where it wont.
Yeah I think I like that idea.
What happens if the user has soldered some SPI RAM onto their mobo then they attach the Uzenet with some more SPI RAM? Does the Uzebox still work? If so, which one gets preference? Can it address both or does it ignore both?
Well you would have two chips trying to use the same lines at the same time. The MOSI line (mcu->ram) would address both at the same time but the MISO (ram->cpu) lines of the chips would conflict for sure and it could perhaps damage the chips. So I would not do that. :)
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet adapter V2

Post by D3thAdd3r »

I figured there were no pins, but couldn't they coincide as an active/disable pair if there was a chip select? I'm probably missing something there.

Sort of related to this, I toyed with WeMos Arduino(ESP8266 instead of ATMega). It replaces the normal AT command processor with a custom iser program. Just a mention that it would be possible to have an Uzebox specific command processor that is more is streamlined. I haven't done this without the Arduino framework, so not sure the implications there.

As an offshoot to that, such a custom firmware would have access to additional ESP8266 features one of which is GPIO pins. At the extreme level, in theory, this hypothetical firmware could bitbang SPI?
User avatar
danboid
Posts: 1930
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzenet adapter V2

Post by danboid »

I have updated https://uzebox.org/wiki/SPI_Ram to add a note regarding the potential danger of trying to use two SPI RAM chips in parallel.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet adapter V2

Post by uze6666 »

I figured there were no pins, but couldn't they coincide as an active/disable pair if there was a chip select? I'm probably missing something there.
Yes of course you could have a chip select for that. But I think it's better to keep the design simple and stick with one. Didn't we a debate a long time ago about this...somebody wanted to have like 4 of them for some reason? :lol: Rethinking about the 64K vs 128K, the Uzebox moto has always been to avoid fragmentation. Moreover, that quoted 25% increase in speed is for random access. Even just a few sequential reads (which is what to aim using SPI RAM) renders the speed gain negligible and the whole point moot. Oh and not even sure the 64K would work on the emulators without change. So, long story short, I changed my mind: 128K ought to be enough for anyone!
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet adapter V2

Post by D3thAdd3r »

That makes sense to me also :lol: I do recall many angles of attack were suggested on all this, many requiring ever more exotic and time consuming development. The Uzenet module is a nice design, and temporarily lacking just one thing IMO. Games!
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet adapter V2

Post by uze6666 »

The Uzenet module is a nice design, and temporarily lacking just one thing IMO. Games!
It needs it's killer app!
Post Reply