Hello Mark, On 10 April 2013 13:37, Mark Pizzolato - Info Comm <[email protected]> wrote: > Anything is possible. Someone could extend a particular simulator instance > to implement a something (a GUI perhaps) which provided a way for a user to > express the desire to perform one of these actions and to gather the needed > details relating to the desired action. > > Hooks exist in the codebase to allow a particular simulator to provide what > can be reasonably described as arbitrary extensions the basic simh framework. > These extensions can include both simulator specific commands and/or > arbitrarily anything else. > That is understandable, though my question would have been better phrased as "would the rewrite of the code to separate the simulator command processor from the simulator CPU into different threads be something that requires a massive rewrite of the codebase?"
> Once again, anything is possible, but this would be a significant amount of > work. If there was some formal documentation available which described the > RS03 and RS04 disks, then adding them to the pdp11_rq.c code would probably > not be too hard. Looking in the 'usual places' on bitsavers.org doesn't > provide any information on these disk devices though. > Well it would be to the pdp11_rp.c code, but either way, they're just another form of MASSBUS disk, and in my quick browse through the pdp11_rp.c code, it looks likes like the various drives under its purview are only defined as their geometries. So to add the RS03 and RS04, all that would be needed to be added -- in my quick glance at the code, would only require entering the proper geometry for the devices. > Meanwhile, there already exists support for many disks within the current > simh codebase. There is existing support for 4 RQDX controllers each of > which can support 4 drives. The RL controller can support up to 4 drives. > The RP can support up to 8 drives. The HK (RK611) can support up to 8 drives. > Speaking of the RK611, I noticed a problem, whereby an RK07 errors out in RSTS/E (10.1-L) with "device not ready" or something similar, while it works just fine with an RK06... weird. There is only one set of drives that isn't implemented in SIMH at present, is the pre-MASSBUS RP drives (on the actual RP11 controller, so RP01, RP02 and RP03). But I don't think much if any still extant software even supports the RP0[1:3]. > Simulated systems can easily be configured which could have never exist in > the real hardware space due to issues like 1) cost, 2) concurrency of > technology, 3) power/bus loading constraints, etc. Yes, you can't currently > configure a system which could have arbitrarily been designed with real > hardware, but you can also configure many system configurations which exceed > many of the assumptions which existed when working with real hardware. > Of course it is possible to "misconfigure" a system, But I know in my own case, I try to keep any system configurations limited to what was actually possible (with the occasional waiver, e.g. having the RP drive series plus its associated RH controller on a QBUS system with the justification of "somewhere there is a third party board that let's you put a CDC 9766 on a QBUS box". Plus the simulated system has allowed the debugging of software with proper configuration issues. (The example of choice being the "XVM/DOS doesn't play nice with an RF15 with 8 platters, only a maximum of 7.") > Once again, anything is possible. There are no magic bullets here. Someone > with sufficient motivation, skill and detailed information would have to make > the effort to do these types of things. > Once you again you are very correct, but I am not the person to implement anything; while I am enthused about getting some of which I mentioned working, I couldn't program it worth anything. Cheers, Christian _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
