Emacs, tabs and helpers in general

I just had to dig up this after a discussion about TABs and coding standards. I prefer not to think about it, but most editors these days tries too much to be helpful including my old friend emacs. As soon as you are closing a paranthese, opening a comment or just tries to code in general it does the equivalent of that annoying spell checker.

What about all these helpers that nags at your attention, patience and defocuses yourself from the task you are trying to accomplish, who asked for these? It all started with the biggest annoyment there ever was, the Office Assistant Clippy!! Released around 1998

This flirting annoyment almost shortened my life by the lionpart when it arrived. To start with it was almost impossible to turn off and secondly the computers were already on their knees when it made the situation even worse and trying to be funny. My mother loved it though.

After that there have been a never ending stream of annoying helper additions for ignorant, illitterate and lazy people! I am probably all of that but I didn't ask for auto-spellers, tripple are-you-really-sure alerts and what triggered this rant: auto-indenters

Emacs was my friend up until it came with predefined language support where the indention style was predefined in some LISP file somewhere on your harddisk. Never in the same place and often your changes to it didn't take any effect because of god-knows-what!

In any case for the moment I found it for my Windows Emacs and also what to change: Edit the c:/Users//AppData/Roaming/.emacs and read here about the changes you want to do:

https://www.emacswiki.org/emacs/IndentingC

It works now but soon I have forgot about it until next time I have to turn it off, change it or even turn it on. We spend too much time beeing defocused from the task we are trying to accompplish!

Another example is the auto-speller that corrects whatever I write to something readable. I only have to hit keys close to the ones that resembles a word and it even marks up the errors in grammar. Geehh I don't know how kids in the future will be able to write with a pen on a paper. Will they?

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.