[Simh] FW: pdp 11 timing --> dectapes
Paul Koning
paulkoning at comcast.net
Mon Jul 20 20:02:36 EDT 2020
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
CALL 1$ ;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, at 54 ;TO YE SYSTEM
.WORD 340 ;AT PRIORITY 0
MOV SP,DTERR ;SAVE CURRENT SP, SAY NO ERROR
CALL SEARCH ;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, at R0 ;SET YE COMMANDE GOING
1$: ADD #2,4(R0) ;POINT THE CONTROLLER TO GIVE ME ROOM
CLR @R2 ;UNUSED BITS MUST BE 0
CALL TWAIT ;WAIT FOR READY WORD OR ERROR.
ASL @R2 ;MAKE ROOM WITH LONG LEFT 2
ROL -(R2)
ASL 2(R2)
ROL (R2)+
CALL TWAIT ;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, at 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
SWAB R1 ;FIX IT UP
MOV R1, at 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 #177774, at SP ;REMOVE JUNK
BIS (SP)+,(R2)+ ;ENBUFFER IT
INC R1 ;BUMP WORD COUNT
RETURN
paul
> On Jul 20, 2020, at 6:21 PM, <simh at swabhawat.com> <simh at swabhawat.com> 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:bqt at softjar.se]
> Sent: Tuesday, 21 July, 2020 00:16
> To: simh at swabhawat.com; simh at 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, simh at 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-bounces at trailing-edge.com] On Behalf Of Johnny
>> Billquist
>> Sent: Tuesday, 21 July, 2020 00:02
>> To: Paul Koning <paulkoning at comcast.net>; Paul Moore
>> <paulmoore100 at hotmail.com>
>> Cc: simh at 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 <paulmoore100 at hotmail.com> 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: 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
More information about the Simh
mailing list