MAME: Esselte 100 and serial support

The Esselte 100 has a rudimentary serial port that is available on the multi faceted I/O port labeled "Printer" where also the different measurement experiments are attached. In order to use the serial port in the emulator it has to be started with an emulated null modem cable attached to something.

In this example we will run it against a Telnet terminal. In order to get out of the emulated world and into the real world we attach it to a bit banger device which in turn needs to be attached to a socket server. These parts will translate the emulation time serial communication into a data stream through the socket server to the telnet terminal.

The null modem has built in support for the bitbanger and does the translation between stream data and the selected baudrate. This is how you set up MAME to work this way:

First you can check what devices is supported by a certain driver. The driver for Esselte 100 is called e100 and the option to use is called -listdevices:

The interesting information here is "RS232 Port" because it is a slot device which we can explore further with the -listslots option:

Here we can see that the RS232 port device called 'rs232' supports null modem. From not so well known sources we also know that the null modem support a bitbanger device which in turn accepts a socket address as argument like this:

This will start MAME as we want it to, The connection between the PIA pins and the rs232 device is defined in the emulation driver for the Esselte 100 and not something we can change from the command line. Once MAME is started you can open Putty.exe or you favorite Telnet terminal and connect it to the socket server using 127.0.0.1 (or the IP address of the machine running MAME if you are using a Telnet terminal on another machine) and port 4321 ( can be change to any port ).

Skip through the alerts at the beginning af the MAME session and at his point you will see two windows, one with Esselte 100 and one with the Telnet terminal:

The Esselte 100 starts in 7 bit, 1 start bit, 2 stop bits and 300 baud so we need to set up the null modem to talk to us at this speed through the internal menu system of MAME. This is enabled by pressing Scroll Lock and then TAB. Enter the "Machine Configuration" menu and change the settings accordingly:

Press TAB to exit the menu and select the Esselte 100 window. In order to use the serial port easy there is a terminal mode built in which takes the baud rate as argument:

Press some keys and there should be text in your Telnet terminal, the emulation has escaped into the real world!! :)

Not much more works at this point but this is a generic method how to connect emulated system with each other or to the outside world, enjoy!

MAME serial support Part II

I have previously submitted a driver for the Zilog SCC, Serial Communication Controller, to MAME, improving it while working on different board drivers needing it. While one would want everything to be emulated correctly from start it crucial to find some legacy code to test the feature at hand. Unless you do the effort is not useful anyway.

Usually a board initiates the SCC and start sending characters through it to an unknown device at the other end. The device on the other end will eventually send something back and the firmware will respond to it. Quite simple ehh!?

The way this is done can differ a lot though and if a feature used is not emulated or previously tested it is important that the board writer get useful messages using the logerror(). I usually start with that, creating logerrors for everything that doesn't work, so when a new software is tested there are printouts saying that this feature is not implemented. Then it is Time to call Saul.

[ The logerrors are seen in the debugger log window. The debugger is enabled by the -debug command line switch from where you start the board driver with F5, but first you want to open the log window by Ctl-L. ]

When writing the board driver for the MVME-147 I had problems getting the keyboard on the terminal to produce input. The funny thing was that the output worked just fine. Hmmm... I had to dive into the core code to understand how this was possible. The core feature that allows us to connect a serial device to a terminal as previously explored is mainly kept in src/emu/diserial.cpp

I had recently added support for SCC:s internal baud rate generator by adding a timer. It worked in the board driver for hk68v10 board but for MVME147 it failed. I pretty soon figured out that the serial timing was not working since I sometimes got a character through but sometimes the system got it wrong by just a bit or so.

I had to investigate it of course and I found several weaknesses of my first implementation in relation to how diserial works and can do for you. Here is my post on the MAMEdev forum summarizing it like this:

"I found the bugs finally, it was due to that it is not possible to use diserial the way I did with local baudrate timer in the SCC device. I got it nearly to work one way as can be seen above but when sending keypresses the other way there was problems. The SCC device wasn't producing exactly the right baud rate but nearly enough to being able to send characters from the board to the terminal, but in the opposite direction there was not start bit detection and there was no mid bit alignment in the SCC device. Even after adding that it turned out that I didn't get the final transmitt_complete because it also had no stop bit detection... So I relized I was reimplementing diserial in the SCC device and after I relized that it took me just 20 minutes to implement the baudrate timer using the diserial setrate() functions. So that part is now rock solid compared to how it was and the MVME-147 driver was submitted a few days ago with a working 147-Bug> terminal."

So to not reinvent the wheel you need to recognize a wheel...

Serial ports in MAME part I

Serial port emulation is a much more intriguing subject than you probably think. I am writing on a number of pages exploring different aspects of the support for serial ports in MAME. The first one is describing what a typical addition of a serial port to a board driver looks like and you can check it out here: serial-port-in-mame.html

Adding the serial port is the easy part, as a board writer you often just find a board that has a similar feature to what your board has and copy the apropriate lines to your driver. However, unless you know how it works the driver will probably not work properly or to the full extent.

In the other end of the RS232 cable there is another device, normally a terminal or a printer but it can be anything. MAME has some default devices that behaves like that class of devices normally behaves.

A MAME top level board driver describes a system rather than a board so the name board driver is somewhat misleading. In MAME you start the board driver and give it configuration options to activate one of many preconfigured devices compiled into MAME that is pre configured to work with that particular driver. For instance there can be a default serial terminal device configured, in which case a terminal window just pops up and starts working without any extra parameters:

./mame fccpu1 -window

There are options that I have not yet explored to connect MAME to a real terminal, this has another set of host related problems that I intend to look at later.