Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Paul Koning]

> On Feb 21, 2018, at 11:19 AM, Ray Arachelian via cctalk <cctalk at classiccmp.org> wrote:
> 
> On 02/19/18 19:36, Adrian Stoness via cctalk wrote:
>> whats invovled in makin an emulator?
>> i have a chunk of stuff for the phillips p1000
> 
> Quite a lot actually.  A single CPU system is difficult enough, but a
> mainframe might be much, much harder.  The idea to use an existing
> emulator framework, such as SIMH, is a great one.
> 
> An easy implementation is to implement an interpretive CPU emulation at
> first, and then later on add other things such as JITs or caching.
> Does this machine implement microcode?  Do you want to emulate it all
> the way down to the microcode level?  Is microcode changeable by the
> OS/applications?  If not maybe implement the higher level (assuming
> CISC) CPU layer.

If microcode is not user-changeable, or if that capability is not a core feature, then you can easily omit it.  That tends to make the job much easier.  For example, I don't know that anyone emulates the PDP-11/60 WCS.  The absence of that emulation isn't a big deal, unless you want to run the Richy Lary PDP-8 emulator on that emulated 11/60.  (Has it been preserved?)

Caching doesn't change user-visible functionality, so I can't imagine wanting to emulate that.  The same goes for certain error handling.  I've seen an emulator that included support for bad parity and the instructions that control wrong-parity writing.  So you could run the diagnostic that handles memory parity errors.  But that's a pretty uncommon thing to do and I wouldn't bother.

> There's a lot to consider.  The CPU(s), any co-processors, I/O
> devices/busses, peripherals/terminals, etc.  Are you going to emulate
> every co-processor in software, or is the system documented enough so
> you can emulate just the protocols that the main CPU(s) use to talk to
> those devices?  For example, many systems have some sort of storage
> processors.  You could emulate everything 100% in software, but for that
> you'd need disk and firmware dumps of everything.  Or, if the firmware
> on those is fairly fixed, just emulate the functionality.

Typically you'd emulate the I/O device functionality, regardless of whether that is implemented in gates or in co-processor firmware.  That's the approach taken with the MSCP I/O device emulation in SIMH, or the disk controller emulation in the CDC 6000 emulator DtCyber.  All those use coprocessors, but the internals of those engines are much more obscure and much less documented than the APIs of the I/O devices, and finding executable code may also be very hard (never mind source code and assemblers).  For example, I have only seen UDA50 firmware once, on a listing on a desk in CXO back around 1981.

> .
> You'll need to fully understand all aspects of the hardware of that
> machine, every detail.  If you have schematics and can read them, they
> can be an absolute gold mine as documentation sometimes is vague, and
> looking at the schematics and resolve what actually happens.  If you
> have source code for an OS, that too can be a great resource to help
> understand what happens and how.

Exact emulation is ideal, but often not necessary.  What's required is emulation that delivers what the OS and drivers rely on.  Devices may have undocumented features, and bugs, that aren't touched by the software that you care about.  Just the documented features (from the programmer manuals) can often be sufficient, especially in well documented machines (DEC machines are examples of such, most of the time).  Sometimes you get surprised by some OS.  RSTS/E occasionally pokes at strange internals, perhaps to complain about a missing ECO that needs to be installed for the OS to be happy.

> ...
> You'll have to implement more than 90% of a working emulator before
> you'll even be able to see progress and know you're on the right track,

Handwritten short test sequences are very helpful for this.  While you'll need 90% or so for an OS to boot, you might need only 5% to test a few instructions entered via deposit commands.

	paul