[Simh] FW: pdp 11 timing

Mon Jul 20 23:09:18 EDT 2020

RSTS/E likes to send a MSCP command packet to request a disk block, and
after that it will then set the interrupt flag for when the read completes.
The original implementation of MSCP was instantaneous reads, so the read
completed before the interrupt was set. RSTS then sat around waiting for
the interrupt. which would never come. This is the reason that delays were
added to simh device emulations.

On Mon, Jul 20, 2020 at 7:37 PM Johnny Billquist <bqt at softjar.se> wrote:

> RT11 distribution comes with (uncommented) sources.
>
>    Johnny
>
> On 2020-07-21 00:31, Paul Moore wrote:
> > At the moment my ambitions are very lightweight. A pdp 11/20 with a
> cassette drive (why that? cos CAPS11 is the first sw listed on the simh sw
> kit page). And next is an RK11 with rk05. So I can run RT11 (the second
> thing on that page).
> >
> > The point that I am hearing is that, in general , the PDP11 sw doesn’t
> rely on timing , there are a few corner cases tho. Contrast this with other
> systems where precise knowledge of video flyback times are built into the
> core of the OS for example. Or timing is achieved by looping instruction x
> n times to produce an exact delay.
> >
> > BTW - does anybody have the source of the RT11 on the simh kit site? I
> got the source of CAPS11 from Lou Ernst and it was a life saver. I could
> not have progressed without it.
> >
> > -----Original Message-----
> > From: Simh <simh-bounces at trailing-edge.com> On Behalf Of
> simh at swabhawat.com
> > Sent: Monday, July 20, 2020 3:14 PM
> > To: Simh at trailing-edge.com
> > Subject: [Simh] FW: pdp 11 timing -->anf10 workstation on pdp11 with
> throttling
> >
> >
> >
> > L.S.
> >
> > Actually where this is important, is when using Pdp11 based ANF10
> workstations in the Tops10 realm.
> >
> > When starting up, the Anf10 software on the pdp11 sim test various
> devices for functionality thereby using instruction count based loops etc.
> > When all the devices necessary (paper tape reader/punch, incremental
> plotter interface, DZ and DH multiplexors, DMS and DUP/KDP devices and DL11
> interfaces) are properly verified, it cranks up the communication
> configuration with  scanning the network for active Pdp10 Tops10 host
> systems.
> > The throttling of the pdp11 should be carefully selected to let this
> function.
> >
> >
> > Reindert
> >
> >
> > -----Original Message-----
> > From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Johnny
> Billquist
> > Sent: Monday, 20 July, 2020 23:20
> > To: Paul Moore <paulmoore100 at hotmail.com>; simh at trailing-edge.com
> > Subject: Re: [Simh] pdp 11 timing
> >
> > Instruction timing as such is not relevant. Different implementations
> had very different timings, not to mention that speed of memory also makes
> a difference.
> >
> > Devices basically do not have a strict timing either, but yes, 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 real hardware that was just an absurd case that lots of code never
> considered, since it wasn't really physically possible for it to happen.
> >
> > The throttling in simh is because some people want the emulation to
> somewhat mimic the real thing. For some people, that experience of slowness
> is desirable.
> >
> >     Johnny
> >
> > On 2020-07-20 23:10, Paul Moore wrote:
> >> (I am writing my own emulator just because I have never done that
> >> before, and the PDP 11 is such a pivotal system in the history of
> >> modern computing it seemed worth learning about, and what better way
> >> to learn than to emulate it )
> >>
> >> So how important is timing of instruction execution and device response?
> >>
> >> The PDP 11 docs go  to great length giving instruction timing. But the
> >> fact that there is a % throttle in simh suggest that’s not important.
> >> I assume that turning that throttle up and down makes the emulated CPU
> >> go faster and slower. I have seen code using simple counters as delays
> >> but I assume that if you want precision you use the Kw11.
> >>
> >> With regards device responses I have found that going ’too fast’
> >> upsets code. If they do something that triggers an interrupt (set ‘go’
> >> for
> >> example) and the interrupt arrives too soon (like before the next
> >> instruction) they get surprised and can misbehave (you could argue
> >> that’s a bug, but that’s irrelevant). So always wait a few beats. But
> >> I assume there is no reason to try to precisely emulate the timing of
> >> , say, a disk drive. (The early handbooks state how awesome the async
> >> nature of the IO subsystem is cos you can swap out old for new and
> >> things just go faster).
> >>
> >>
> >> _______________________________________________
> >> Simh mailing list
> >> Simh at trailing-edge.com
> >> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailm
> >> an.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimh&data=02%7C01%7C%7
> >> C7737449fd7b940ede41e08d82cfa6bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7
> >> C1%7C0%7C637308801343677110&sdata=r%2BGE87iQAYJIJue9GPTrR7FESpVsQm
> >> hPhKxgm2CZCos%3D&reserved=0
> >>
> >
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20200720/6b11b1fa/attachment.html>