• Please review our updated Terms and Rules here

NABU PC Emulation under MAME

B

brijohn

Experienced Member
Joined
Jul 19, 2021
Messages
187
Location
Michigan
So suffering form a bit of boredom over the weekend while waiting for my NABU to actually get shipped (It finally shipped today), I started playing around with getting the system emulated under MAME.

So far the base system should be mostly emulated, the hcca port is exposed to the host system via either the pty device or a null_modem device to allow communication with the in progress NABU network emulator.

The standard NABU keyboard is still not full emulated as I was not able to find online schematics for the keyboard PCB and my NABU has yet to arrive, however I implemented an HLE keyboard that simply sends the correct serial data rather then emulating the 6801/3 chip. The system also does not yet emulate the bus, so no emulated expansion cards yet.

Github: https://github.com/brijohn/mame/tree/nabupc_wip
 

Attachments

  • mame_nabupc.png
    mame_nabupc.png
    106.7 KB · Views: 5
Hey if it’s not working yet then it’s emulating my NABU perfectly!
[Mine’s still in its box. I did download the (8K) ROM’s and work on the disassembly. ;-)]
 
someone else is working on it

Nabu computer

I watched Adrian's Digital Basement video on the Nabu Network Computer. It's a z80 paired with a tms9918 that hooked up to a cable system and would download software from the cable. It had its OS downloaded to it that was based on CP/M. It failed commercially, but it's getting new life ...
forums.bannister.org forums.bannister.org
 
snuci said:
Luigi30 is working on it here: https://github.com/luigi30/mame/tree/nabu

I haven't tried it yet but I do have the 4k, 8k and keyboard ROMs here: https://vintagecomputer.ca/files/Nabu/firmware/
Click to expand...
Yeah i have been using your ROM set for my version. I hadn't seen Luigi's version before though, but i took a brief look since I was curious if he had a better handle on the keyboard emulation, though it doesn't look much different my current iteration. Hence why i have currently implemented a high level emulation version that does not require using the original keyboard rom. I do have support in mine for loading both the 8k and 4k version though the 8k fails with a floppy drive failed message because there is currently no emulated floppy controller for the system.
 
So I just pushed some code that adds support for bus emulation and along with that support for booting from a floppy to my mame core.

The emulation seems to work fine however since the disk images provided by @snuci seem to be bad it runs into the same issues that he has been having on his real hardware, namely that it gets stuck at the "LOADING FROM FLOPPY DISK" screen and the drive motor remains running.

It is however correctly reading from the emulated floppy. When booting it will load Track 0, Sector 1 from the disk to address C000, which contains code to load the remaining 4 sectors from Track0 to address 100. This contains the CP/M loader which is a small CP/M implementation whose sole purpose to load CPM3.SYS from disk. The problems start when it tries to call BDOS function 15 (Open file) to access the CPM3.SYS file. This call never exists and instead gets stuck executing code over then range of 0x507-0x51B. Hopefully we will be able to some good CP/M bootable disks eventually.

The floppy controller uses 4 I/O registers, the first 3 (0-3) are just the internal registers of the FD1797 chip, the fourth (F) is a register on the board itself. This register always seems to read as 0x10, and this is how the ROM code determines if a floppy controller is installed, it just scans CF,DF,EF,FF to determine which if any of the slots the card is installed in. When writing to this register BIT 1 is used to turn the floppy motots on or off, a 1 turns them on and a 0 turns them off. I also suspect that another bit (maybe BIT 0) is used for the drive select line, but haven't verified that yet.
 

Attachments

  • insert_disk.png
    insert_disk.png
    114.1 KB · Views: 5
  • loading.png
    loading.png
    91.6 KB · Views: 5
I will double check but i believe the motor on and drive select are tied together , one controls drive a and the other drive B
 
Looking at the disk layout of the bootable IMD images they do seem to be laid out in sequential ordering, 1,2,3,4,5, with each sector being 1024 bytes in size.
 
Klyball said:
I will double check but i believe the motor on and drive select are tied together , one controls drive a and the other drive B
Click to expand...
That would be helpful. I'm coming at this from the software side so all I figured out was based on how the current 8k rom interacts with the controller, and since it only needs to access drive A i'm not seeing how drive B is selected. If we had a working CP/M boot disk I could just boot that and then try accessing the second drive to see what was being written to what registers.
 
