Re: [Simh] FW: pdp 11 timing
> ... there is plenty of software that assumes that an interrupt does not > happen before a single instruction have been executed after the previous > interrupt, from the same device, for example. On the ibm1130 (a different machine of course) we found a case where a driver expected to execute quite a few instructions ... many hundreds ... before an interrupt could occur in real hardware, while zeroing or copying a buffer for instance. So it might be good to do what simh does and make the delay between initiating an IO operation and signaling its completion an adjustable parameter. Start with a realistically large number and see if reducing it causes failures. I would guess you would have fewer dependencies like this in drivers for hardware whose latency was random (eg disk seek and rotation) and a bigger risk that authors might have assumed and exploited the delay time on operations that had a fixed cycle time (block to block or sector to sector times, or punched card operations) ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] suspicious code in pdp11_rl.c
When I saw the suspicious code subject, I was half hoping that the code in question would have been something like scan local hard disk, send all files to dark server in Khazakstan. Oh well. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SIMH internals documentation?
The 1130 GUI works for me. I build it under VS 2008. Dave, do you want the .sln file? The GUI code, by the way, is Windows-only. I made only vague attempts to abstract it so that it could be reimplemented in other environments. Brian On 9 May 2011 at 7:34, Dave Wade wrote: I last built it under vs2005 and it worked fine, not tried recently. If I get time I'll have a look tonight. (note I am in the UK) Dave G4UGM On 8 May 2011 23:12, Richard legal...@xmission.com wrote: In article C099F659EBBF4EFE99657CB5D581DD46@EMACHINE, Dave dave.g4...@gmail.com writes: The 1130 simulator has a GUI on Windows. Its in the pac... When I add GUI_SUPPORT to the vcproj that I made for VS2008, all I get is a console window and a tiny window with japanese text in the title bar. When I try to use that nmake makefile, it doesn't build. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadul... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _| _| _| Brian Knittel _| _| _| Quarterbyte Systems, Inc. _| _| _| Tel: 1-510-559-7930 _| _| _| http://www.quarterbyte.com ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] 1130 GUI, was SIMH internals documentation?
Two things to be certain of: * Be sure that ibm1130_gui.c is in the build and, * Be sure that Unicode is turned off. The Japanese text makes me suspect it wasn't in your build. In Visual Studio 2008, for example, in the project's properties page, under Configuration Properties, General, be sure that Character Set is set to Not Set for both Debug and Release builds. Brian On 9 May 2011 at 7:34, Dave Wade wrote: I last built it under vs2005 and it worked fine, not tried recently. If I get time I'll have a look tonight. (note I am in the UK) Dave G4UGM On 8 May 2011 23:12, Richard legal...@xmission.com wrote: In article C099F659EBBF4EFE99657CB5D581DD46@EMACHINE, Dave dave.g4...@gmail.com writes: The 1130 simulator has a GUI on Windows. Its in the pac... When I add GUI_SUPPORT to the vcproj that I made for VS2008, all I get is a console window and a tiny window with japanese text in the title bar. When I try to use that nmake makefile, it doesn't build. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadul... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _| _| _| Brian Knittel _| _| _| Quarterbyte Systems, Inc. _| _| _| Tel: 1-510-559-7930 _| _| _| http://www.quarterbyte.com ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
I am running this on a recently purchased quad-core system that is rather fast. I have simh set up on a system that is much slower, so I will give that a try to see if there is a difference. Hi Peter, The speed of the *host* (Intel) processor should not be a factor. The timing in question is within the simulated machine -- the virtual time between when a hardware device is given a command and when the corresponding data is transferred or when the device interrupt occurs. In SIMH the delay is typically specified as a number of simulated instructions. That is, a delay of 10 means an interrupt will occur after the simulated VAX CPU has executed 10 instructions. The default delay settings for each device are determined on an ad-hoc basis, and as I found while writing the IBM 1130 simulator, this can be a dicey thing. Here's a hypothetical explanation of the problem: The VMS 4 driver initiates an operation, does a little housekeeping, then enters an idle loop waiting for the corresponding operation-complete interrupt. On real hardware, there was always enough time for the housekeeping work. But, in SIMH the interrupt occurs before the VMS driver enters the wait loop, and so the wait never ends because no further interrupts occur. This is the too fast issue they're talking about. If this is the problem, then increasing the disk device's delay settings may well solve it. It looks like the RP device read and write delay is: RTIME + STIME * (# of cylinders being stepped) where RTIME and STIME are both 10 by default. If the read head is already on the desired cylinder, a read operation completes when just 10 VAX instructions have elapsed since it was initiated. On real hardware, a read took, at the very least, enough time for the desired number of words to rotate past the read head. 10 instructions isn't very much time at all. I'd suggest setting RTIME to 1000 just to see if the boot succeeds: deposit RP RTIME 1000 then boot. If it works, try repeatedly halving it. Find the minimum value needed for a successful boot. But the problem could be also due to a subtle difference in the way that interrupts are generated on the real hardware vs. the simulated hardware (for example, an interrupt that should be occurring isn't or vice versa), or in the way that the control registers work (as a hypothetical example, after a seek the driver examines the current- cylinder register and expects to see it changing over time, whereas in SIMH the register changes instantly). The VMS 4 driver might be dependent on the exact behavior, while the other versions' drivers aren't. If this is the problem, it may require a change in the source code for the simulated device. Far trickier to do. The change would have to make VMS 4 work but not break the other VMS versions or the PDP-11 operating systems, which share the same RP device simulator code. Brian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _| _| _| Brian Knittel _| _| _| Quarterbyte Systems, Inc. _| _| _| Tel: 1-510-559-7930 _| _| _| http://www.quarterbyte.com ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] An idea for graphics support in SIMH
On 7 Jul 2010 at 19:53, Michael Kerpan wrote: ... As to why the graphics would be done through RFB rather than through direct display, that's just to keep things cross-platform by off-loading the platform-specific work of displaying graphics to external programs rather than having code display routines for every platform SIMH runs on into the codebase. Exactly. The big win here is making TCP/IP the part that has to be abstracted for all SIMH host platforms, rather than the graphics display. It will still be challenging. Second, a (small) bonus is that it lets you run the VNC display client on any any computer, on any operating system. You can run SIMH on a machine that doesn't have its own graphics display, if necessary, and run the VNC client on another machine. I can see that being useful in some cases. (And wansn't this talked about about 6 years ago? Didn't go anywhere?) Also, re the conversation about some SIMH guests already having X support, that's fine, for a small corner of the SIMH universe where X implementations were available. There is more to SIMH than the MicroVAX. I'm talking about emulating OLD graphics hardware here, with (usually) very peculiar, OS-integrated driver support, from long before X existed. And the Tektronics stuff is, well, it's cute, but it's just application software spitting control codes out a simulated serial port, right? The good stuff all takes place in the add-on terminal. The fun part here is resurrecting the native display devices themselves. Unless someone is talking about making a SIMH 4014? Brian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _| _| _| Brian Knittel _| _| _| Quarterbyte Systems, Inc. _| _| _| Tel: 1-510-559-7930 _| _| _| http://www.quarterbyte.com ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
