Page 3 of 4

Re: NABU Computer Support

Posted: Tue Jan 24, 2023 10:42 pm
by dom
Yes, we completely bypass the BDOS for reading the keyboard - it was really causing a whole bunch of issues that weren't great when screen modes were changed:

- Screen spam when a key was pressed
- The VDP interrupt was hooked to flash the cursor which isn't that useful when you want to use the whole screen area

Re: NABU Computer Support

Posted: Fri Jan 27, 2023 1:50 am
by DJ Sures
RobertK wrote: Tue Jan 24, 2023 8:18 pm Here is the Dstar sample game for NABU CP/M. I've noticed that the current NABU network version crashes at the start.
I have added screen mode switching in the dstar.c file, I'm using mode 2 for gameplay, and with that it's working.
Use QAOP and Space.
I updated the cloud cp/m user area 4 with DSTAR.COM for ya! :D

Re: NABU Computer Support

Posted: Fri Feb 17, 2023 10:39 pm
by dom
Following a bit of testing, it looks like the issues we experienced with the floppy based CP/M are resolved in Cloud CP/M. As a result I've rearranged the libraries a little.

The interrupt code has been separated out into a separate nabu_int.lib. This is used by default for the +nabu target since we can own the whole machine. It can optionally be used for floppy based CP/M but I'd recommend targeting cloud CP/M instead.

The CP/M subtype=nabubdos has been removed since it's no longer of use. Instead we have -subtype=nabu which generates floppy images and -subtype=naburn which generates hard disc images used by Cloud CP/M (which doesn't seem to support floppy images).

Both CP/M subtypes support z88dk graphics (including generic console, ansiterminal), AY trackers, joysticks so the Nabu is now looking like a regular machine.

In summary, the recommended compilation modes for the Nabu are:

* zcc +nabu ... - For bootable/full hardware support
* zcc +cpm -subtype=naburn - For working within Cloud CP/M

Re: NABU Computer Support

Posted: Thu Jun 29, 2023 10:17 am
by jorgegv
I suppose most of you have seen it already, but I felt this belongs in this post, just in case:

https://www.vice.com/en/article/ak3k34/ ... sachusetts

Source: https://spectrumcomputing.co.uk/forums/ ... 24b112d273

Re: NABU Computer Support

Posted: Thu Jun 29, 2023 2:27 pm
by jorgegv
...and now I realize that the article talks about DJ Sures... the very starter of this thread. :-)

Very nice read, It brought me some memories of "Halt and Catch Fire", one of my all time favorites TV series.

Long live the NABU. :cool:

Re: NABU Computer Support

Posted: Thu Jun 29, 2023 11:31 pm
by Timmy
Thanks for reminding me of this Computer. Its story is really fascinating!

I've spent a bit of time today watching some youtube videos on it, and it seems that it can play MSX games as well. (Because they ported a bit of the MSX BIOS to NABU).

Therefore I don't need to port my MSX games to this platform. :) And the MSX scene is still quite alive, too. And they still have many new games being made every year.

PS. One other thing I've saw was that he was writing C code. Which reminds me to say that the C in z88dk have some additional ways to optimise code and data than regular C code. If their code needs even more optimisations we might be able to help.

Re: NABU Computer Support

Posted: Sun Nov 12, 2023 10:44 am
by GryBsh
dom wrote: Fri Feb 17, 2023 10:39 pm Following a bit of testing, it looks like the issues we experienced with the floppy based CP/M are resolved in Cloud CP/M. As a result I've rearranged the libraries a little.

The interrupt code has been separated out into a separate nabu_int.lib. This is used by default for the +nabu target since we can own the whole machine. It can optionally be used for floppy based CP/M but I'd recommend targeting cloud CP/M instead.

The CP/M subtype=nabubdos has been removed since it's no longer of use. Instead we have -subtype=nabu which generates floppy images and -subtype=naburn which generates hard disc images used by Cloud CP/M (which doesn't seem to support floppy images).

