• Please review our updated Terms and Rules here

NABU PC Emulation under MAME

brijohn said:
When that happens for whatever reason it is not opening a tcp connection, but simpley creating a locale file called in this case socket.127.0.0.1:5816 on your disk and writing data to it.
Click to expand...

You beat me to it, but I can confirm that a hard reset does not give the full menu, but just the option to insert a disk and press go. I can also confirm the local socket.127.0.0.1:5816 file as well. This is with the latest IA released on 12/20.
 
I've added support for rs232 boards on my emulator

When starting mame you can use the following options to create a rs232 terminal setup -option<n> rs232 -option<n>:rs232:rs232 terminal. Where n is the slot number 1-4

Inside CP/M doing device,conout=rs<n-1> will redirect your output to the terminal.

nabu_rs232.png
 
labomb said:
Very cool. Were the changes committed? My clone of your fork (nabupc_wip branch) indicates I'm up to date.
Click to expand...
Yeah they were commited to the nabupc_wip branch, before posting. If you do a git pull to should grab the latest.
 
I'll repeat, very cool :). Only comment so far is that the status LEDs are gone with the rs232 option.
 
labomb said:
I'll repeat, very cool :). Only comment so far is that the status LEDs are gone with the rs232 option.
Click to expand...
add "-numscreens n"

If using only rs232 use n=2
if using rs232 and printer (-centronics lx810l) use n=3

This will separate the screens into different windows and keep the status LEDs on the console.
 
brijohn said:
I've added support for rs232 boards on my emulator

When starting mame you can use the following options to create a rs232 terminal setup -option<n> rs232 -option<n>:rs232:rs232 terminal. Where n is the slot number 1-4
Inside CP/M doing device,conout=rs<n-1> will redirect your output to the terminal.
Click to expand...
and <n> is the same slot-No. for the 2 option entrys ;)
example:
-option3 rs232 -option3:rs232:rs232 terminal and in CP/M device conout=rs2,tv OR device conout=rs2

So we have 80 chars output via RS232 is there a chance to diable the TV-Output to see only the 80 Chars window?

