[Simh] FW: pdp 11 timing --> dectapes

[Johnny Billquist]

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