• Please review our updated Terms and Rules here

NABU PC Emulation under MAME

That's basically what I was going to suggest - check for magic numbers or so.
 
Can we use osborne type disk in a or b without cpm in the mix? Is this already in your github nabupc_wip?
 
Can we use osborne type disk in a or b without cpm in the mix? Is this already in your github nabupc_wip?
The osborne type disk is what programs like nabu writer, nabu basic, etc use. As far as mame is concerned any disk hat does not have a boot loader installed on it is considered an osborne disk and as such will not inject the special out of band data into track 0. Nanu CPM will read either type, if you are just using software from the nabu network it only understands the osborne type of disk.
 
Sorry for the delay. I have now uploaded the Windows build with brijohn's latest code.


- You can boot from unpatched NABU CPM images
- Out of band track 0 data is only added to NABU CPM images
- You can use both OSBORNE1 and NABU images
- NABU uses the Internet Adapter by default, so it should work without any command line options or cfg files (patch by nathanel23)

I included 2 CPM disks and you can easily boot them by running floppy-boot.cmd

It executes this command:

mame nabupc -window -bios ver14 -option1 fdc -flop1 disks\leo1.img -flop2 disks\leo2.img

BIOS ver14 starts the floppy boot process the fastest in my MAME tests
 
Last edited:
With the newest build, while rom versions 14 and 17 seem fine, version 29 just shows the Nabu logo and hangs. I thought the adding the -hcca and -bitb options (since version 29 supports both network and disk) might do the trick, but no joy. Full command line is as follows:

Code:
mame nabupc -window -kbd nabu_hle -hcca null_modem -bitb socket.192.168.168.16:5816 -bios ver29 -option1 fdc -flop1 disks\nabupc\leo1.img -flop2 disks\nabupc\leo2.img
 
reva is the only one that network boots for me.

Yes, that is the case currently, but the ver 29 rom supports both network and disk. @brijohn is chasing an issue with the emulator where it doesn't display the boot options when using that version of the ROM (as the real hardware does).

I can get ver29 to boot from floppy if I reset with F3 after it has loaded.

Thanks for that, it does indeed work with a reset. Not sure why a reset is necessary though.
 
Thanks for that, it does indeed work with a reset. Not sure why a reset is necessary though.
This is strange ver29 boots from a floppy just fine on my machine, wasn't ever a need to reset it.

I was able to boot the "LEO1_BRI.imd" from "https://vintagecomputer.ca/files/Nabu/disk_images/", but not the NABUPER*.IMD disks that you mentioned should work.

Am I missing something?

Thanks - appreciate your work on getting this working.
Booting IMD do not work, you need to convert the IMD to a raw sector image for it to boot.

I needed to write custom handling for the out of band data, this required its own format custom raw format.

The LEO!_BRI.imd is a hacked version of the floppy designed to work without the need for the out-of-band data, in return it no longer supports accessing osborne1 style disks. Its mainly there for people who want to use cp/m on real hardware but lack a flux imaging device.
 
This is strange ver29 boots from a floppy just fine on my machine, wasn't ever a need to reset it.

A bit more detail:

I updated the network adapter server software to the iteration released yesterday. When using the new build with the v29 rom, it does connect to the server apparently. I know this because with the new network adapter software, when quitting mame is now stops the IP server and the 'Start TCP' button needs to be pressed again (that didn't happen with the prior release of the network adapter software... there was a fix related to TCP disconnects that apparently causes this to happen now). I'm guessing that hitting F3 on mame stops the TCP connectivity and reverts to a disk boot?
 
Regarding ver29 rom and booting from hard drive, do we know if the only OS available was CP/M or was there anything else?
 
A bit more detail:

I updated the network adapter server software to the iteration released yesterday. When using the new build with the v29 rom, it does connect to the server apparently. I know this because with the new network adapter software, when quitting mame is now stops the IP server and the 'Start TCP' button needs to be pressed again (that didn't happen with the prior release of the network adapter software... there was a fix related to TCP disconnects that apparently causes this to happen now). I'm guessing that hitting F3 on mame stops the TCP connectivity and reverts to a disk boot?
I don't think this is it, as i am using the same version of IA and it works fine on my system.
 
Well I think i figured out why you don't get the boot menu on mame. It is as far as i can tell a mame bug in how the uart controller used for the HCCA port works.

Basically the nabu firmware revb and rev29 on boot enable to hcca send interrupt and then check to see if an interrupt is generated or not. If no the assume you do not have an adapter. The send/transmit interrupt is generated whenever the transmit buffer is empty, which on boot it should be since we haven't even tried to send anything yet naturally the transmit buffer is empty. The problem is that mame is not generating the callback on the uart reset to inform us of initial pin state. I've cheked and if i set the variable i use to track this pin to 1 on reset in the nabu code i wrote the menu appears. However mame should be giving us a callback on reset with the initial state.
 
Dunno... I've tried numerous times, both with and without the -hcca/-bitb options, it just hangs until F3 is hit... just as @Wormetti experienced.

Perhaps something unique with the Windows build?
 
The problem is that mame is not generating the callback on the uart reset to inform us of initial pin state. I've cheked and if i set the variable i use to track this pin to 1 on reset in the nabu code i wrote the menu appears. However mame should be giving us a callback on reset with the initial state.

So it's a mame pull-request, or is something you can address?
 
I have updated the code with a fix so you should now be able to get the boot menu from either cable or floppy.
So it's a mame pull-request, or is something you can address?
Its definitely not right on the mame end of things, but fixing it there is abit more complicated and could have other unintended effects. So for the time being I have taken the approach of simply setting my variable that tracks the state of the transmit empty pin to default to 1, instead of relying on the emulated chip to notify me of the correct state on reset.
 
Back
Top