• Please review our updated Terms and Rules here

NABU PC Emulation under MAME

The second message is normal and shouldn't be a problem. For the Wyse terminal to work however you need to make sure you have reset its nvram before trying to use it, to do this hold the g key down while booting it up. If you do it correctly the screen should flash with a print out of the various characters and you should see at the top of the screen above the solid bar the letters "FDX".

That was it, thanks. A quick run at google didn't turn up anything referencing the need for that, is it a fairly common requirement with emulated machines in mame?

Regardless, I clearly have much to learn about it.
 
That was it, thanks. A quick run at google didn't turn up anything referencing the need for that, is it a fairly common requirement with emulated machines in mame?

Regardless, I clearly have much to learn about it.

Like a lot of things in mame, you have to read the source code for notes:

from src/mame/wyse/wy50.cpp

To initialize EAROM settings on the WY-50, hold down the G key while
booting. The equivalent procedure on the WY-75 uses 5 on the numeric
keypad instead.

I was baffled too when I first tried to use the wy50 8-)

And I was having trouble with the 8k roms on the Nabu until I realized that you had to switch the 4k/8k rom bios size in the machine configuration.
 
For the Wyse terminal to work however you need to make sure you have reset its nvram before trying to use it, to do this hold the g key down while booting it up. If you do it correctly the screen should flash with a print out of the various characters and you should see at the top of the screen above the solid bar the letters "FDX".
That also solved the output-problem for me with the Wyse50 - but had to reboot after the G-NVRAM-Reset to make it work :)

BTW: Is there any command-line to use such a MAME-Terminal (like Wyse 50 or the VT100/240)
with a normal COM-device on a Windows-PC?
I did try
mame -window wy50 -modem null_modem -bitb COM3 or
mame -window vt100 -rs232 null_modem -bitb COM19
to connect the WYse 50 to COM3, but that didnt worked :(
(And does the VT100 also need a NVRAM-Reset?)
 
Last edited:
That also solved the output-problem for me with the Wyse50 - but had to reboot after the G-NVRAM-Reset to make it work :)

