NABU Computer Support
Re: NABU Computer Support
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
- 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
I updated the cloud cp/m user area 4 with DSTAR.COM for ya!
Re: NABU Computer Support
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
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
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
https://www.vice.com/en/article/ak3k34/ ... sachusetts
Source: https://spectrumcomputing.co.uk/forums/ ... 24b112d273
Re: NABU Computer Support
...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.
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.
Re: NABU Computer Support
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.
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
I've been having a heck of a time trying to use the HCCA code.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
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
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
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.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?
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?
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.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
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
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
I've added -subtype=nabu-nshd8 which I hope generates images in the right format - the layout looks the same as NDSK_DEFAULT.IMGAlso, any plans to be able to output to CPM without the disk image? These images don't work with Ishkur CPM.
Ooops, apologies. Turns out my memory is rubbish and apparently I used NNS to do the original testing!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.
Let me know when you've pushed and I'll give it a whirl.
Re: NABU Computer Support
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.
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
So I can't reproduce your problem at the moment. The following code:
Produced this:
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.
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);
}
}
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.
You do not have the required permissions to view the files attached to this post.
Re: NABU Computer Support
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.
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
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:
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:
Though that won't work on Mame since the v9938 mame driver is used instead.
I've tried it on that build of Mame and again it's working:
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);
You do not have the required permissions to view the files attached to this post.
Re: NABU Computer Support
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
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
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.
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)"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
This is the second time you've mentioned 139 bytes - I'm always getting 147 - what's going on there?
Re: NABU Computer Support
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:
I'll post that later. As to the number of bytes received, since I have that info handy, it should be 139 bytes:
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.<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1 NA: RCVD: 00
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1 NA: RCVD: 00
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1 NA: RCVD: 1 byte
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1 NA: RCVD: 1 byte
<7>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1 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 NA: SENT: 141 bytes
<6>Nabu.Network.NabuNetworkCom.MenuProtocol[0] 127.0.0.1 Menu: 0, Page: 1/1 Sent
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
Mine matches up between the logs and what's on screen, so we must have slightly different menus:
Regardless, I await with curiosity to find out what's gone wrong in your windows environment!
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
Re: NABU Computer Support
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? The background is supposed to be blue, it changes while drawing the screen.
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? The background is supposed to be blue, it changes while drawing the screen.
You do not have the required permissions to view the files attached to this post.
Re: NABU Computer Support
Here is a standalone example. I am not trying to print length values or anything that might cause weirdness, yet I get weirdness.
And it produces the screenshot above. Down to the green background.
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();
}
}
Re: NABU Computer Support
Just looking at the code - I will try it out tomorrow.
Shouldn’t this be n_length?
Code: Select all
name[length] = '\0';
Re: NABU Computer Support
You're gonna love this....
So I fix that typo.... Thanks for all your help
So I fix that typo.... Thanks for all your help
You do not have the required permissions to view the files attached to this post.
Re: NABU Computer Support
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.
And here is the map and bin.
You do not have the required permissions to view the files attached to this post.
Re: NABU Computer Support
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!
If you're creating what I think you're doing then that will be fantastic. Naming everything 000001.nabu does get confusing!