Re: [Simh] FW: pdp 11 timing -> RT11 source
You mean that it should be on the disk in the SIMH s/w kits?, I could not see any source. Its just one rk05 image. I also read you could get the full source if you asked. -Original Message- From: Johnny Billquist Sent: Monday, July 20, 2020 6:37 PM To: Paul Moore ; Simh@trailing-edge.com Subject: Re: [Simh] FW: pdp 11 timing 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 On Behalf Of > s...@swabhawat.com > Sent: Monday, July 20, 2020 3:14 PM > To: Simh@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-boun...@trailing-edge.com] On Behalf Of Johnny > Billquist > Sent: Monday, 20 July, 2020 23:20 > To: Paul Moore ; simh@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@trailing-edge.com >> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail >> m >> an.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimhdata=02%7C01%7C% >> 7 >> C7737449fd7b940ede41e08d82cfa6bf7%7C84df9e7fe9f640afb435% >> 7 >> C1%7C0%7C637308801343677110sdata=r%2BGE87iQAYJIJue9GPTrR7FESpVsQ >> m >> hPhKxgm2CZCos%3Dreserved=0 >> > -- Johnny Billquist || "I'm on a bus
Re: [Simh] FW: pdp 11 timing
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 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 On Behalf Of > s...@swabhawat.com > > Sent: Monday, July 20, 2020 3:14 PM > > To: Simh@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-boun...@trailing-edge.com] On Behalf Of Johnny > Billquist > > Sent: Monday, 20 July, 2020 23:20 > > To: Paul Moore ; simh@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@trailing-edge.com > >> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailm > >> an.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimhdata=02%7C01%7C%7 > >>
Re: [Simh] FW: pdp 11 timing
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 On Behalf Of s...@swabhawat.com Sent: Monday, July 20, 2020 3:14 PM To: Simh@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-boun...@trailing-edge.com] On Behalf Of Johnny Billquist Sent: Monday, 20 July, 2020 23:20 To: Paul Moore ; simh@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@trailing-edge.com https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailm an.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimhdata=02%7C01%7C%7 C7737449fd7b940ede41e08d82cfa6bf7%7C84df9e7fe9f640afb435%7 C1%7C0%7C637308801343677110sdata=r%2BGE87iQAYJIJue9GPTrR7FESpVsQm hPhKxgm2CZCos%3Dreserved=0 -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
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] FW: pdp 11 timing --> dectapes
Right. I was talking about RT-11, where this is clearly covered. RALL (and WALL) are not going to be particularly friendly to multi-tasking either. Here is the relevant code from FILEX.MAC (from RT V2). Amazing stuff. So yes, my memory was correct. Note subrouting TWAIT, which watches for the word count register changing, indicating another 16 bits have been transferred to memory and the matching upper bits are in TCDT. paul .SBTTL READ BLOCK FROM PDP-10 TAPE ; ROUTINE TO READ A BLOCK FROM A PDP-10 DECTAPE ; INTO AREA POINTED TO BY T.BUFF ; R0 = BLOCK NUMBER. R0 IS DESTROYED. T.RDTP: CLR -(SP) ;GO INTO SYSTEM STATE CALL1$ ;SO THAT TIMER TICKS ARE VERY FAST TST DTERR ;GOT DECTAPE ERRORS? BNE RTS0;NO ERR INER;YUP, HOW TERRIBLE 1$: MOVB#340,@#PS ;UP TO 7 JSR R5,@54 ;TO YE SYSTEM .WORD 340 ;AT PRIORITY 0 MOV SP,DTERR;SAVE CURRENT SP, SAY NO ERROR CALLSEARCH ;POSITION THE DECTAPE MOV R1,-(SP) MOV R2,-(SP) MOV (PC)+,R2;POINTER TO EXTRA BIT BUCKET T.BUFF: .WORD 0 MOV R2,-(SP);SAVE BUFFER PTR MOV #-256.,R1 ;SET UP WORD COUNT MOV #TCDT,R0;POINT FOR FILLER MOV R2,-(R0);STUFF BUS ADDRESS MOV R1,-(R0);STUFF WORD COUNT TST -(R0) ;POINT RIGHT FOR BYTE MOVB#340,@#PS ;WE MUST NOT BE INTERRUPTED!!! MOVB#5,@R0 ;SET YE COMMANDE GOING 1$: ADD #2,4(R0);POINT THE CONTROLLER TO GIVE ME ROOM CLR @R2 ;UNUSED BITS MUST BE 0 CALLTWAIT ;WAIT FOR READY WORD OR ERROR. ASL @R2 ;MAKE ROOM WITH LONG LEFT 2 ROL -(R2) ASL 2(R2) ROL (R2)+ CALLTWAIT ;WAIT FOR A WORD TST (R2)+ ;SKIP OVER THE GOOD WORD TST R1 ;ARE WE DONE (EVEN COUNT) ? BGE 3$ ;YES, CEASE THIS STUFF TST (PC)+ ;DO WE WANT ALL BITS? FULLIO=. .WORD 0 BNE 1$ ;YES, GO EAT CLRB@#PS;DOWN AGAIN 2$: BIT #100200,@R0 ;NO, JUST WAIT FOR COMPLETION BEQ 2$ BMI HARDER 3$: CLRB@#PS;DOWN TO 0 IF FULLIO ON MOV T.UNIT,R1 ;A CONVENIENT STOP SEL TRANS SWABR1 ;FIX IT UP MOV R1,@R0 ;STOP IT!! MOV (SP)+,R0;PASS HIM THE BUFFER ADDRESS RTS2: MOV (SP)+,R2 RTS1: MOV (SP)+,R1 RTS0: RETURN TWAIT: TST @R0 ;CHECK FOR ERROR BMI HARDER ;STOP IF SO CMP R1,2(R0);IS A WORD READY? BEQ TWAIT ;NO, KEEP LOOPING MOV @#TCST,-(SP);GET EXTRA BITS BIC #14,@SP ;REMOVE JUNK BIS (SP)+,(R2)+ ;ENBUFFER IT INC R1 ;BUMP WORD COUNT RETURN paul > On Jul 20, 2020, at 6:21 PM, wrote: > > On a single user machine possibly so, however on a 11/40 with about 14 user > working in timesharing mode I don't think it was doable without killing our > dear users. > Some of them had a quickly detonating mindset about them which was best to > avoid for system managers who thought to be king in their own realm ... > > > Reindert > > -Original Message- > From: Johnny Billquist [mailto:b...@softjar.se] > Sent: Tuesday, 21 July, 2020 00:16 > To: s...@swabhawat.com; simh@trailing-edge.com > Subject: Re: [Simh] FW: pdp 11 timing --> dectapes > > I think Paul's suggestion was if you actually keep a tight look at timing, > the extra two bits actually do appear in the other register as DMA is going > on, so you could just blindly read them out at the right times, and it might > work... > > Johnny > > On 2020-07-21 00:12, s...@swabhawat.com wrote: >> L.S. >> >> When in the past using dectapes, we read/wrote Pdp10/8 dectapes on Rsx11-D. >> On the Pdp11, you could do that only with READALL in interrupt mode to get >> the 2 extra bits, not in the standard dma mode. >> Other (timesharing) users weren’t that happy because the interrupt >> processing locked them out for a while, so to appease them it went a block >> at a time and then wait a while. >> >> Reindert >> >> -Original Message- >> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny >> Billquist >> Sent: Tuesday, 21 July, 2020 00:02 >> To: Paul Koning ; Paul Moore >> >> Cc: simh@trailing-edge.com >> Subject: Re: [Simh] pdp 11 timing >> >> On 2020-07-20 23:18, Paul Koning wrote: >>> >>> On Jul 20, 2020, at 5:10 PM, Paul Moore wrote: (I am writing my own emulator just because I
Re: [Simh] FW: pdp 11 timing -->anf10 workstation on pdp11 with throttling
> Well, then the first question that needs to be answered, which model > of PDP-11 was that code expected to run on ANF-10 primarily runs on the 11/40 (well, and the PDP-10s). Exceptions: DN200 remote station: 11/34, DN22: 11/04 . CHK11 compiles accordingly. On 20-Jul-20 18:19, Johnny Billquist wrote: > Well, then the first question that needs to be answered, which model > of PDP-11 was that code expected to run on, because the results will > differ depending on that. Also, what kind of memory? (I would guess > some old, small core memory boards.) > The PDP-11 execution speed really does vary based on many factors, on > real hardware... > > Johnny > > On 2020-07-21 00:13, s...@swabhawat.com wrote: >> >> >> 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-boun...@trailing-edge.com] On Behalf Of >> Johnny Billquist >> Sent: Monday, 20 July, 2020 23:20 >> To: Paul Moore ; simh@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@trailing-edge.com >>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>> >> > ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] FW: pdp 11 timing -->anf10 workstation on pdp11 with throttling --> machine selection
Well, the real ones were Pdp11/34 based without memory management, so 56 kB net could be used, but under simh every pdp11 runs at warp speed unless bridled somewhat. The memory could be core with parity checking but I am not sure they had already mos memory available in the 11/34. When the first static 4k mos 5V only chips came about - so no refresh necessary which was problematic in simple cpu architectures - we used them to replace the limited expensive 4k/8k pdp8e core memories for a single self made 32kW omnibus module, but that is aside ... It still was a time of the soldering iron though. Reindert -Original Message- From: Johnny Billquist [mailto:b...@softjar.se] Sent: Tuesday, 21 July, 2020 00:19 To: s...@swabhawat.com; Simh@trailing-edge.com Subject: Re: [Simh] FW: pdp 11 timing -->anf10 workstation on pdp11 with throttling Well, then the first question that needs to be answered, which model of PDP-11 was that code expected to run on, because the results will differ depending on that. Also, what kind of memory? (I would guess some old, small core memory boards.) The PDP-11 execution speed really does vary based on many factors, on real hardware... Johnny On 2020-07-21 00:13, s...@swabhawat.com wrote: > > > 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-boun...@trailing-edge.com] On Behalf Of Johnny > Billquist > Sent: Monday, 20 July, 2020 23:20 > To: Paul Moore ; simh@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@trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] FW: pdp 11 timing
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 On Behalf Of s...@swabhawat.com Sent: Monday, July 20, 2020 3:14 PM To: Simh@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-boun...@trailing-edge.com] On Behalf Of Johnny Billquist Sent: Monday, 20 July, 2020 23:20 To: Paul Moore ; simh@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@trailing-edge.com > https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailm > an.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimhdata=02%7C01%7C%7 > C7737449fd7b940ede41e08d82cfa6bf7%7C84df9e7fe9f640afb435%7 > C1%7C0%7C637308801343677110sdata=r%2BGE87iQAYJIJue9GPTrR7FESpVsQm > hPhKxgm2CZCos%3Dreserved=0 > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.trailing-edge.com%2Fmailman%2Flistinfo%2Fsimhdata=02%7C01%7C%7C7737449fd7b940ede41e08d82cfa6bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637308801343677110sdata=r%2BGE87iQAYJIJue9GPTrR7FESpVsQmhPhKxgm2CZCos%3Dreserved=0 ___ Simh mailing list
Re: [Simh] FW: pdp 11 timing --> dectapes
On a single user machine possibly so, however on a 11/40 with about 14 user
working in timesharing mode I don't think it was doable without killing our
dear users.
Some of them had a quickly detonating mindset about them which was best to
avoid for system managers who thought to be king in their own realm ...
Reindert
-Original Message-
From: Johnny Billquist [mailto:b...@softjar.se]
Sent: Tuesday, 21 July, 2020 00:16
To: s...@swabhawat.com; simh@trailing-edge.com
Subject: Re: [Simh] FW: pdp 11 timing --> dectapes
I think Paul's suggestion was if you actually keep a tight look at timing, the
extra two bits actually do appear in the other register as DMA is going on, so
you could just blindly read them out at the right times, and it might work...
Johnny
On 2020-07-21 00:12, s...@swabhawat.com wrote:
> L.S.
>
> When in the past using dectapes, we read/wrote Pdp10/8 dectapes on Rsx11-D.
> On the Pdp11, you could do that only with READALL in interrupt mode to get
> the 2 extra bits, not in the standard dma mode.
> Other (timesharing) users weren’t that happy because the interrupt processing
> locked them out for a while, so to appease them it went a block at a time and
> then wait a while.
>
> Reindert
>
> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny
> Billquist
> Sent: Tuesday, 21 July, 2020 00:02
> To: Paul Koning ; Paul Moore
>
> Cc: simh@trailing-edge.com
> Subject: Re: [Simh] pdp 11 timing
>
> On 2020-07-20 23:18, Paul Koning wrote:
>>
>>
>>> On Jul 20, 2020, at 5:10 PM, 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).
>>
>> For the most part that should work fine. The one exception I can think of
>> is DECtape. Driving one of those involves doing RNUM (read block number)
>> operations to look for the desired block, then switching to the read or
>> write data operation to do the actual I/O. If a block goes by too fast,
>> that won't work. Related: RT-11 has contiguous files, and DECtape I/O
>> should be able to see the consecutive blocks without overshooting, i.e.,
>> after block completion the next action is another RNUM (I believe) which
>> should see the next block.
>
> Obviously, if running in a simulation, it would be rather silly to simulate
> overrunning the block. The simulated tape can start and stop instantly, and
> always seek to the correct block. So it would be rather complex to actually
> implement the timing based behavior of the hardware in the first place.
>
>> I don't think any PDP-11 OS does timing based block position prediction
>> ("overlapped seek") on DECtape, the way TOPS-10 and (reported) VMS do. For
>> that to work the timing has to be rather more accurately emulated.
>
> Checked the RSX code, and no, it don't seem to support overlapped seeks on
> DECtape.
>
> The VMS driver was an unofficial hack. Did it really do such tricks?
>
>> Lastly, I don't know if anyone expects RT-11 FILEX reading of TOPS-10 tapes
>> to work in emulation. If I remember right, that does a rather strange
>> thing: DMA the block to get the bottom 16 bits of each word, while watching
>> the extended data register to get the upper 2 bits as the words fly by. It
>> doesn't use RALL which would have been a cleaner solution. I think Anton
>> said he didn't think of that, which seems hard to believe.
>
> That would be quite the trick.
>
> FLX under RSX does not support any non-PDP11 tape formats.
>
> Looking at some TC11 documentation - if you want to read 18-bit data, it
> looks like you really should use RALL. Using RDATA might be possible, but it
> would seem to be to be extremely difficult to do well. I am
Re: [Simh] FW: pdp 11 timing -->anf10 workstation on pdp11 with throttling
Well, then the first question that needs to be answered, which model of PDP-11 was that code expected to run on, because the results will differ depending on that. Also, what kind of memory? (I would guess some old, small core memory boards.) The PDP-11 execution speed really does vary based on many factors, on real hardware... Johnny On 2020-07-21 00:13, s...@swabhawat.com wrote: 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-boun...@trailing-edge.com] On Behalf Of Johnny Billquist Sent: Monday, 20 July, 2020 23:20 To: Paul Moore ; simh@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@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] FW: pdp 11 timing --> dectapes
I think Paul's suggestion was if you actually keep a tight look at
timing, the extra two bits actually do appear in the other register as
DMA is going on, so you could just blindly read them out at the right
times, and it might work...
Johnny
On 2020-07-21 00:12, s...@swabhawat.com wrote:
L.S.
When in the past using dectapes, we read/wrote Pdp10/8 dectapes on Rsx11-D.
On the Pdp11, you could do that only with READALL in interrupt mode to get the
2 extra bits, not in the standard dma mode.
Other (timesharing) users weren’t that happy because the interrupt processing
locked them out for a while, so to appease them it went a block at a time and
then wait a while.
Reindert
-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny Billquist
Sent: Tuesday, 21 July, 2020 00:02
To: Paul Koning ; Paul Moore
Cc: simh@trailing-edge.com
Subject: Re: [Simh] pdp 11 timing
On 2020-07-20 23:18, Paul Koning wrote:
On Jul 20, 2020, at 5:10 PM, 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).
For the most part that should work fine. The one exception I can think of is
DECtape. Driving one of those involves doing RNUM (read block number)
operations to look for the desired block, then switching to the read or write
data operation to do the actual I/O. If a block goes by too fast, that won't
work. Related: RT-11 has contiguous files, and DECtape I/O should be able to
see the consecutive blocks without overshooting, i.e., after block completion
the next action is another RNUM (I believe) which should see the next block.
Obviously, if running in a simulation, it would be rather silly to simulate
overrunning the block. The simulated tape can start and stop instantly, and
always seek to the correct block. So it would be rather complex to actually
implement the timing based behavior of the hardware in the first place.
I don't think any PDP-11 OS does timing based block position prediction ("overlapped
seek") on DECtape, the way TOPS-10 and (reported) VMS do. For that to work the
timing has to be rather more accurately emulated.
Checked the RSX code, and no, it don't seem to support overlapped seeks on
DECtape.
The VMS driver was an unofficial hack. Did it really do such tricks?
Lastly, I don't know if anyone expects RT-11 FILEX reading of TOPS-10 tapes to
work in emulation. If I remember right, that does a rather strange thing: DMA
the block to get the bottom 16 bits of each word, while watching the extended
data register to get the upper 2 bits as the words fly by. It doesn't use RALL
which would have been a cleaner solution. I think Anton said he didn't think
of that, which seems hard to believe.
That would be quite the trick.
FLX under RSX does not support any non-PDP11 tape formats.
Looking at some TC11 documentation - if you want to read 18-bit data, it looks
like you really should use RALL. Using RDATA might be possible, but it would
seem to be to be extremely difficult to do well. I am truly impressed if they
did it that way.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
[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-boun...@trailing-edge.com] On Behalf Of Johnny Billquist Sent: Monday, 20 July, 2020 23:20 To: Paul Moore ; simh@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@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] FW: pdp 11 timing --> dectapes
L.S.
When in the past using dectapes, we read/wrote Pdp10/8 dectapes on Rsx11-D.
On the Pdp11, you could do that only with READALL in interrupt mode to get the
2 extra bits, not in the standard dma mode.
Other (timesharing) users weren’t that happy because the interrupt processing
locked them out for a while, so to appease them it went a block at a time and
then wait a while.
Reindert
-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny Billquist
Sent: Tuesday, 21 July, 2020 00:02
To: Paul Koning ; Paul Moore
Cc: simh@trailing-edge.com
Subject: Re: [Simh] pdp 11 timing
On 2020-07-20 23:18, Paul Koning wrote:
>
>
>> On Jul 20, 2020, at 5:10 PM, 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).
>
> For the most part that should work fine. The one exception I can think of is
> DECtape. Driving one of those involves doing RNUM (read block number)
> operations to look for the desired block, then switching to the read or write
> data operation to do the actual I/O. If a block goes by too fast, that won't
> work. Related: RT-11 has contiguous files, and DECtape I/O should be able to
> see the consecutive blocks without overshooting, i.e., after block completion
> the next action is another RNUM (I believe) which should see the next block.
Obviously, if running in a simulation, it would be rather silly to simulate
overrunning the block. The simulated tape can start and stop instantly, and
always seek to the correct block. So it would be rather complex to actually
implement the timing based behavior of the hardware in the first place.
> I don't think any PDP-11 OS does timing based block position prediction
> ("overlapped seek") on DECtape, the way TOPS-10 and (reported) VMS do. For
> that to work the timing has to be rather more accurately emulated.
Checked the RSX code, and no, it don't seem to support overlapped seeks on
DECtape.
The VMS driver was an unofficial hack. Did it really do such tricks?
> Lastly, I don't know if anyone expects RT-11 FILEX reading of TOPS-10 tapes
> to work in emulation. If I remember right, that does a rather strange thing:
> DMA the block to get the bottom 16 bits of each word, while watching the
> extended data register to get the upper 2 bits as the words fly by. It
> doesn't use RALL which would have been a cleaner solution. I think Anton
> said he didn't think of that, which seems hard to believe.
That would be quite the trick.
FLX under RSX does not support any non-PDP11 tape formats.
Looking at some TC11 documentation - if you want to read 18-bit data, it looks
like you really should use RALL. Using RDATA might be possible, but it would
seem to be to be extremely difficult to do well. I am truly impressed if they
did it that way.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] pdp 11 timing
On 2020-07-20 23:18, Paul Koning wrote:
On Jul 20, 2020, at 5:10 PM, 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).
For the most part that should work fine. The one exception I can think of is
DECtape. Driving one of those involves doing RNUM (read block number)
operations to look for the desired block, then switching to the read or write
data operation to do the actual I/O. If a block goes by too fast, that won't
work. Related: RT-11 has contiguous files, and DECtape I/O should be able to
see the consecutive blocks without overshooting, i.e., after block completion
the next action is another RNUM (I believe) which should see the next block.
Obviously, if running in a simulation, it would be rather silly to
simulate overrunning the block. The simulated tape can start and stop
instantly, and always seek to the correct block. So it would be rather
complex to actually implement the timing based behavior of the hardware
in the first place.
I don't think any PDP-11 OS does timing based block position prediction ("overlapped
seek") on DECtape, the way TOPS-10 and (reported) VMS do. For that to work the
timing has to be rather more accurately emulated.
Checked the RSX code, and no, it don't seem to support overlapped seeks
on DECtape.
The VMS driver was an unofficial hack. Did it really do such tricks?
Lastly, I don't know if anyone expects RT-11 FILEX reading of TOPS-10 tapes to
work in emulation. If I remember right, that does a rather strange thing: DMA
the block to get the bottom 16 bits of each word, while watching the extended
data register to get the upper 2 bits as the words fly by. It doesn't use RALL
which would have been a cleaner solution. I think Anton said he didn't think
of that, which seems hard to believe.
That would be quite the trick.
FLX under RSX does not support any non-PDP11 tape formats.
Looking at some TC11 documentation - if you want to read 18-bit data, it
looks like you really should use RALL. Using RDATA might be possible,
but it would seem to be to be extremely difficult to do well. I am truly
impressed if they did it that way.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
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@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] pdp 11 timing
> On Jul 20, 2020, at 5:10 PM, 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).
For the most part that should work fine. The one exception I can think of is
DECtape. Driving one of those involves doing RNUM (read block number)
operations to look for the desired block, then switching to the read or write
data operation to do the actual I/O. If a block goes by too fast, that won't
work. Related: RT-11 has contiguous files, and DECtape I/O should be able to
see the consecutive blocks without overshooting, i.e., after block completion
the next action is another RNUM (I believe) which should see the next block.
I don't think any PDP-11 OS does timing based block position prediction
("overlapped seek") on DECtape, the way TOPS-10 and (reported) VMS do. For
that to work the timing has to be rather more accurately emulated.
Lastly, I don't know if anyone expects RT-11 FILEX reading of TOPS-10 tapes to
work in emulation. If I remember right, that does a rather strange thing: DMA
the block to get the bottom 16 bits of each word, while watching the extended
data register to get the upper 2 bits as the words fly by. It doesn't use RALL
which would have been a cleaner solution. I think Anton said he didn't think
of that, which seems hard to believe.
paul
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] pdp 11 timing
(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@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