Both CP/M subtypes support z88dk graphics (including generic console, ansiterminal), AY trackers, joysticks so the Nabu is now looking like a regular machine.

In summary, the recommended compilation modes for the Nabu are:

* zcc +nabu ... - For bootable/full hardware support
* zcc +cpm -subtype=naburn - For working within Cloud CP/M
I've been having a heck of a time trying to use the HCCA code.
When I can hcca_reset_write a 3E is getting sent to the adaptor. Then I can write to the adaptor no problem, but when trying to read the first uint16 of the response with hcca_readUint16, I get back a 0 instead of the length of the following block of data like I expect. I have this code all macro'd up to switch back and forth from NABU-LIB and straight z88dk, and with NABU-LIB it works as expected. I'd prefer not to use NABU-LIB, as it breaks z88dk features I'd like to use. I've tried with the latest release of z88dk and several nighlies. Any advice?

Also, any plans to be able to output to CPM without the disk image? These images don't work with Ishkur CPM.

Re: NABU Computer Support

Posted: Sun Nov 12, 2023 3:32 pm
by GryBsh

Code: Select all

void main() {
    _init;
   
    while (true)
    {
        struct Menu *menu = malloc(sizeof(struct Menu));
        _VDP_CLEARSCREEN();
        _VDP_SETLINE(0);

        hcca_reset_write();
        hcca_start_read(HCCA_MODE_RB, NULL, 0);
        
        hcca_writeByte(0x30);
        hcca_writeByte(0);
        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];
        
        byte count = 0;
        for (int i = 1; i < length; count++ )
        {
            byte n_length = data[i++];
            char *name = malloc(n_length + 1);
            for (int j = 0; j < n_length; j++)
            {
                name[j] = data[i++];
            }
            name[length] = 0x00;
            menu->items[count] = name;
        }
        menu->count = count;
        free(data);

        printf("Menu Count: %d\n", menu->count);
        printf("Menu Pages: %d\n", menu->pages);

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

Re: NABU Computer Support

Posted: Sun Nov 12, 2023 10:23 pm
by dom
GryBsh wrote: Sun Nov 12, 2023 10:44 amI've been having a heck of a time trying to use the HCCA code.
When I can hcca_reset_write a 3E is getting sent to the adaptor. Then I can write to the adaptor no problem, but when trying to read the first uint16 of the response with hcca_readUint16, I get back a 0 instead of the length of the following block of data like I expect. I have this code all macro'd up to switch back and forth from NABU-LIB and straight z88dk, and with NABU-LIB it works as expected. I'd prefer not to use NABU-LIB, as it breaks z88dk features I'd like to use. I've tried with the latest release of z88dk and several nighlies. Any advice?
It's fairly simple code, so it should work! It's odd that it's returning 0 since it's hcca_read_*() is meant to wait until data is available in the ringbuffer. The code you pasted looks similar to there retronet/ code that worked back when I wrote it.

I can't immediately see what command 0x30 is - I presume you've implemented in nabu.run and I can just build that and try to debug this issue?
Also, any plans to be able to output to CPM without the disk image? These images don't work with Ishkur CPM.
You should be able to just not specify -create-app and then take the .COM file generated. It's pretty easy to add new formats so as long as we have an image to work from we can usually figure out the disc parameters.

Re: NABU Computer Support

Posted: Mon Nov 13, 2023 12:44 pm
by GryBsh
I'm NNS not nabu.run, and yes, it is something I implemented in it. I'll get my latest code up in a branch so you can debug with it at some point today.
I was also surprised that not only did it not work, but that I got a 0. What I should be getting is 139

Re: NABU Computer Support

Posted: Mon Nov 13, 2023 11:20 pm
by dom
Also, any plans to be able to output to CPM without the disk image? These images don't work with Ishkur CPM.
I've added -subtype=nabu-nshd8 which I hope generates images in the right format - the layout looks the same as NDSK_DEFAULT.IMG
I'm NNS not nabu.run, and yes, it is something I implemented in it. I'll get my latest code up in a branch so you can debug with it at some point today.
Ooops, apologies. Turns out my memory is rubbish and apparently I used NNS to do the original testing!

Let me know when you've pushed and I'll give it a whirl.

Re: NABU Computer Support

Posted: Tue Nov 14, 2023 2:43 pm
by GryBsh
I expect no one to remember everything and I am a big fan of Mr. Masto's fine work on nabu.run. :)

https://github.com/GryBsh/NabuNetworkEm ... headless-1
That contains the code that will answer 0x30 :)