BTW: Is there any command-line to use such a MAME-Terminal (like Wyse 50 or the VT100/240)
with a normal COM-device on a Windows-PC?
I did try
mame -window wy50 -modem null_modem -bitb COM3 or
mame -window vt100 -rs232 null_modem -bitb COM19
to connect the WYse 50 to COM3, but that didnt worked :(
(And does the VT100 also need a NVRAM-Reset?)

running a ./mame wy50 -listslots

Code:
SYSTEM           SLOT NAME        SLOT OPTIONS     SLOT DEVICE NAME
---------------- ---------------- ---------------- ----------------------------
wy50             modem            dec_loopback     RS232 Loopback (DEC 12-15336-00)
                                  ie15             IE15 Terminal
                                  keyboard         Serial Keyboard
                                  loopback         RS232 Loopback
                                  mockingboard     Sweet Micro Systems Mockingboard D
                                  null_modem       RS232 Null Modem
                                  patch            RS-232 Patch Box
                                  printer          Serial Printer
                                  pty              Pseudo terminal
                                  rs232_sync_io    RS232 Synchronous I/O
                                  rs_printer       Radio Shack Serial Printer
                                  sunkbd           Sun Keyboard Adaptor
                                  swtpc8212        SWTPC8212 Terminal
                                  terminal         Serial Terminal


You might try a pseudoterminal, in linux once you launch mame there's a new entry in the UI menu that says "Pseudo Terminals" that will tell you where it connected it to, in my case it was /dev/pts/4.

./mame wy50 -modem pty


I can then do stuff like "ls > /dev/pts/4" and see the listing appear on the terminal (garbled a bit since the newlines don't match carriage returns) and also do "cat /dev/pts/4" and see the what I type on the console.

You might try something like "cat /dev/pts/4 | COM3" or "cat /dev/pts/4 > COM3" and see if it will copy the data through. You could even try netcat with the bit banger socket.
 
Last edited:
That also solved the output-problem for me with the Wyse50 - but had to reboot after the G-NVRAM-Reset to make it work :)

BTW: Is there any command-line to use such a MAME-Terminal (like Wyse 50 or the VT100/240)
with a normal COM-device on a Windows-PC?
I did try
mame -window wy50 -modem null_modem -bitb COM3 or
mame -window vt100 -rs232 null_modem -bitb COM19
to connect the WYse 50 to COM3, but that didnt worked :(
(And does the VT100 also need a NVRAM-Reset?)
So I don't have windows system to try on, but I'm pretty sure that you should be able to to just use COM<n> and have it bitbang out a standard windows COM port. At least there are various online references that suggest that is possible. I'm not sure why that does not seem to be working in your case.
 
So I don't have windows system to try on, but I'm pretty sure that you should be able to to just use COM<n> and have it bitbang out a standard windows COM port. At least there are various online references that suggest that is possible. I'm not sure why that does not seem to be working in your case.

I saw that as well, but in my testing mame just hangs when specifying a com port for -bitb. That said, I've figured out how to connect mame to a terminal emulator (and this method may well work for a physical port as well):

teraterm_nabu.jpg

I used a couple of programs to handle the IP to serial connectivity, specifically com0com and hub4com. I used com0com to create a virtual com port pair at the com0com command prompt:

Code:
command> Install PortName=COM8 PortName=COM9

I then used hub4com to handle IP connections for one of the virtual ports:

Code:
.\com2tcp \\.\com8 127.0.0.1 5817

In my case, I used teraterm configured to connect to the other virtual rs232 port (com9).

Last, start mame as per usual:

Code:
./mame nabupc -kbd nabu_hle -hcca null_modem -bitb socket.192.168.168.16:5816 -bios 2 -option1 fdc -flop1 disks\nabupc\leo1.img -flop2 disks\nabupc\leo2.img -option3 rs232 -option3:rs232:rs232 null_modem -bitb2 socket.127.0.0.1:5817

Did the device assignments in CP/M, and it worked fine. Teraterm is set up as a vt100, but I imagine any terminal emulator running any specific emulation you wish should work fine as well. If attempting to use a physical port, you may only need to use hub4com, but I haven't tested that.
 
Last edited:
I think I've managed to collect most of the files of a development environment that would at least build Pac-Man, Q*Bert, and Miner 2049er. Our dev environment was set up on E and F. It would include M80, L80, and some other goodies including SUPERCPM.

Following instructions earlier in the thread :
Thanks Brijohn

Using the following in /etc/cpmtools/diskdefs:
Code:
# Nabu hard disk 2nd partition F: (don't use on .chd file; use only after converting to .raw)
diskdef nabu-hddf
    seclen 512
    tracks 1224
    sectrk 16
    blocksize 4096
    maxdir 256
    boottrk 980
    os 3
end

worked just fine (I tried 980 earlier, but the maxdir wasn't changed to 256) to access and copy to F:

Workflow to add files to hdd.chd:

1. extract .chd to .raw: chdman extracthd -i hdd.chd -o hdd.raw

copy files (cpmcp), remove files (cpmrm), or list files (cpmls) using "-f nabu-hdd" or "-f nabu-hddf" with hdd.raw
i.e. to copy file.ext to F: cpmcp -f nabu-hddf hdd.raw file.ext 0:
i.e. to list files on E: cpmls -f nabu-hdd hdd.raw

2. create .chd from .raw: chdman createhd -c none -chs 306,4,16 -i hdd.raw -o hdd-new.chd

The assumption is that you use the files earlier in the forum for the .chd so the cylinders/heads/sectors is: 306/4/16
You can verify the cylinders/heads/sectors with: chdman info -i hdd.chd)

I found that cpmls doesn't show anything on the extracted RAW. I can use cpmcp to copy files to it, and they show up. I'm sure I'm missing something basic, since all of the software involved is new to me. Has anyone else had this problem?
 
I found that cpmls doesn't show anything on the extracted RAW. I can use cpmcp to copy files to it, and they show up. I'm sure I'm missing something basic, since all of the software involved is new to me. Has anyone else had this problem?

Which definition are you using? In my case, the nabu-hdd definition shows a few files present:

Code:
.\cpmls -f nabu-hdd .\nabu\hdd.raw
0:
ccp.com
cpm3.sys
date.com
nabushow.com

However, nabu-hddf shows no files.
 
Keep in mind that the specific nabu-hdd and nabu-hddf definitions were based on specific creation of hdd image of 10MB (details in earlier post) not necessarily the same as a physical device. I suspect that is the problem.

Regarding drive F: being blank when using properly prepared image, copy or create a file inside of CP/M and then test after (make sure you extract to raw before using cpmls).
 
I think I've managed to collect most of the files of a development environment that would at least build Pac-Man, Q*Bert, and Miner 2049er. Our dev environment was set up on E and F. It would include M80, L80, and some other goodies including SUPERCPM.

Following instructions earlier in the thread :


I found that cpmls doesn't show anything on the extracted RAW. I can use cpmcp to copy files to it, and they show up. I'm sure I'm missing something basic, since all of the software involved is new to me. Has anyone else had this problem?
What raw file are you using? Is this a dump of one of your hard drives? The details of those disk defs are based on the 10 MB image i created for mame and may not work for other images correctly. The drive E one should work as long as your drive has 4 heads and uses 16 sectors for per track. However the nabu-hddf is based on knowing exactly where the second directory structure starts, which could be different on another drive and therefor the boottrk value would nee to be different to ensure we start looking for the directory at the correct spot.
 
What raw file are you using? Is this a dump of one of your hard drives? The details of those disk defs are based on the 10 MB image i created for mame and may not work for other images correctly. The drive E one should work as long as your drive has 4 heads and uses 16 sectors for per track. However the nabu-hddf is based on knowing exactly where the second directory structure starts, which could be different on another drive and therefor the boottrk value would nee to be different to ensure we start looking for the directory at the correct spot.
I'm using the hdd.chd that was supplied by you originally. I did manage to get stuff transferred to it, though. M80 and L80 are working.

I don't plan to dump the old hard drive until I have access to better expertise and tools. I think I can build the development image from the floppy images I've already analyzed.
 
I'm using the hdd.chd that was supplied by you originally. I did manage to get stuff transferred to it, though. M80 and L80 are working.

I don't plan to dump the old hard drive until I have access to better expertise and tools. I think I can build the development image from the floppy images I've already analyzed.
Yeah my original hdd.chd i don't think i put anything on the F drive so cpmls naturally wouldn't show anything, but you should be able to use cpmcp to copy files to it and they ought to then show up.

For actually image old MFM hard drives, I generally use David Gesswein's MFM emulator which supports imaging drives.

Looking forward to see your HDD image with development tools you're creating though.
 
One problem I have is that I can't write to those CHD files while CP/M is running, so I gotta use floppy images for the actual building, but the floppy images do not have capacity for all the source. Did anyone create a DSDD img file to be used with the floppy subsystem that is writable?
 
One problem I have is that I can't write to those CHD files while CP/M is running, so I gotta use floppy images for the actual building, but the floppy images do not have capacity for all the source. Did anyone create a DSDD img file to be used with the floppy subsystem that is writable?
I think that is still in the works. Something about using an SD card for the target.
 
Yeah my original hdd.chd i don't think i put anything on the F drive so cpmls naturally wouldn't show anything, but you should be able to use cpmcp to copy files to it and they ought to then show up.

For actually image old MFM hard drives, I generally use David Gesswein's MFM emulator which supports imaging drives.

Looking forward to see your HDD image with development tools you're creating though.

That MFM emulator would be ideal for Leo's system, as it could image the existing drive and replace it, allowing him to use the MFM emulator in place of the ST-412, keeping the stock controller setup and running the stock software with no change.
 
I think that is still in the works. Something about using an SD card for the target.
Bummer. I'll have to wait for greater capacity to perform an actual build properly, or try to get the crank turning on the functional hardware I do have.
 
Bummer. I'll have to wait for greater capacity to perform an actual build properly, or try to get the crank turning on the functional hardware I do have.
I can probably add support for to the emulator for DSDD floppies, i'll need to figure out what the proper DPB for the DS disks is though as that is encoded as we've discovered in the out of band mfm data of track 0 and is going to be different for DS disks then it is for SS disks.
 
Bummer. I'll have to wait for greater capacity to perform an actual build properly, or try to get the crank turning on the functional hardware I do have.

An additional option is to modify the simple compact flash "adapter" here to use the FDC connector.

I have uploaded a modified ROM and CP/M 3.0 disk image to the repository that can be used to boot from the compact flash as the rev29 ROM, boot block, boot loader, and CPM3.SYS file have been altered to speak LBA IDE. This should still retain the original floppy support when chained through a floppy controller as very little code was changed.

Using this in mame will require an additional IDE device to mimic the hardware.
 
Bummer. I'll have to wait for greater capacity to perform an actual build properly, or try to get the crank turning on the functional hardware I do have.
thecodeman on Discord should be able to get in touch with you about the project status.
 
Back
Top