Uzenet

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
L4rry
Posts: 240
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry » Sun Aug 26, 2018 1:47 pm

Jubatian wrote:
Sun Aug 26, 2018 12:19 pm
I believe you will need those. The SPI RAM, which is normally the other device on an Uzenet card, works fine without any extra parts. A bit of looking around revealed this: ESP8266 on the Wiki, they are responsible for the 3.3V the ESP8266 needs. So most likely in your current setup, the ESP8266 isn't even powered.

At least it isn't a bad solder then! :D
Sweet! Thank you. So it seems I need the MCP1700-3302E/TO 3.3V regulator and two 1uf capacitors if I read that schematic correctly. I don't see a BOM for any of these anywhere, but I think I've got that right. Please let me know if I don't! :)

User avatar
D3thAdd3r
Posts: 2430
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r » Sun Aug 26, 2018 5:26 pm

Definitely need the regulator and caps. Also keep in mind there are a ton of different firmware versions floating around. Off memory, the F ones that I have seen all come with an AI Thinker firmware that plug and play work with UzenetDemo..maybe. Different firmwares can have different default baud rates, response syntax, which might need changing. It can be a headache, and I believe the F revision is the best of several I tested.

I am trying to find the alpha version of "UzeNet Setup Utility" on one of these PCs which auto detects any baudrate then sets a known one and performs a WiFi list and setup. I am packed up for moving, so I may not be able to find it depending what PC it is actually on :?

I am just glad someone else is really interested in UzeNet, I am jumping back on it!

User avatar
L4rry
Posts: 240
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry » Sun Aug 26, 2018 5:50 pm

D3thAdd3r wrote:
Sun Aug 26, 2018 5:26 pm
Definitely need the regulator and caps. Also keep in mind there are a ton of different firmware versions floating around. Off memory, the F ones that I have seen all come with an AI Thinker firmware that plug and play work with UzenetDemo..maybe. Different firmwares can have different default baud rates, response syntax, which might need changing. It can be a headache, and I believe the F revision is the best of several I tested.

I am trying to find the alpha version of "UzeNet Setup Utility" on one of these PCs which auto detects any baudrate then sets a known one and performs a WiFi list and setup. I am packed up for moving, so I may not be able to find it depending what PC it is actually on :?

I am just glad someone else is really interested in UzeNet, I am jumping back on it!
I got it working :) I scavanged the C16 and C20 capacitors from a broken uzebox I had along with the IC1 chip and put then in my newer, working uzebox. The uzenet demo works like a charm.

The default baud rate of my module is set at 115200, but as you said, that can't be relied on. I've attempted to cycle through the available baud rates to see which one returns a 'ready' response so I can dynamically adapt the baud rates without making any assumptions about the firmware. I can't get that working though, and I'm wondering if my approach is wrong here. I paste the algorithm here:

Code: Select all

int initWifi(){
    u8 bauds[5] = {185, 92, 46, 60, 30};
    s8 i = 0;
    int result;
    UBRR0H=0;
    UCSR0A=(1<<U2X0); // double speed mode
    UCSR0C=(1<<UCSZ01)+(1<<UCSZ00)+(0<<USBS0); //8-bit frame, no parity, 1 stop bit
    UCSR0B=(1<<RXEN0)+(1<<TXEN0); //Enable UART TX & RX
    DDRD|=(1<<PD3);
    PORTD&=~(1<<PD3);
    WaitVsync(1);
    PORTD|=(1<<PD3);
    do {
        UBRR0L=bauds[i];
        result = wifiWaitForStringP(PSTR("ready\r\n"),NULL, 2*60);
        i++;
    } while ((result != WIFI_OK) && (i < 5));
    return result;
}
I can't get that working, no matter what I put in or out of that loop. Unless the first baud in the array is the correct one (30 in my case for double speed 115200). Any suggestions?

User avatar
D3thAdd3r
Posts: 2430
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r » Mon Aug 27, 2018 9:45 pm

L4rry wrote:
Sun Aug 26, 2018 5:50 pm
I got it working I scavanged the C16 and C20 capacitors from a broken uzebox I had along with the IC1 chip and put then in my newer, working uzebox. The uzenet demo works like a charm.
Nice!

It has been a while and I can't find the code. My guess from my memory is it is possibly a timing issue, buffer overflow, or the ESP8266 interpreting commands differently than you want(due to ESP8266 timing). I think that firmware should show "ready\r\n" as the last thing it does after bootup, but if it was previously setup for WiFi it might say something like "WIFI CONNECTED\r\n" after a few seconds, potentially overflowing the "ready\r\n" in the Rx buffer before the next check. Originally I had done some different methods that were rather slow and unreliable for finding random baud settings, but I believe I finally settled on spamming "AT\r\n" and rapidly checking for "OK\r\n". So in the inner loop I think it is worth a try to just send out "AT\r\n" several times with a small delay. Due to timing, it might receive something like "T\r\nAT\r\n" a couple times if it is busy and spit out an error, and get confused, so with some very small delays and playing around, there is some perfect mixture that will find any baud setting in about .75 seconds. Ultimately I think that is the best way, then to set it to a known baud rate.