You should get back the names of the top-level source list items.
This is for a modified version of the nabunetwork.com headless menu, that can support more than 4 top level menus, and a larger number of pages and items.

Re: NABU Computer Support

Posted: Tue Nov 14, 2023 8:25 pm
by dom
So I can't reproduce your problem at the moment. The following code:

Code: Select all

#include <arch/nabu/hcca.h>
#include <stdio.h>

void main() {

    while (1)
    {
        printf("Starting\n");
        hcca_reset_write();
        hcca_start_read(HCCA_MODE_RB, NULL, 0);

        hcca_writeByte(0x30);
        hcca_writeByte(0);
        hcca_writeByte(0);

        hcca_start_write(HCCA_MODE_BLOCK, NULL, 0);

        uint16_t length = hcca_readUInt16();
        printf("Read length %d\n",length);

        uint8_t c;

        while (1) {
          c = hcca_readByte();
          printf("%02x ",c);
        }
    }
Produced this:
Screenshot 2023-11-14 at 20.22.27.png
Which looks like it's working. I had a few battles with Mame 0.255 seems broken for the Nabu (a lot of unknown 0xff in the nns log) so I've gone back to 0.250.

Re: NABU Computer Support

Posted: Tue Nov 14, 2023 9:41 pm
by GryBsh
I've been using the 0.250 80 column MAME from here: https://gtamp.com/nabu/,
Ya the unknown FF's mean the HCCA in MAME is sending junk, and I'm wondering if this might be a MAME issue. I'll have to get my NABU in here from the other room and try it on real hardware.

Re: NABU Computer Support

Posted: Tue Nov 14, 2023 10:43 pm
by dom
Regardless of any Mame issue regarding the HCCA I'm not sure where that leaves your report.

I've tried it on that build of Mame and again it's working:
Screenshot 2023-11-14 at 22.39.02.png
Can you try my simple program and see what it yields for you? I can't run yours since the struct definition is missing!

And yes, that screenshot means that I've added 80 column support for the Nabu target (vdp_set_mode(80)). There's some extra routines (vdp_f18a_lock, vdp_f18a_unlock, vdp_f18a_detect) to deal with the F18A.

To detect and use 80 column mode, the following code structure should be used:

Code: Select all

#include <video/tms99x8.h>

...
vdp_f18a_unlock();
int f18_present = vdp_f18a_detect();

vdp_set_mode( f18_present ? 80 : 0);
Though that won't work on Mame since the v9938 mame driver is used instead.

Re: NABU Computer Support

Posted: Wed Nov 15, 2023 4:42 am
by GryBsh
So, for whatever reason, this is not working for me at all on Windows with the nightly builds, whatever I build comes out weird and buggy. I cloned and built z88dk from source on WSL and I can build your sample program and get the 139 bytes I expect.
Now, when I try to output those bytes as the ascii characters that they are with %c, I get green screen, rando characters, the screen clearing, really everything except the ascii strings I want. I can see that what was sent was correct, the length bytes all match, it should be good :(

Re: NABU Computer Support

Posted: Wed Nov 15, 2023 6:11 pm
by dom
GryBsh wrote: Wed Nov 15, 2023 4:42 amSo, for whatever reason, this is not working for me at all on Windows with the nightly builds, whatever I build comes out weird and buggy.
There's something weirdly environmental going on. I've done the following:

1. Take libraries from a nightly build and compile on macOS
2. Use a Win10 VM, installed nightly and compiled the example

The NABU file produced is the same, and works.

If you could compile with "zcc +nabu test.c -m -create-app" and send through the resulting .map and .bin files I can dig further.
I cloned and built z88dk from source on WSL and I can build your sample program and get the 139 bytes I expect.
Now, when I try to output those bytes as the ascii characters that they are with %c, I get green screen, rando characters, the screen clearing, really everything except the ascii strings I want. I can see that what was sent was correct, the length bytes all match, it should be good :(
The screen driver has a few control codes which I think the lengths are triggering. Skipping over those, and going from the first 0x46 to the last character before 0x07 in my screenshots it's "pretty clear" that the first string is "FigForth (latest)"

This is the second time you've mentioned 139 bytes - I'm always getting 147 - what's going on there?

Re: NABU Computer Support

Posted: Wed Nov 15, 2023 9:38 pm
by GryBsh
Having it in WSL is workable, but since the easiest thing to believe is that I'm just doing it wrong: I'm curious how I boned this up :)
I'll post that later. As to the number of bytes received, since I have that info handy, it should be 139 bytes:
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1:36089: NA: RCVD: 00
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1:36089: NA: RCVD: 00
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1:36089: NA: RCVD: 1 byte
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1:36089: NA: RCVD: 1 byte
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1:36089: NA: SEND: 8B|00|01|10|4C|6F|63|61|6C|20|4E|41|42|55|20|46|69|6C|65|73|11|46|69|67|46|6F|72|74|68|20|28|6C|61|74|65|73|74|29|0C|31|39|38|34|20|43|79|63|6C|65|20|31|0C|31|39|38|34|20|43|79|63|6C|65|20|32|0C|43|79|63|6C|65|20|44|69|72|65|63|74|0A|49|73|68|6B|75|72|20|43|50|4D|07|4E|41|42|55|2E|63|61|0F|4E|61|62|75|4E|65|74|77|6F|72|6B|2E|63|6F|6D|1C|50|72|6F|64|75|63|74|69|6F|6E|20|44|61|76|65|27|73|20|4E|61|62|75|20|47|61|6D|65|73
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1:36089: NA: SENT: 141 bytes
<6>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1:36089: Menu: 0, Page: 1/1 Sent
There is says 141, but the first 2 bytes are the number of bytes to read (008b or 139). Then one byte for the total page count, which is 1 here at the top level. Then it's all length prefixed (1 byte) ascii strings with the source names, like they appear in the drop-down menu in the web UI.
Local NABU Files
FigForth (latest)
1984 Cycle 1
1984 Cycle 2
Cycle Direct
Ishkur CPM
NABU.ca
NabuNetwork.com
Production Dave's Nabu Games

Re: NABU Computer Support

Posted: Wed Nov 15, 2023 10:11 pm
by dom
Mine matches up between the logs and what's on screen, so we must have slightly different menus:

Code: Select all

dbug: [2023-11-15 22:04:59.3257] Nabu.Network.NabuNetworkCom.MenuProtocol: 127.0.0.1:63424: NA: RCVD: 00
dbug: [2023-11-15 22:04:59.3257] Nabu.Network.NabuNetworkCom.MenuProtocol: 127.0.0.1:63424: NA: RCVD: 1 byte
dbug: [2023-11-15 22:04:59.3257] Nabu.Network.NabuNetworkCom.MenuProtocol: 127.0.0.1:63424: NA: RCVD: 00
dbug: [2023-11-15 22:04:59.3257] Nabu.Network.NabuNetworkCom.MenuProtocol: 127.0.0.1:63424: NA: RCVD: 1 byte
dbug: [2023-11-15 22:04:59.3432] Nabu.Network.NabuNetworkCom.MenuProtocol: 127.0.0.1:63424: NA: SENT: 149 bytes
dbug: [2023-11-15 22:04:59.3432] Nabu.Network.NabuNetworkCom.MenuProtocol: 127.0.0.1:63424: NA: SEND: 93|00|01|11|46|69|67|46|6F|72|74|68|20|28|6C|61|74|65|73|74|29|07|4E|41|42|55|2E|63|61|18|4E|61|62|75|4E|65|74|77|6F|72|6B|2E|63|6F|6D|20|48|65|61|64|6C|65|73|73|0F|4E|61|62|75|4E|65|74|77|6F|72|6B|2E|63|6F|6D|0A|49|73|68|6B|75|72|20|43|50|4D|0C|31|39|38|34|20|43|79|63|6C|65|20|31|0C|31|39|38|34|20|43|79|63|6C|65|20|32|0C|43|79|63|6C|65|20|44|69|72|65|63|74|1C|50|72|6F|64|75|63|74|69|6F|6E|20|44|61|76|65|27|73|20|4E|61|62|75|20|47|61|6D|65|73
info: [2023-11-15 22:04:59.3432] Nabu.Network.NabuNetworkCom.MenuProtocol: 127.0.0.1:63424: Menu: 0, Page: 1/1 Sent
Regardless, I await with curiosity to find out what's gone wrong in your windows environment!

Re: NABU Computer Support

Posted: Thu Nov 16, 2023 2:34 am
by GryBsh
:lol: And of course, now, after downloading the nightly then trying to build, I can't reproduce it. Its working just fine now.
This is like when someone at work wants to show me something isn't working, and just by me looking at it, it starts working again.
I'm only mildly peeved because while I didn't sink huge amounts of time into tinkering with it, I sunk enough lol.

Huge thanks to you for putting "the fear" into it :)

Any advice on outputting the text correctly?
Screenshot 2023-11-15 210213.png
The background is supposed to be blue, it changes while drawing the screen.

Re: NABU Computer Support

Posted: Thu Nov 16, 2023 9:49 pm
by GryBsh
Here is a standalone example. I am not trying to print length values or anything that might cause weirdness, yet I get weirdness. =(

Code: Select all

#include <stdlib.h>
#include <stdio.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() {
    while (1)
    {
        struct Menu *menu = malloc(sizeof(struct Menu));
        printf("%c", 12);
        printf("%c%c%c", 22, 32, 32);

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

        hcca_writeByte(0x30);
        hcca_writeByte(0);
        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 *name = malloc(n_length + 1);
            for (int n = 0; n < n_length; n++)
            {       
                name[n] = data[i++];
            }
            name[length] = '\0';
            menu->items[count] = name;
        }
        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);
        getkey();
    }
}
And it produces the screenshot above. Down to the green background.

Re: NABU Computer Support

Posted: Thu Nov 16, 2023 11:08 pm
by dom
Just looking at the code - I will try it out tomorrow.

Code: Select all

           name[length] = '\0';
Shouldn’t this be n_length?

Re: NABU Computer Support

Posted: Thu Nov 16, 2023 11:23 pm
by GryBsh
:lol: You're gonna love this....
So I fix that typo....
Screenshot 2023-11-16 181631.png
Thanks for all your help :)

Re: NABU Computer Support

Posted: Fri Nov 17, 2023 1:46 pm
by GryBsh
I think I have reproduced the state I was in earlier of the hcca just returning 0 with -compiler=sdcc, which was used in the menu code I started from.
And here is the map and bin.
000001.7z

Re: NABU Computer Support

Posted: Fri Nov 17, 2023 8:15 pm
by dom
Ah, fantastic that does explain it! I've fixed it now: https://github.com/z88dk/z88dk/commit/0 ... a156b28531 - the sdcc decorators were absent.

If you're creating what I think you're doing then that will be fantastic. Naming everything 000001.nabu does get confusing!