brijohn said:
That would be helpful. I'm coming at this from the software side so all I figured out was based on how the current 8k rom interacts with the controller, and since it only needs to access drive A i'm not seeing how drive B is selected. If we had a working CP/M boot disk I could just boot that and then try accessing the second drive to see what was being written to what registers.
Click to expand...
@brijohn It looks to me like bit 0 is density select, bit 1 is drive A and bit 2 is drive B bit 3 is unused its connected to the flip flop but the outputs are unconnected.possibly was for motor on , but by looking at the board in the drive the drive a and b lines connect to 2 pins each but don't share . but with out seeing where they go i guess the are strapped to motor on which means the motor is always on.
 
Klyball said:
@brijohn It looks to me like bit 0 is density select, bit 1 is drive A and bit 2 is drive B bit 3 is unused its connected to the flip flop but the outputs are unconnected.possibly was for motor on , but by looking at the board in the drive the drive a and b lines connect to 2 pins each but don't share . but with out seeing where they go i guess the are strapped to motor on which means the motor is always on.
Click to expand...
Thanks for the information. I've updated the emulation to handle drive selection based on this.
 
Started work on integrated network adapter emulation for my mame core. So far I have it going through the handshake protocol to the point where it waits for a file transmission. Still need to implement sending of the segments to the emulator, the current issue is I'm not 100% sure how to correctly calculate the CRC value at the moment.
 

Attachments

  • network_adapter_wip.png
    network_adapter_wip.png
    124.6 KB · Views: 6
brijohn said:
Started work on integrated network adapter emulation for my mame core. So far I have it going through the handshake protocol to the point where it waits for a file transmission. Still need to implement sending of the segments to the emulator, the current issue is I'm not 100% sure how to correctly calculate the CRC value at the moment.
Click to expand...
There is a routine in the ROM at 065d if my memory serves... It uses a table to do a CRC. To get the two bytes that go at the end of the packet you xor the CRC up to that point with 0xffff and the result of that will give you the two bytes to go at the end of the packet.

github.com

nabu-tftp/tools/packetize.c at main · dkgrizzly/nabu-tftp

TFTP Gateway for NABU-PC using a Raspberry Pi Pico W - dkgrizzly/nabu-tftp
github.com github.com

Has code for packetizing a undecorated .NABU (segment) file. I haven't deciphered the .npak files the DJ's tool uses, they appear to be scrambled or encrypted, and it was easier to simulate the nabu side of the comms and pull all the packets that way.
 
GrizzlyAdams said:
There is a routine in the ROM at 065d if my memory serves... It uses a table to do a CRC. To get the two bytes that go at the end of the packet you xor the CRC up to that point with 0xffff and the result of that will give you the two bytes to go at the end of the packet.

github.com

nabu-tftp/tools/packetize.c at main · dkgrizzly/nabu-tftp

TFTP Gateway for NABU-PC using a Raspberry Pi Pico W - dkgrizzly/nabu-tftp
github.com github.com

Has code for packetizing a undecorated .NABU (segment) file. I haven't deciphered the .npak files the DJ's tool uses, they appear to be scrambled or encrypted, and it was easier to simulate the nabu side of the comms and pull all the packets that way.
Click to expand...
Thanks, that was what I needed. My code can no successfully load local .nabu segments and send them to the emulator.

MAME running the NABU hello world tutorial.mame_nabu_hello_world.png
 
I couldn't wait, so I compiled your code and gave it a try. It took me a while since I've never compiled or even really used MAME before. Fantastic work! I want the real hardware but this is a great alternative and the faster loading times are a nice advantage.

 
Last edited:
Ok, I'd love to know what I did wrong then because I cloned the repo, built - but I just get keyboard failure and adaptor failure.
 
hupshall said:
Ok, I'd love to know what I did wrong then because I cloned the repo, built - but I just get keyboard failure and adaptor failure.
Click to expand...
The keyboard and adaptor aren't virtually plugged in by default.

This is what I had to figure out, not sure if it's the best way but it worked.

First run DJ's NABU Internet Adapter and click Start TCP.

Then use this command line to start your compiled mame:

mame nabupc -kbd nabu_hle -hcca null_modem -bitb socket.127.0.0.1:5816

After it starts, push tab, go to machine configuration and set the baud rate to 115200.
 
Last edited:
Is there a MAME setting to make the keyboard less sensitive or would I need to change the code? I can't really navigate the menu properly with the keyboard. It works fine with my controller.
 
You must log in or register to reply here.
Back
Top