To all with interest in preservation

On Tue, Aug 14, 2012 at 4:08 PM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote: (much snippage...) . . . Personally, I like the real hardware and enjoy constructing new hacks and keeping the original gear working both. I also write code, but far more system-level code than application code. To me, at the level I write at, I need a 100% faithful hardware emulation from my simulators. It's not good enough that a FORTRAN or BASIC program will run, pull in text right characters for output. I care if bits in I/O registers flip and clear in the right combination (though I care less if it takes 1us or 0.001us as long as it's perceived by my code to be in the right sequence with no atomic operations broken). In general, most emulators do a fine job of this or the OS would never load in the first place, but there are edge cases, which is why, for example, in VICE, you can select logical emulation of the model 1541 floppy drive or exact emulation. Logical emulation presents far less load on the host and if all you do is load and save files and send non-exotic commands to read and write data, it all works fine. If your program needs to manipulate data structures and buffers behind the scenes (CBM DOS allows the main CPU to read and write arbitrary bytes in the disk drive CPU's memory space using simple textual commands that are syntactically the same as the commands to load and save and review the directory, so it's not out of the question to emulate it all). I had one experience where I found what I thought was an obvious case of "this should work" that turned out to be a bug in the emulation of the hardware... On an early version of the SimH PDP-11 emulator (c. 1998), there were no known obvious problems under RT-11 or RSX-11 or even 2BSD with various types of DEC disk _except_ when I tried to create an environment with an RP03 and load 2.9BSD on it (since I already had real 2.9BSD tapes that I'd previously used to install the OS on real hardware - an 11/24 with RL02 and RK07), the install worked perfectly, but the OS hung on startup when it came time to probe the bus for what controllers were installed. It took three of us, Bob Supnik included, to figure out the issue was that when probe code writes to a read-only register on the RP-11 controller, the controller should generate an interrupt. That behavior is documented, but even in hindsight, it's not documented in such an obvious place that someone attempting to build an RP-11 work-alike would know or expect that something important should happen when you write to a read-only register. The code fix was trivial and after that, 2.9BSD came up and ran perfectly well. If I hadn't decided that I wanted about 60MB of space (vs 10MB per "disk" w/RL02 or 28MB per disk with RK07), I never would have known that there was an implementation bug with the RP11 code. Also, if I'd only ever stuck to DEC operating systems, I'd probably never have known then either. It's an edge case, since I doubt there were ever very many real PDP-11s with real RP-11s running 2.9BSD (for larger disk, an Emulex controller using the xp driver would have been far cheaper and far more common), but since with an emulator, I'm freer to configure a virtual machine in somewhat more interesting (but supposedly legal) combinations. So this is not a condemnation of emulation, but it is a cautionary tale that sometimes, it's not as easy as it appears to "get it right", and that's where having real working hardware can help. You say, "almost all emulators or simulators have as their primary focus... the accurate execution of any given hardware instruction", but do keep in mind that it goes beyond the instruction set when you start fiddling with emulated hardware. MOV might move a byte just fine as far as the ALU is concerned, but when it's not merely storing a byte in an array to be fetched later, when it needs to *do* something behind the scenes because in the real box, you've just triggered a cascade of flip-flops and gates, there's a whole lot of emulator code that has to work that might or might not have been sufficiently tested for "accurate execution". -ethan P.S. - yes, I've written plenty of MACRO-11 code under RT-11 that directly fiddles registers - I worked on this one project that had a hardware DMA engine and a framebuffer, so my application code did lots of writes to the I/O page, not just make I/O requests via the usual RT-11 mechanisms.