Hello fellow coders.

I would like to give a brief status update on my port of EASy68K to un*x/win32
First a little about myself. I work mostly with C++ and C#.Net on the windows platform,
but I have both used and developed unix software.

I think the EASy68K simulator is easy to use and very neat,
but at home I use a mac book pro, meaning that I have to run it
in a virtual machine overtime I want to run it.
When I browsed the forum I saw that someone else tried to port
the software, but unfortunately didn't finish it.

Since the source is available I think I am going to try to do it too.
I don't really need to do a port, using it in a virtual machine is ok,
but it is a nice hobby project to do.

This is the current status of the code.
* 4 different parts (Edit68K (Editor) , Edit68K(Assembler), Sim68K, EASyBin)
* Compiled against the Borland libraries (non portable)
* Only compilable with Borland C++
* Uses DirectX and some other non portable libraries.

Doing a port one should not underestimate
the risk of introducing bugs when code is rewritten.
At least 4 parts needs to be rewritten in a port.
1. One has to replace the non portable libraries (find a replacement or create a replacement)
2. One has to replace the calls to the non portable libraries.
3. One has to rewrite some routines if a library works completely different, like graphics or sound libraries.
4. Rewrite the GUI

Some of the ports of EASy68K that was started that I have seen, take on all 4 at the same time.
This introduces more risk, and it is harder to compare the original code and the new.

I decided early to just take on point 1.
I believe the other are optional.

If the code uses AnsiString, TForm, IDirectMusicLoader8, etc.
Why is there a need to change that?

Instead I reimplemented AnsiString, TForm, IDirectMusicLoader8.
Or at least created typedefs/interfaces/wrappers for them.
This way I will keep the original source code intact.

So far I have ported the Assembler
and I am on my way porting the Simulator.

This is currently working in the port
1. Running 68K assembly (run /step into)
2. GUI - I am using a console window at the moment.
3. Output to screen is partially working (console)
4. Buttons
5. Switches
6. Leds
7. Seven digit display
8. Interrupt buttons
9. Sound (using SDL2)

This is missing
10. More GUI interaction
11. Setting Interrupt Timers
12. Serial communication
13. Net Sockets.
14. Graphics output.

I will implement inet sockets next.
Probably I will skip the setting of the interrupt timers until I have created a real GUI.

The assembler is ported already, and I am working on the simulator.
I have not decided yet if I will port the Editor and EASyBin.

I am still developing, but I only have 30-60 minutes per day.
I have a family to attend also. But I think I will have some more time during X-mas.
Now I am done with the implementation of network sockets.

Normally when receiving one specify the Socket to read from.
In the example echoServer case it uses the deprecated API
which specified only remote IP.
This is a problem if multiple sockets are open to the same IP.

I was considering skipping implementing the deprecated APIs.
But I implemented it anyway.
It works for UDP but not for TCP. But the same behaviour has EASy68K.
In the documentation one could believe it should work for both, but it doesn't.

I have started with the implementation of the graphical output window.
and already display some text in some font, and I also get input from it properly.

The number of columns in the output screen depends on the font tsize.
The "best" font would be a monospaced font.
That would speed up rendering in so many ways.
that would also solve text wrapping in an elegant way.

Regarding testing serial communication.
Prof Kelly. I should be able to use a nullmodem, doing a loopback connection for that, right?
Fortunately I have 2 usb-serial converters + nullmodem.

A null modem cable should work. I have not done that with two USB to serial converters but I think they should support it. I tested the serial communications by connecting to my 60000 ECB board, so EASy68K was a terminal that I used to talk to my real 68000

_________________
Prof. Kelly

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.

I have had some progress with the port.
I started on creating a GUI for the Sim68.
I chose FLTK. Fast Light Toolkit.
It is a framework that favours size and speed over functionality.

Its drawing capabilities and performance was astonishing.
It was a good candidate for replacing SDL which I had used before for the gfx output.
Said and done, Now I have replaced the SDL output window with a FLTK output window.

Due to how things are rendered in Sim68K,
I never could leverage the speed of SDL.
I had to redraw after each drawing operation.
For making games where you can gather several operations
and draw them all at once, SDL might be a better option.

For drawing I use a backbuffer,
without forcing a redraw. I just schedule it for redraw.
That way several drawing operations can go into the same redraw.
SDL didn't fit so well. I had to force a redraw after each operation.
Because I could not know if another drawing operation would follow.

FLTK supports backbuffer, hardware acceleration, and supports more drawing routines.
The filler is not supported in SDL, but it is in FLTK.
It also supports different pen sizes and drawing modes.
It is a fantastic framework.

Next I will work on the fixing the pen sizes
and see what pen drawing modes that are supported.

Here is a screenshot.
The GUI is actually not the original Sim68K GUI.
i intentionally made it look the same.
Why change something that works?

It looks very good.

Perhaps we should consider adding an additional function to Trap Task 32 that returns the identity of the simulator.

D1.B = 08, Return the Sim68K Identity in D1.B.

Windows implementation returns 1.
Linux/UNIX implementation returns 2.

_________________
Prof. Kelly

Now most of the simple GUI operations work. (Run, Step, Trace, Reload)
Graphics output is working, except for the Pen Mode feature that is not portable.
Messages for the user are also displayed correctly.

I also added a GUI for the Hardware Window.
So far I have connected the Leds, buttons, and the switches.
The digits and the IRQs are missing, but shouldn't be any problem.

The rewind doesn't work yet.
I am a bit unsure how to implement it, and how it is different from a reload.
Shouldn't both operations reset the memory and registers and reset the PC?

The new trap task could be added,
but why would it be interesting to know from the running program
if it is running under Linux or Windows?

There might be differences between the Windows and Linux implementations. Providing a Trap task to return the host platform to the running program might be useful.

_________________
Prof. Kelly