[Simh] SIMH GUI

[Holger Veit]

Am 10.05.2011 09:40, schrieb Dave:
> Richard,
>
>   Just a note to say that I believe that the Hercules IBM Mainframe emulator
> uses a pipe to communicate with its GUI which then runs as a separate task.
> There is a startup parameter to tell the emulator its under control of a
> GUI. When it sees this it then sends status information at regular
> intervals.
>
> This means the GUI is pretty independent of the core emulator code. In fact
> there are at least two GUIs for Hercules, a Windows one, and a DOS one.
>
> One issue I can think of with SIMH is that certainly with the 1130 emulator
> when the console has a read posted I don't think its possible to enter SIMH
> commands at that point. Hercules avoids this issue on its integrated TTY by
> having an escape character for console input.
>
> Hope this provides some food for thought
>
> Dave.
>
> P.S. I was wondering if it might be useful to have some general definition
> of device i/o over IP. That would allow re-usable device emulations, such as
> say the Calcomp plotter, to be re-used with multiple emulator cores...
>

Actually, the latter summarizes a pet project I have in mind concerning 
simh (unreleased, but
some of these ideas I am toying with in the SAGE-simh simulator).

What is already possible is attaching a terminal emulator to a serial 
device, by using the terminal
multiplexer API. This hasn't been implemented in all simulators, though, 
but it might be a starting
point to construct a homogeneous interface.

An abstracted device in simh could this way be implemented in a 
two-layer manner:
- "low-core"-interface that provides the programming interface to the 
CPU, and
- the device independent API, e.g. the terminal multiplexer that does 
the real work.

I have used this concept with the SAGE m68k stuff which is a typical 
implementation
of a microprocessor board:
- it has chips with registers that are addressed in the memory or I/O 
range of the processor,
- which then interface with an I/O layer that could be either real 
device code (such as the IMD interface
to disks) or a socket abstraction layer.

The 8080/z80 Altair simulator follows similar ideas, but does not 
strictly distinguish simh devices
and hardware chips, which made it impossible for me to reuse code from 
there, although
the SAGE has the same floppy controller chip. The device concept IMHO 
was largely designed
for the classical mini computers, and thus does not match this kind of 
two-layered device model;
it requires additional context information when applied to a system with 
multiple LSI circuits.

Besides these issues, the general problem is that such abstraction APIs 
need to be defined well in
advance to be general enough.

For the serial I/O device, there is a useful abstraction as the terminal 
multiplexer which allows
to attach independently written terminal emulators, but this is mainly 
because it is just about
transferring untyped byte streams (which get their semantics from the 
emulated operating system,
such as interpretation of ESC sequences).

For other devices, we do not have these yet. The question here is: what 
is a simh GUI supposed to provide?
You need a button to boot a machine? You want to issue simh commands in 
a nicer way?
You want to have a log window for "console" messages? You want to have a 
means to reconfigure
the hardware, attach disks or paper tapes to devices, provide abstracted 
printing services?
You want abstracted bitmap devices for video (there is already X11 which 
provides this, but it is rather
uncomfortable to handle - SDL is better but still not easy stuff out of 
the box)?
You want to have a frontpanel, or 7-segment hex display?

As long as it is not clear what a GUI should do it is not possible to 
isolate it from the core simulator.

This brings up the question that also MESS and other approaches have: 
how does one avoid duplicate
design work to get a new simulator done? If I would like to add another 
Z80 based system, for instance,
would I be able to lift some stuff directly from the Altair? If I would 
like to write some T11-based microcontroller
board, could the pdp11_cpu.c file be used unmodified for this? I am 
afraid it couldn't, as there is still too much
system dependence to the PDP or Altair configurations in these files. No 
LEGO bricks.

Regards
-- 

Holger