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
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
