On 2/21/2018 5:14 PM, Paul Koning via cctalk wrote: TSS/8. It was a wonderful thing to witness. Start the drive spinning, deselect it, go start up another, then reselect the first one as it approached the right part of the tape. ??? -Rick

That's true. But it is unfortunately also true that creating a bug for bug accurate model of an existing machine is extremely hard. Building an OS-compatible version is not nearly as hard, but still hard enough. Passing diagnostics is yet another hurdle; in some cases that isn't feasible without an entirely different design. For example, in the CDC 6600 there is the "exchange jump" test, which at some point depends on the execution time of a divide instruction and the timing of exchange instructions. It is very hard for an emulator to mimic that (and an utter waste of effort for every other bit of software available for that machine). Another example is the work pdp2011 had to do in order to make RSTS boot on that FPGA based PDP-11 emulation, because RSTS was doing some CPU-specific hackery to test for an obscure CPU (or FPU?) bug that had been corrected in some ECO that it wanted to require. The only way to figure out how to do that is to reverse engineer that particular bit of code, which isn't normally available in source form. paul

On Mon, 26 Feb 2018, Paul Koning via cctalk wrote: There is always a decision to be made, whether to mimic the behavior, or mimic how it is supposed to behave. If you are aware of a bug in the original, do you emulate that bug? There was once a New Yorker cartoon, where a mechanic told a customer, "For $300 we can get it to run like new. For $600 we can get it to run like it should." Emulation of the bugs can not simply be ignored. Surely, you could get away with not emulating the truncated mantissa FDIV bug? Not necessarily. Sometimes timing can be important. Using a do-nothing loop for a time delay was never a good idea (and optimizers would remove it), but it did happen, ranging from crude amateur programs, to crude copy protection. I remember when it was sometimes necessary for MS-DOS code to determine what processor it was running on. Since not all processors provided an "Identify yourself" command, it was done through checking for bugs, obscure differences, etc. Such as checking the size of the pre-fetch buffer, or whether a double prefix was maintained after an interrupt (REP ES:MOVSW). There was no offical method for identification. I remember an article in Microcornucopia that mentioned an Intel sanctioned set of methods; the author couldn't remember where he got it; I called Intel, and after many transfers reached somebody who understood the question; he had no idea, but asked me to forward him a copy if I did ever find it. So, it becomes necessary to have massive configuration settings, to be able to emulate as spec'ed, or as which set of the variant bugs. It's hard enough just getting it to work! When the first software based PC emulator for the Amiga came out, it worked [well enough to run XenoCopy on some formats]. But, people griped because it wasn't faster than their current PC. Geez! They got an elephant to fly, and people gripe about the speed and payload capacity! -- Grumpy Ol' Fred cisin at xenosoft.com