In my mind the best path would be to set a default rate of 9600 baud so that every Uzebox game knows to start there(since 9600 baud is plenty sufficient for many things, and it limits the precious ram cost of buffers). Defaulting to 115200 would potentially require a buffer some games couldn't afford even enough to get it set to 9600(missing rapid responses at 115200). I found that getting it to such a known state, there are a ton of assumptions you can then make in the logic with a bit of timing, and send out the stream of commands with a grand error check all at the end to make sure it worked. To check every possible thing gets slow due to longer than necessary delays, or otherwise has a bunch of very specific checks for amount of chars in the buffer, time elapsed, etc.

User avatar
L4rry
Posts: 240
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry » Thu Aug 30, 2018 5:15 pm

D3thAdd3r wrote:
Mon Aug 27, 2018 9:45 pm
but I believe I finally settled on spamming "AT\r\n" and rapidly checking for "OK\r\n".
Awesome, that strategy works perfectly :) I ended up adapting my local copy of the uzenet demo with the below algorithm that includes the AT spamming to determine baud rate, and then explicitly setting the baud rate to what I want to. (I also updated the send-and-wait commands to take timeout parameters)

Code: Select all

const u16 bauds[] PROGMEM = {246,184,92,60,44,30};
int initWifi(){
    s8 i = 0;
    int result;
    UBRR0H=0;
    UCSR0A=(1<<U2X0); // double speed mode
    UCSR0C=(1<<UCSZ01)+(1<<UCSZ00)+(0<<USBS0); //8-bit frame, no parity, 1 stop bit
    UCSR0B=(1<<RXEN0)+(1<<TXEN0); //Enable UART TX & RX
    do {
        UBRR0L=pgm_read_byte(&(bauds[i % 6]));
        WaitVsync(1);
        result = wifiSendCommandAndWait(PSTR("AT\r\n"),PSTR("OK\r\n"), 30);
        i++;
    } while ((result != WIFI_OK) && (i < 12));
    if (result == WIFI_OK) {
        result = wifiSendCommandAndWait(PSTR("AT+UART_CUR=76800,8,1,0,0\r\n"),PSTR("OK\r\n"), 2*60);
        if (result == WIFI_OK) {
            UBRR0L=pgm_read_byte(&(bauds[4]));
            WaitVsync(1);
        }
    }
    return result;
}
I do have a question about double speed though. So according to this comment in the uzenet demo:

Code: Select all

	//initialize UART0 
	UBRR0H=0;	

	//http://wormfood.net/avrbaudcalc.php
	//This is for single speed mode. Double the
	//values for UART double speed mode.
	//Baud  UBRR0L	Error%
	//9600	185		0.2
	//14400	123		0.2
	//19200	92		0.2
	//28800	61		0.2
	//38400	46		0.8
	//57600	30		0.2
	//76800	22		1.3
//115200	15		3.0
You have to double these values for double speed. I did that for baud rates 14400 - 115200 in my code above as you can see and it works perfectly. however, the value for 9600 can't be doubled without an 8 bit overflow. Do we then just set the UBRR0H value with the overflow? My testing seems to suggest this doesn't work but perhaps my c addressing is just rubbish. I am covered for all other baud rates though.

EDIT: Yup, got my c addressing wrong as I suspected :mrgreen: I was incrementing by two bytes instead of one to get the high byte from my array values. I needed to cast to an 8 bit pointer first. Fixed code is below with correct handling of high and low bytes and support for 9600 baud rate. Sorry for the long message!

Code: Select all

const u16 bauds[] PROGMEM = {370,246,184,92,60,44,30};
int initWifi(){
    s8 i = 0;
    int result;
    UCSR0A=(1<<U2X0); // double speed mode
    UCSR0C=(1<<UCSZ01)+(1<<UCSZ00)+(0<<USBS0); //8-bit frame, no parity, 1 stop bit
    UCSR0B=(1<<RXEN0)+(1<<TXEN0); //Enable UART TX & RX
    do {
        UBRR0L=pgm_read_byte(((u8*) &(bauds[i % 7])));
        UBRR0H=pgm_read_byte(((u8*) &(bauds[i % 7]))+1);
        WaitVsync(1);
        result = wifiSendCommandAndWait(PSTR("AT\r\n"),PSTR("OK\r\n"), 30);
        i++;
    } while ((result != WIFI_OK) && (i < 14));
    if (result == WIFI_OK) {
        result = wifiSendCommandAndWait(PSTR("AT+UART_CUR=9600,8,1,0,0\r\n"),PSTR("OK\r\n"), 2*60);
        if (result == WIFI_OK) {
            UBRR0L=pgm_read_byte(((u8*) &(bauds[0])));
            UBRR0H=pgm_read_byte(((u8*) &(bauds[0]))+1);
            WaitVsync(1);
        }
    }
    return result;
}

