> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk <cctalk@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. It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the mainframe I/O is complex to say the least. However, it is my belief (and I think others have also stated) that assuming infinitely fast I/O (e.g. no delays what so ever) can cause issues because in many cases the SW expects to be able to do some work between the time that the I/O is started and when it completes. TTFN - Guy
