NABU Computer Support

[GryBsh]

You already don't need to stick to that name. If you make a `NABUs` folder in with the NNS binary (in the prebuilt zips there is an empty one), you can name you .nabu file whatever you like:

Screenshot 2023-11-17 162849.png

Screenshot 2023-11-17 163046.png

I think the NABU.ca adapter was fussy about having the 000001 name, it may still I don't know its been quite some time since I've used it. But most others give you some mechanism of loading a nabu with an arbitrary name. Whatever file is defined by the source/program is what is sent when the NABU requests pak 1.

I am modifying the on NABU menu the nabunetwork.com adapter already has. It is hard coded to work with the 4 top level menus it has. NNS has more top level menus, and some like cycle direct (which will glitch start any item in the cycle without having to use the menu) go on for pages and pages, and the way it worked didn't lend well to that. Because it was purpose built for that adapter software.

There is basically nothing left of the original at this point, I even changed the communication back and forth to the adapter. (whats in the test code above). But this its so you can run change programs without the UI. It returns to the menu on reboot. NNS get used at a lot of cons and meetups, because it can drive multiple serial as well as TCP NABUs at once. Being able to have each one operate completely independently would be the ideal.

[GryBsh]

Well, I've hit another odd one.
if we take this slightly modified version of the test code I posted before

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <video/tms99x8.h>
#include <arch/nabu/hcca.h>

#define byte uint8_t
#define uint uint32_t
#define ushort uint16_t

struct Menu
{
	byte count;
	byte pages;
	char *items[20];
};

void main() {
    vdp_set_mode(0);
    byte loop = 0;
    while (1)
    {
        // I've had to put this here because there is a key press 
        // in the buffer on restart.
        puts("Press any key to continue\n");
        getkey(); 
        if (loop > 9) loop = 0;
        
        struct Menu *menu = malloc(sizeof(struct Menu));
        printf("%c", 12);

        hcca_reset_write();
        hcca_start_read(HCCA_MODE_RB, NULL, 0);

        hcca_writeByte(0x30);
        hcca_writeByte(loop);
        hcca_writeByte(0);
   
        hcca_start_write(HCCA_MODE_BLOCK, NULL, 0);
        ushort length = hcca_readUInt16();
        byte *data = malloc(length);
        for (int i = 0; i < length; i++)
        {
            data[i] = hcca_readByte();
        }
        printf("Menu Bytes: %d\n", length);
        
        menu->pages = length == 0 ? 0 : data[0];        
        printf("Menu Pages: %d\n", menu->pages);
        
        
        int count = 0;
        for (int i = 1; i < length; count++ )
        {
            byte n_length = data[i++];
            printf("I: %d, L: %d\n", count, n_length);
            char *item = malloc(n_length);
            for (int n = 0; n < n_length; n++)
            {       
                item[n] = data[i++];
            }
            item[n_length] = '\0';
            menu->items[count] = item;
            
        }
        menu->count = count;
        free(data);

        printf("Menu Count: %d\n", menu->count);
        
        for (int i = 0; i < menu->count; i++)
        {
            printf("%s\n", menu->items[i]);
        }
        
        free(menu);
        loop++;

        puts("________________________________\n");
    }
}

If you compile this without '-compiler=sdcc', it compiles, but it will get to the nabu.ca menu and it just stops dead. If I use sdcc, I get several warnings about missing prototypes, not just in my code, but also in math_genmath.h. And it works just fine besides some random lock ups that happen in both cases.

There is also a key press in the buffer on a restart, which is why there is the getkey() at the beginning, so it won't just skip the first page.

[dom]

Oh, it looks like I forgot to document something!

So, with _RB you're reading into a ring buffer of a fixed size. By default that fixed size is 256 bytes. So, page 2 has a size of 324 so the ringbuffer wraps and so the length is probably reading something large and it just gets stuck in the loop trying to read that many bytes.

Configure the ringbuffer size with -pragma-define:CLIB_RXBUF_SIZE=512 (or another multiple of 256), likewise there's a CLIB_TXBUF_SIZE for sending.

[GryBsh]

You're a legend. Thanks! Even after generously expanding the buffers it still locks up from time to time, always when waiting to read data.
Not sure what thats about. But it's working well enough that my Launcher menu is now shipping with NNS.

Also, Joystick 0 inputs are coming in as Joystick 1. Not sure what thats about either.

[dom]

Joysticks, yeah I can see the bug! I'll fix it up this evening.

Code: Select all

handle_keyboard:
    ld      a,(__nabu_key_mode)
    ld      hl,__nabu_j1
    cp      1
    jr      z,handle_joy
    ld      hl,__nabu_j1
    cp      2
    jr      z,handle_joy

[GryBsh]

I've tried the last 2 nighlies, and I can see your change in the libsrc folder, but the behavior persists.

[dom]

I'm temporarily confused as to what was going on so I've rewritten the code a little and it now seems to be working (the routine is in the nabu_int.lib library if you want to recompile yourself).