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.Can we use osborne type disk in a or b without cpm in the mix? Is this already in your github nabupc_wip?
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
Seems that booting from LEO1_BRI.imd was the problem - I didn't realized that leo_disks.zip were attached earlier in thread.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.
reva is the only one that network boots for me.
I can get ver29 to boot from floppy if I reset with F3 after it has loaded.
This is strange ver29 boots from a floppy just fine on my machine, wasn't ever a need to reset it.Thanks for that, it does indeed work with a reset. Not sure why a reset is necessary though.
Booting IMD do not work, you need to convert the IMD to a raw sector image for it to boot.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.
This is strange ver29 boots from a floppy just fine on my machine, wasn't ever a need to reset it.
I don't think this is it, as i am using the same version of IA and it works fine on my system.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?
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.
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.So it's a mame pull-request, or is something you can address?