21 Feb
2018
21 Feb
'18
11:24 a.m.
On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
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.
I disagree, especially if you?re using an emulator for development. Caching is one of
those things that can go
horribly wrong and not having them emulated properly (or at all) can lead to
bugs/behaviors that are significantly
different from real HW. The same goes for error reporting/handling. There are cases
where errors may be expected
and not having them can cause the SW to behave differently.
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.