Closed colinleroy closed 3 weeks ago
Since MAME's RS232 emulation sends and receives data on a bit-serial level, the 6551 baud rate and framing parameters (normally set by firmware) are not necessarily reflected by those set in "Machine Configuration" for the null_modem
device, though they really should match.
I don't really know much about POSIX terminal programming or the handshaking properties of your /dev/tnt1
, but it does seem like it would be possible to add flow control calls and such to the pty
"pseudo-terminal" interface (though not null_modem
).
Hi,
Thank you for your answer.
So I understand that null_modem -bitb /dev/ttySxyz
treats the serial port as a simple file?
There is no way to connect the emulated RS232 device to an actual RS232 device with flow control, line status, baudrate and the other parameters passed along?
Yes, the bitbanger
device (which is admittedly poorly named) basically only provides simple file I/O. That is also basically true of the pty
interface, though more of an accident of underdevelopment. For either interface, the OSD layer provides some termios(3)
-based handling for files whose names begin with /dev/pts
(or /dev/pty
on MacOS), which to me seems a bit more rudimentary than it should be.
The fundamental issue is that MAME's asynchronous serial emulation is designed for line-level accuracy, while the character-level terminal interface provided by POSIX is designed more as a portable interface to whatever actual hardware the host system has. The two are therefore not directly compatible without some adapter code to retransmit data in the appropriate form. While it's theoretically possible to use termios(3)
calls to force the /dev/XXX
terminal's baud rates and framing parameters to match those from the "Machine Configuration" settings, it's not clear that doing so would offer any benefit when the interface device already has to convert the data transmitted as individual bits by the ACIA back to character format.
The main advantage I can think of is that it would allow support of CRTSCTS handshaking, and would help the emulated program not lose bytes when it asserts flow control. At least, that's my use case 🙂
MAME version
0.251 (ecdce6505c499531ceb3c4b70c7d59db78e8125b)
System information
Ubuntu 23.04, x86_64, en_US.
INI configuration details
Emulated system/software
apple2c0
Incorrect behaviour
The above command (
mame apple2c0 -window -flop1 mastoperso.dsk -resolution 560x384 -modem null_modem -bitb socket.localhost:2000 -nomouse -debug
) works and gives me serial communication, as long as I have ser2net running and the tty0tty kernel module loaded (which does pair virtual ttys).However, with this solution the line status is completely ignored.
I have understood that I should be able to pass
-bitbanger /dev/ttySomething
to use a file directly, and hoped that it would solve hardware handshaking issues. However, in this mode, whatever is configured in MAME's OSD UI "Machine configuration" tab, the serial device stays set at 38400bps and communication doesn't work.Linked issue: The ACIA 6551 has control registers that allows to dynamically set parameters like speed, data bits, stop bits etc. I would expect changing the ACIA settings via its registers to reflect on the "Machine configuration" tab, but it does not.
Expected behaviour
I expected the Machine Configuration settings to be reflected on the serial device, using tcsetattr() calls. However this is not the case according to
strace
.I would love to improve this myself if this is welcomed by MAME's team, however, I have to admit that I don't understand at all how the firmware / port / bitbanger are linked together.
Thanks!
Steps to reproduce
mame apple2c0 -window -flop1 mastoperso.dsk -resolution 560x384 -modem null_modem -bitb /dev/tnt1 -nomouse -debug
In Machine Configuration, the "RS232 null model [root:modem:null_modem]" configurations are shown as: Flow Control: RTS Data bits: 8 Parity: none RX Baud: 19200 Stop bits: 1 TX Baud: 19200
However
stty -F /dev/tnt1
shows:Additional details
apple2c0 has an ACIA 6551 in slot 2.