[Simh] SIMH GUI
Holger Veit
holger.veit at iais.fraunhofer.de
Wed May 11 10:46:56 EDT 2011
Am 11.05.2011 15:48, schrieb dott.Piergiorgio:
> Il 11/05/2011 11:34, Holger Veit ha scritto:
> o.
>> SAGE, as in www.sageandstride.org
>
> An (interesting) case of same naming, indeed...
>
> Interesting because this can be a good starting point for the sorely
> lacking emulation of a non-multimedia, non-graphic machine based on
> the 68K (there are many 68K CPU emulator code, but I guess that having
> a plain 68000 system emulated is useful....)
>
> I' still working (on and off) on the Occam treatment of a pair of
> simh_$CPU prior of doing an actual CPU implementation (I'm toying
> around an idea of an hypotethical 6-bit CPU (think if Intel produced
> as intermediate step, a 6006 between the 4040 and 8008) then, fool
> around 8008 emulation ;) )
>
> The most dear thing on SIMH code is that is relatively easy to "plug
> in" diverse hardware emulation (IMVHO is not by chance that the main
> fork is the altairZ80 project, and I guess you known well how diverse
> was the S-100 hardware...) and with a graphical hardware emulation
> (not limited to screen graphic, but also LED and, aptly for the
> "trailing edge" SIMH emulates, the blinkenlighten always associated
> with the large 1950s to 1970s machines) the usefulness of SIMH
> trascend the field of emulation, and can be really a core package in
> didactics (I don't hide that will be really interesting the emulation
> of the mid-1970s microprocessors/controllers SBC trainers...) research
> and like fields (last but not least the digital archeology, as pointed
> by Kossow's efforts in running 1960s software under emulator
> environments)
>
> heh... now I realize that this discussion ought not to be confined to
> both of us, so I let you decide if this ought or not to be reposted on
> the ML and if so, please feel free to do so :)
>
> Best regards from Italy,
> dott. Piergiorgio.
Hi,
To begin with the last section: I have no problems with reposting to the
list, as it is beginning to be a general interest thing, maybe it is also a
matter of the sage_dev list (provided your are a member). The whole
discussion thread being started is a bit about the future of simh.
I already mentioned MAME/MESS as another emulation project which is
better known, and which provides more emulators, also and mainly
for the microcomputer era which is so far only scratched by the
AltairZ80 and the upcoming m6800 and m68k emulators.
I don't like the MAME/MESS horde, though, for some reasons, so I rather
spend my time for simh instead to make it better than just the
frequently used PDP and VAX simulation platforms.
simh, IMHO, was built around the mini-computer paradigm of having
separate boards in a cabinet, each being one or more entirely isolated
device(s), that exclusively communicate through a general bus, but with
the exception of a general DMA concept, not between each other.
This makes it difficult for emulating more closely coupled microcomputer
systems, because a strict separation of devices does no longer
exist. The FDC is a separate device, but it is connected not to
daisy-chained interrupts on something like a QBUS, but communicates with a
more or less programmable interrupt controller (e.g. an i8259A PIC). The
difficulty to simulate this is that the PIC itself behaves as a device to
the CPU, but it glues together other devices. Similarly this happens to
a programmable DMA controller. The FDC of the mentioned SAGE does not,
in contrast to the reference FDC in the AltairZ80, use DMA, but polled
I/O, so that lego block turned out to be non-fitting. The hard disk
controller of the SAGE machine is not monolithic, but consists of
various TTL and LSI circuits, some of which (like 8253 counters) are
programmable and also triggers interrupt to an own slave PIC connected
to a cascading pin of the primary PIC.
The fundamental architecture of such microprocessor systems is that
there is a CPU and a number of programmable circuits more or less
connected by glue logic. Despite of the CPU address, data and control
buses, there is no clearly separatable bus concept that allows for a "a
board is a device" model. In other words: having the Altair emulator
won't help writing another Z80 emulator unless it also is an S100 one;
you might be
able to lift the sim_instr code, but essentially rewrite a completely
new Z80 simulator with its specific glue logic which may or may not be
devices
or units. It is not a solution to cut the system in a way that DMA or
IRQ logic is regarded as a part of the CPU or a part of a device that needs
such services, because this even further specializes the component set
rather than generalizing it. It is already a mess in the existing families,
like PDP or HP2100, to deal with variants of different instruction sets,
address busses, memory sizes and layouts, and model-specific quirks.
This does not really contribute to good maintainability by others than
the original code writer.
Provided, users and developers aren't just satisfied with basically
enjoying VMS in a box on a Windows PC, the interesting (research)
question to me is what extensions to simh are useful to assist a
developer in supporting the microcomputer era. Some weeks ago, GIANO was
mentioned as
derivation into such a direction, and maybe there is something to learn
there. What I want to avoid, though, is that simh will split into as
many variants as BSD or Linux distributions because the simh developer
base is by magnitudes smaller than the former ones. This might however
happen as
the set of now suitable computer systems with sufficient documentation
and software to try is unfortunately limited, and worse, the developer base
who still knows and understands valve-based SAGE computers, for
instance, tends to age.
--
Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6148 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20110511/dae781ed/attachment-0002.bin>
More information about the Simh
mailing list