[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