Should be TSB and IPL Bob, TSB assumes that it is the OS, so it is assuming that it ?owns? all of its peripherals, DMA and the Interrupt system as well. As long as these false assumptions are accounted for under IPL I would think that a single CPU TSB such as TSB E may run without many problems. The real problem comes with dual processor configurations of TSB. Ether processor can initiate communication to the other, although the Main is generally the one ?Calling the shots?. Ether way, they assume that their partner is listening attentively, and they don?t have much tolerance for a sluggish response. If ether one gives up on the other the result is DEATH. Under SIMH we had problems getting the timing right between the two virtual processors, but it does work, and on some platforms it still needs tweaking. On real hardware if you stop all user activity, you can get away with halting the Main processor, exploring memory from the front panel and pressing Run without causing a crash. But if any terminal were to strike a key while the Main was halted the IOP would give up on the main and die, when the main came back the IOP would be dead, so the Main would die too. If you try to halt the IOP with the system running the result is always death. I think that it may be the result of a lost clock interrupt, because we see the same thing under SIMH. TSB is rather particular about addresses of it IO devices, so running both processors on the same CPU may take a bit of creativity when allocating devices. The IOP of Access would give you the most flexibility, but it?s still rather strict. On the 2100 version of Access the IOP microcode went into the same sockets as the Main Processor?s floating point microcode so they were mutually exclusive and both required, but on the 21MX versions I think that was changed. So it may be possible to have both floating point instructions and IOP instructions in the same CPU. Although I seem to recall that the IOP instructions needed a stack pointer, and since they were not using some register of the memory subsystem they just used that register for the stack. I want to say that it was a ?memory fence register?, but I?m not sure. And the IMS that describes it refers only to the 2100a/s microcode, so I really don?t know what they did in the MX microcode. It?s possible that the IOP microcode for MX may interfere with something that IPL is counting on and Jay, Al, or Bob may be the best people to speak to that. Of course, this would only apply to real hardware, under SIMH the instructions are simulated without the constraints of the real hardware. It would be really cool if the interconnect kit (the channel between the two processors) could be virtual through IPL and perhaps even cause the change of context to running the other processor. The device drivers in the IOP are well organized, but the Main Processor is not. Sometimes it looks more like spaghetti code, with IO instructions all over the place in seemingly unrelated routines. (I?m sure they did that because they had both memory and CPU time constraints, ;-) None the less, my hat?s off to them. The last version of HP2000 Access had only one bug found in it that I am aware of. With that bug patched, I don?t think any other bug has ever been found. I don?t think I shall ever again see such perfection. On the special boot strap loader issue for Access, I don?t see it being a problem. We don?t use it or even load it under SIMH. We just let SIMH load the second half of the bootstrap paper tape image in low memory of the Main processor and start it. We also let SIMH load the whole image of a preconfigured IOP and start that. Sure someone could change the SIMH startup scripts to be absolutely true to the recommended boot procedures, but then again, a lot of these short cuts were well known back in the day of real production systems and we are trying to boot the system with minimal operator intervention. TSB E sounds like the place to start. Then I would try Access on two CPUs then each running under IPL. And finally Access with both running on the same CPU. If you decide to run tests with IPL and TSB under SIMH I would also caution that the simulated interconnect between the two processors has only (as far a I know) been working under Windoz. I think it has something to do with the ?Socket Connect? library code, which last I checked was only used by this device. Some day some other device may use it, and someone may take the time to fix it. But for now we are just so happy to be able to run dual CPU TSB that we put up with running it on Windoz. The quickest way to boot up a TSB E system is under SIMH. The URL for the ZIP is in the links section of the HP2000 Yahoo Group. The binaries are images of original HP paper tapes (Thanks, Al and Jeff), so they should be quite useable on real hardware if ported to a suitable media. Hope this helps, Mike Gemeny