User avatar
D3thAdd3r
Posts: 2430
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r » Thu Aug 30, 2018 11:25 pm

Sweet, you are armed to start networking then! :mrgreen:

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 » Fri Sep 07, 2018 5:05 am

I decided to bite the bullet and try updating the firmware directly via the UART port. I'm suprised that it was relatively easy in the end. You need a FTDI232 USB-to-serial cable and use their tool. So I installed the latest and greatest AT firmware (1.7.0) and god this thing improved since the last time I used it! There's a lot more functions and it overall feels much more responsive and polished. The things that most got my attention are:
  • AT+CIPMODE: UART-Wi-Fi passthrough mode. Once enabled it directly sends the bytes you push on the TX line directly to a TCP/UDP adress:port (and receives the bytes the same way). Then send +++ to get back to normal mode. I have to make some tests for latency but that seems *the* thing for multiplayer games. So much simpler! :D
  • AT+CIPRECVMODE: Set TCP Receive Mode. Finally a mode that the ESP8266 buffers what it receives and the client asks for arbitrarily sized chunks at its own pace!

Latest AT instruction set: https://www.espressif.com/sites/default ... et__EN.pdf

Here's all the latest docs (There's so many now!)
https://www.espressif.com/en/support/do ... d%5B%5D=14
And binaries
https://www.espressif.com/en/products/h ... /resources

I'll write up something on the wiki for the firmware update procedure.

User avatar
L4rry
Posts: 240
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Uzenet

Post by L4rry » Fri Sep 07, 2018 11:51 am

uze6666 wrote:
Fri Sep 07, 2018 5:05 am
  • AT+CIPMODE: UART-Wi-Fi passthrough mode. Once enabled it directly sends the bytes you push on the TX line directly to a TCP/UDP adress:port (and receives the bytes the same way). Then send +++ to get back to normal mode. I have to make some tests for latency but that seems *the* thing for multiplayer games. So much simpler! :D
  • AT+CIPRECVMODE: Set TCP Receive Mode. Finally a mode that the ESP8266 buffers what it receives and the client asks for arbitrarily sized chunks at its own pace!
Interestingly, it looks like those two modes (passthrough and passive receive) can't be used at the same time according to the note in the AT docs for AT+CPIRECVMODE.

I'm still very much in the experimental phase and am yet to setup my second uzebox with an ESP-12f chip, but my plan is to enable local wifi networking by setting up one uzebox as a SoftAP, a second uzebox to connect to that SoftAP, and then sending data back and forth using UDP in the pass through mode. A game can then have two options. 'Host Local Wifi Game' or 'Join Local Wifi Game'. Hosting a game will setup an access point with an SSID with a game specific prefix and a subset of the ESP-12fs mac address. For example for Tank Fu, that might be 'TANKFU1afe3f'. The 'joining' game will look for access points with the 'TANKFU' prefix and choose a game to join. State will then be shared through UDP and passthrough.

That at least is the strategy I'm aiming to test.

EDIT: I suppose I don't even need to setup that second uzebox just yet. I can setup one with a softAP and then use a PC networking tool like 'netcat' to experiment with. Should make debugging a bit easier as well initially.

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 » Fri Sep 07, 2018 4:33 pm

Interestingly, it looks like those two modes (passthrough and passive receive) can't be used at the same time according to the note in the AT docs for AT+CPIRECVMODE
Yes, but it doesn't really matter since I don't see them used together. In the first, it's implicit you will have control of the data flow since you must roll your own protocol and will insure only small amount of data is exchanged. I see the second one for things like service requests, web pages or even streaming where you don't know the size of what you will receive.

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 » Sat Sep 08, 2018 7:08 am

That new esp8266 pass-thought mode really got on my mind and decided to hack my old uzenet demo. In no time I had a barebone telnet terminal. Was so easy and fun to code!
uzenet.jpg
uzenet.jpg (144.91 KiB) Viewed 2316 times
The best is, even with the current basic keyboard code included in the demo, I could exchange with the server with no efforts, just push the keyboard keys straight to the UART...so cool!

That monochrome 80 columns text opens the door to a world of telnet sites I never knew existed. Games, news, weather, chats, google search, wikipedia, you name it.

80 columns works ok on the Uzebox but even on my Commodore monitor, it get hard to read. I've looked at Jubatian mode 40 and its clearly the best thing for a Uzebox BBS/board/telnet site iHMO. So if you guys know of some active 40 columns telnet site for commodore machines or other ones, let me know. I'm totally working on a full Ansi color terminal for the uzebox.

Hopefully that will lead to my ultimate initial goal of making a retro computer with keyboard and all. Now with a relatively easy way to interact with the world, it makes it much more worthwhile. Now just think about that keyboard loaded with clickety Cherry-mx switches... :mrgreen:

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests