BadCat WiFi with UnApi(or open sourced unapi wifi solution).

By nihirash

Rookie (21)

nihirash's picture

22-02-2021, 20:56


If you have BadCat wifi with 16C550CFN chip that have AFE(auto flow control) - you can use it as UnApi modem already now.

You just need USB->TTL-Uart adapter and arduino ide(and my firmware+driver).

Firmware can be grabbed here:
Simple unapi driver present as sources and binary(in releases).

If your BadCat haven't AFE feature - you can extend driver code to make your own flow control. Or wait when I'll make it(but I have AFE and it isn't first need for me, sorry).

Some questions are answered in readme file.

Login or register to post comments

By ducasp

Champion (400)

ducasp's picture

23-02-2021, 14:18

Quite cool to have a new ESP8266 UNAPI firmware, congratulations for the nice Work nihirash, once I find some free time I will test it on my BaDCaT since it has AFE working...

The driver probably works on MSX1 as well, as long as it has a mapper that initializes itself (like SD Mapper), as I see the loading and allocation is, like the SM-X driver, based on Nestor code for loading and allocating an UNAPI driver Smile

Regarding no AFE support, that was my main point of contention... My idea (perhaps it helps you) was that if AFE is not detected, driver would send a command to the UNAPI firmware telling it, and UNAPI firmware would send data in chunks of 10 bytes, it sends 10 bytes and wait for CTS level to change, than sends 10 bytes more and wait for CTS level to change (so it will toggle from 0, to 1, to 0, etc). Once the firmware send the last byte, it will flip RTS state (that like CTS, will togle from 0 to 1 to 0, etc)

Driver would read data and once getting by the 7th or so byte, would flip CTS level to allow ESP to fill the buffer.

Then once the FIFO is really empty, driver just check if RTS state flipped, if so, consider data is received.

If your firmware has indication in the very beginning of command responses of how many bytes the driver should expect to receive, the RTS mechanism would not be needed.

To test without AFE you can just consider that the UART has no AFE for your tests, and to check if AFE is supported, this is
how I do with Telnet:

unsigned char check16C550C(void)
    unsigned char Ret = NOUART;
    unsigned char ucTest;

    AFESupport = 0;

    // First check scratchpad, if it doesn't exist, done
    ucTest = mySR;
    ucTest += 2;
    mySR = ucTest;
    // If matches the new value
    if (ucTest == mySR)
        //Ok, we have a scratch register, now check for FIFO
        myIIR_FCR = 0x07; // Clear FIFO, enable FIFO
        ucTest = myIIR_FCR&0xc0; //check 7th and 8th bit
        if (ucTest==0xc0)
            //Hey, we have a FIFO! so this is at least a 16550
            Ret = U16C550;
            //Now test if AFE can be enabled
            myMCR = 0x22;
            ucTest = myMCR&0x20;
            if (ucTest == 0x20)
                Ret = U16C550C;
            AFESupport = 1;

    return Ret;

Not sure how many BaDCaTs there are in the Wild without AFE and if it is worth pursuing this, but it would be quite cool to have support for those BaDCaTs as well. :)

By nihirash

Rookie (21)

nihirash's picture

23-02-2021, 16:38

Firmware currently have very basic support of UnApi TCP/IP but it enough for browsing gopher, setting time, downloading software via hub and telneting.

I've covered my needs currently Smile
Also It works times faster than Obsonet(I think I'll gift it to someone or keep just for testing but better way - gift it for someone whom'll need it).

Just a bit later - I'll try make driver for usual 16550 chips.