BTW: The RS232-Terminal doesnt understand the ADM-A3 Screen-Codes :(
Tested with the te-editor.

NABU_80Chars_FRACTAL.jpg
 
Last edited:
guidol said:
BTW: The RS232-Terminal doesnt understand the ADM-A3 Screen-Codes :(
Tested with the te-editor.

View attachment 1250558
Click to expand...

looking at src/devices/bus/rs232/terminal.cpp it uses src/machine/terminal.h

looking at src/machine/terminal.cpp there's a fairly simple function that processes the keystrokes, it wouldn't be difficult to make this process adm3a codes given in

archive.org

ADM-3A User Reference Manual April 1986 : Lear Siegler : Free Download, Borrow, and Streaming : Internet Archive

ADM-3A User Reference Manual, April 1986.
archive.org

void generic_terminal_device::term_write(uint8_t data)
{
if (data > 0x1f)
{
// printable char
if (data != 0x7f) write_char(data);
}
else
{
const uint16_t options = m_io_term_conf->read();
switch(data)
{
case 0x07: // bell
m_beeper->set_state(1);
m_bell_timer->reset(attotime::from_msec(250));
break;

case 0x08: // backspace
if (m_x_pos) m_x_pos--;
break;

case 0x09: // horizontal tab
m_x_pos = (std::min<uint8_t>)((m_x_pos & 0xf8) + 8, m_width - 1);
break;

etc...
Click to expand...
 
guidol said:
and <n> is the same slot-No. for the 2 option entrys ;)
example:
-option3 rs232 -option3:rs232:rs232 terminal and in CP/M device conout=rs2,tv OR device conout=rs2

So we have 80 chars output via RS232 is there a chance to diable the TV-Output to see only the 80 Chars window?

BTW: The RS232-Terminal doesnt understand the ADM-A3 Screen-Codes :(
Tested with the te-editor.

View attachment 1250558
Click to expand...
CP/M uses 0 indexing for its slots, but mame starts enumerating at slot1, hence slot4 is rs3 in cp/m.

Yeah the builtin terminal doesn't really implement any screen-codes, its pretty dumb. It does create an interesting pattern though.
 
Updated the emulator with an improved builtin network adapter. There are two modes of operation local and remote. The remote one allows you to run either cycle1 or cycle2 over the internet, downloading and decrypting segments as needed. The local version is designed for home brew but can also run the official cycles if you have downloaded and decrypted them separately.

For running homebrew locally you need to necessary for the program to run together into a single zip with a .npz extension. The segment filenames should be 6 characters long with the filename being the segment id in hex (0 padded) and should have either a .pak extension if it has been pre packitized, or a .nabu extension if its just the raw binary.

These can then be run in the emulator by using -hcca hcca_local -npz <image>

The remote version can be used with -hcca hcca_remote and allows you to select either cycle 1 or 2 based on an option in the machine configuration menu in mame.

Some things don't work yet in either mode. The two most notable things are retrochat, because i don't currently support the bidirectional communication mode. Also not supported is the method used by DJ in things like bad apple to request additional assets.
 
How do you select "cycle1 or cycle2"? The option I see in "Machine Configuration" is "Prompt for channel?"

1672116221950.png
 
brijohn said:
Just checked and its definitely a weird mame bug on the hard reset. Basically mame does the tcp bit-banging byt open a "file" called socket.<host:port>. The prefix socket. tells mame its not a real file, but rather a tcp socket. The problem seems to be how mame is handling this on a hard reset. When that happens for whatever reason it is not opening a tcp connection, but simpley creating a locale file called in this case socket.127.0.0.1:5816 on your disk and writing data to it. I am unsure why this is happening but it seems likely to be an issue with mame rather then this particular core. I might do some digging if i have the time.
Click to expand...
I tested hard reset (shift F3) with other systems too: ct486 and cpc6128 while those were connected to null_modem/bitb and they had the same issue.
 
guidol said:
BTW: The RS232-Terminal doesnt understand the ADM-A3 Screen-Codes :(
Tested with the te-editor.
Click to expand...
been fiddling around with terminals, and mame has a driver for the wyse wy-50 which is supposed to do adm31 codes.

You have to reset the nvram on the wy50 for it to work, power up with the g key down. Shift+ESC will bring up the wy50 config menu.

"./mame wy50 -modem terminal" will connect it to a terminal


Run two mame instances and you can connect two wy50s to each other:

./mame wy50 -modem null_modem -bitb socket.127.0.0.1:5917 (port 5917 chosen arbitrarily)
./mame wy50 -modem null_modem -bitb socket.127.0.0.1:5917

so you could try to connect the nabu rs232 to a wy50 via a null_modem -bitb socket, note that if you have multiple bitb devices (like two null_modems) the bitb devices get an additional number attached to distinguish them like -bitb1 and -bitb2
 
brijohn said:
Updated the emulator with an improved builtin network adapter. There are two modes of operation local and remote. The remote one allows you to run either cycle1 or cycle2 over the internet, downloading and decrypting segments as needed. The local version is designed for home brew but can also run the official cycles if you have downloaded and decrypted them separately.

For running homebrew locally you need to necessary for the program to run together into a single zip with a .npz extension. The segment filenames should be 6 characters long with the filename being the segment id in hex (0 padded) and should have either a .pak extension if it has been pre packitized, or a .nabu extension if its just the raw binary.

These can then be run in the emulator by using -hcca hcca_local -npz <image>

The remote version can be used with -hcca hcca_remote and allows you to select either cycle 1 or 2 based on an option in the machine configuration menu in mame.

Some things don't work yet in either mode. The two most notable things are retrochat, because i don't currently support the bidirectional communication mode. Also not supported is the method used by DJ in things like bad apple to request additional assets.
Click to expand...
Thank you for all the amazing work you continue to do for this project.
 
jefferystone said:
I tested hard reset (shift F3) with other systems too: ct486 and cpc6128 while those were connected to null_modem/bitb and they had the same issue.
Click to expand...
So i did a small bit of looking into whats happening with this and it seems that on a hard reset mame is turning socket.<host>:<port into <path to current directory>/socket.<host>:<port>. In other words it is trying to turn what it thinks si a relative path into an absolute path. However when this goes to to open call for osd_file this means that it no longer starts with socket. and therefor the open call does not think its a socket, but rather a real file.

Not sure why or where the filename is getting made into an absolute path though.
 
brijohn said:
So i did a small bit of looking into whats happening with this and it seems that on a hard reset mame is turning socket.<host>:<port into <path to current directory>/socket.<host>:<port>. In other words it is trying to turn what it thinks si a relative path into an absolute path. However when this goes to to open call for osd_file this means that it no longer starts with socket. and therefor the open call does not think its a socket, but rather a real file.

Not sure why or where the filename is getting made into an absolute path though.
Click to expand...
You may ask the mamedev forum (or I might after they approve my registration) to see if someone else can help as this is a global/common issue.
 
It looks like the src/lib/util/zippath.cpp has a revised_path variable that is used during load_image_by_path

revised_path is only called from:

devices/imagedev/floppy.cpp
emu/dislot.cpp
emu/diimage.cpp

I wish I knew enough C++ to help troubleshoot this.
 
jefferystone said:
It looks like the src/lib/util/zippath.cpp has a revised_path variable that is used during load_image_by_path

revised_path is only called from:

devices/imagedev/floppy.cpp
emu/dislot.cpp
emu/diimage.cpp

I wish I knew enough C++ to help troubleshoot this.
Click to expand...
Yeah thats what i was seeing as well. it takes the revised_path set by zippath_fopen and sets that as the image path. Initially things work since the first time it is called our path has not been revised, after a hard reset however we will be using the updated path.

I do have a fix that i think should work for this though. The revised_path is set by the OS dependent osd_get_full_path function. If we modify that function to check for a special path (socket,ptty,domain socket) and not in those cases try and get the full path then things work as expected. I'll look into making a patch to fix this issue.
 
You must log in or register to reply here.
Back
Top