Yes. A null modem worked perfectly to test the serial communication.
It have basic serial support now.
Below I am documenting some of the obstacles I ran into
when trying to implement support for graphics.
I chose SDL and the extension SDL gfx for the graphics.
It is a popular portable framework for game making.
It is hardware accelerated and even has support for OpenGL.
But I will use it only for accelerated 2D output.
Drawing ellipses, circles, boxes, and drawing pixels are quite easy,
and it will automatically accelerated by hardware if acceleration is supported.
There is a big difference in how Sim68 works.
Sim68 wrote directly to frame buffer, a Canvas.
Canvas->Pixels[x][y] = clBlue
I am trying as far as possible to keep the original source code.
I solved this by overloading twice the  operators, and finally call into the new library.
This is of course very inefficient. But luckily normal routines like drawline are not plotted pixel by pixel.
In the good old times. Writing to a memory buffer was the fastest way of outputting graphics.
Nowadays when the graphics cards are hardware accelerated,
it is no longer a good idea, because the memory doesn't reside in the pc ram, rather in the gpu ram.
Reading a pixel value is also expensive. Gpu ram has to be copied, before it can be read.
My implementation of GetPixel is therefore more expensive.
But Normal drawing should be as fast as DirectX.
The graphical framework SDL does unfortunately not implement,
the notion of a pen or a brush which DirectX does.
A quick and dirty fix would be to draw several parallel lines,
or circles on top of each other with a small adjustment in X and Y.
DirectX is also very generous in implementing several
drawing modes which affects the color by combining it against the background.
I can possibly implement it myself, but then I would probably have to set pixel by pixel.
SDL doesn't implement FloodFill either.
My first attempt to implement flood resulted in a a stack overflow when it recursively was called.
I solved this by converting the recursion into a loop.
I save the state in an std::stack, instead of in the call stack.
I will probably convert it into a fixed array and just step an index up and down.
The flood fill is of course an expensive routine to call when it is not hardware accelerated.
It worked good with a rectangle, but my current implementation fails to fill a circle completely.
It needs a couple of more tweaks.
I am considering replacing SDL with another portable framework.
But they are not so easy to find. For now I will keep it.
I don't believe in including a lot of unportable features in a portable version of the Sim68.
The current API is exposing a lot of functionality specific to DirectX.
DirectX is a quite an advanced library.
It will be hard to find a portable library that implements everything I need.
Below you can see the output of the reference example graphicSound.S68
It does look very different, but the reason for the difference
is the lack of drawing mode on the pen, pen width, and support of floodfill.
I will probably get the flood fill right eventually.
The pen drawing mode might not be a good idea to implement in software.
Maybe I have to chose a another library to get that.
To the right hand side is my version.
It is still in progress.