21 Feb
2018
21 Feb
'18
10:59 a.m.
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:
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.
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. 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