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 <paulkon...@comcast.net>; Paul Moore <paulmoore...@hotmail.com>
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 <paulmoore...@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: 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
