-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of John Wilson
Sent: Sunday, January 06, 2013 14:29
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DU11 vs. DUV11
From: "Lee Gleason" <lee.gleason at comcast.net>
I'm even more curious what a PDT-11 optimization is doing in an RSX
driver...was there at one time an RSX product product
planned for the
PDT family?
I've never met a PDT-11/110 in person. The docs say they
were downline-load-only -- so what DID they run? MRRT11?
RSX11S would certainly make sense. Also, DEC dumped a lot of
the PDTs to their own employees, so maybe someone made a few
tweaks to the RSX code for their own evil purposes at home.
John Wilson
D Bit
The main target for the PDT-11 was RT-11. It was slow. The floppies
spent a great deal of time seeking. They were the size of a small
microwave oven. In software services we would use it to test patches to
RT-11 and some of the layered products. I had one for a time that I
used at home over a 300 baud connection. Tough to say whether the
dial-up or the floppies were slower... :-)
-Steve
From: "Lee Gleason" <lee.gleason at comcast.net>
I'm even more curious what a PDT-11 optimization is doing in an RSX
driver...was there at one time an RSX product product planned for the PDT
family?
I've never met a PDT-11/110 in person. The docs say they were
downline-load-only -- so what DID they run? MRRT11? RSX11S would
certainly make sense. Also, DEC dumped a lot of the PDTs to their
own employees, so maybe someone made a few tweaks to the RSX code
for their own evil purposes at home.
John Wilson
D Bit
On Sun, Jan 6, 2013 at 1:20 PM, Bill Pechter <pechter at gmail.com> wrote:
perhaps rsx11s was planned for the pdt11 series.
On Jan 6, 2013 12:14 PM, "Lee Gleason" <lee.gleason at comcast.net> wrote:
.IF DF L$$SI1
MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE
MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11)
.IFF ; DF L$$SI1
MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER
.ENDC ; DF L$$SI1
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
--
I'm even more curious what a PDT-11 optimization is doing in an RSX
driver...was there at one time an RSX product product planned for the PDT
family?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
Hello!
I'm even more curious just what finally happened to that family
member. (And this week I'm not interested in finding one or two.)
--
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
perhaps rsx11s was planned for the pdt11 series.
On Jan 6, 2013 12:14 PM, "Lee Gleason" <lee.gleason at comcast.net> wrote:
.IF DF L$$SI1
MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE
MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11)
.IFF ; DF L$$SI1
MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER
.ENDC ; DF L$$SI1
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
--
I'm even more curious what a PDT-11 optimization is doing in an RSX driver...was there at one time an RSX product product planned for the PDT family?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
.IF DF L$$SI1
MOVB @(R5)+,-(SP) ;;; COPY CHARACTER FOR WORD MOVE
MOV (SP)+,(R4) ;;; (SAVES 85 USECS ON PDT-11)
.IFF ; DF L$$SI1
MOVB @(R5)+,(R4) ;;; OUTPUT A CHARACTER
.ENDC ; DF L$$SI1
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
--
I'm even more curious what a PDT-11 optimization is doing in an RSX driver...was there at one time an RSX product product planned for the PDT family?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
From: Johnny Billquist <bqt at softjar.se>
Some devices have
warnings about not doing byte operations on them, while others are fine,
as far as I can remember from reading various manuals.
That's because of how the Unibus (and Q-bus) encodes cycle types.
Instead of having separate "enable" lines for low-byte and high-byte
reads and writes, it encodes the four cycle types on two lines (C0 and
C1), so the choices are DATI, DATIP, DATO, and DATOB. (DATIP is like
DATI but the master promises to follow with a DATOx, so core memories
should wait until then to rewrite, plus the whole thing might possibly
be interlocked on a PDP-11/45 etc.)
So to support byte writes (reads are always words) you have to decode
those bits (plus A0), so it adds several extra chips, which they often
don't bother with. So instead they just decode C1 alone, so DATIP is
treated like DATI (which is fine for a peripheral), and DATOB is treated
like DATO (so you're writing both bytes even though the CPU thinks it's
only writing one half). So you'll write garbage to the other byte.
Q-bus is about the same but I think they say DATIO instead of DATIP.
John Wilson
D Bit
On 2013-01-06 03:33, John Wilson wrote:
From: "Brian Schenkenberger, VAXman-" <system at TMESIS.COM>
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
I don't know the exact answer, but the I/O page in a PDT-11 is emulated by
an 8085A and it's always super slow. I don't know why DATOB would be any
worse than DATO but if DEC thought it was, I'm sure it's true (it shouldn't
have to be a read-modify-write but some PDP-11 models do gratuitous extra
cycles so it may well be). So this isn't actually a Q vs. U difference, it's
a PDT vs. real bus difference, but the LSI-11 conditionals will catch PDTs.
I know that it isn't as simple sometimes/somehow. Some devices have warnings about not doing byte operations on them, while others are fine, as far as I can remember from reading various manuals. But my memory is (as usual) fuzzy enough that I might be misremembering in one way or another.
But that would suggest that doing a DATOB might not work as expected on peripherials. Most of my brain cells actually are wasted on the 11/70, where things work slightly different, since the memory bus is actually 32 bits wide. I'm probably constantly confusing the bus cycles with the memory cycles of that machine all the time.
Thinking more, you are probably right that a DATOB shouldn't be a RMW cycle, but something in the PDT obviously don't like a byte write anyway.
Gah. I should probably re-read the bus specs now that you got me starting to think about this again... It's been too long.
Anyway, thanks Johnny! Good to know that DU and DUV are 2 for the price of 1.
(And it hadn't even clicked that the thing in a PDT is emulating a DUV, so I
guess it's 3 for the price of 1!)
You're welcome.
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
On 2013-01-06 03:40, Johnny Billquist wrote:
On 2013-01-06 03:17, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
Well, this code runs on any Qbus, so all Qbus machines "benifit" from
the code, not just the PDT-11. It's proably that on the Unibus, the
speed penalty for a read-modify-write is less than reading a byte and
pushing it on the stack, and then popping the stack and writing the word
to the bus. Also, the DU-11 might respond much faster than the DUV-11.
The buses are asynchronous, so the time for the execution is totally
dependent on the speed of the device to respond to the bus cycles.
OK. That wasn't clear from the choice of the symbol in the conditional.
I know that the selection whether to call the driver DU or DUV is based
on the L$$SI1 symbol. Sorry I probably didn't point that out enough.
That tells me that all Qbus machines get that variant. (The choice of
symbol name is probably just simply because the LSI-11 was the first
Qbus machine.)
I assume the PDT-11 mentioned is the one with a Qbus, so it's the same
controller as all other Qbus machines. But that part is really a guess.
It might be that I'm wrong on that, and that the PDT-11 have something
else, which looks and works just the same way as any other Qbus machine,
but DEC didn't have any convenient way of setting up a specific
variation for the PDT-11, so they took the small hit on Qbus machines in
order to save the PDT-11, but could avoid even the small hit on Unibus
machines, since the PDT-11 isn't even in the picture there.
And based on John's response, it seems as if it actually is this latter guess that is right.
The cost on any other Qbus machine is pretty minimal, even if it is slower to go through the stack.
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
On 2013-01-06 03:17, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
{...snip...}
Well, this code runs on any Qbus, so all Qbus machines "benifit" from
the code, not just the PDT-11. It's proably that on the Unibus, the
speed penalty for a read-modify-write is less than reading a byte and
pushing it on the stack, and then popping the stack and writing the word
to the bus. Also, the DU-11 might respond much faster than the DUV-11.
The buses are asynchronous, so the time for the execution is totally
dependent on the speed of the device to respond to the bus cycles.
OK. That wasn't clear from the choice of the symbol in the conditional.
I know that the selection whether to call the driver DU or DUV is based on the L$$SI1 symbol. Sorry I probably didn't point that out enough.
That tells me that all Qbus machines get that variant. (The choice of symbol name is probably just simply because the LSI-11 was the first Qbus machine.)
I assume the PDT-11 mentioned is the one with a Qbus, so it's the same controller as all other Qbus machines. But that part is really a guess.
It might be that I'm wrong on that, and that the PDT-11 have something else, which looks and works just the same way as any other Qbus machine, but DEC didn't have any convenient way of setting up a specific variation for the PDT-11, so they took the small hit on Qbus machines in order to save the PDT-11, but could avoid even the small hit on Unibus machines, since the PDT-11 isn't even in the picture there.
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
From: "Brian Schenkenberger, VAXman-" <system at TMESIS.COM>
OK, I'll bite. Why is moving a character in the deferred location in
R5 to the stack and then, from the stack to the address in R4 faster
than just going from the deferred R5 location to the R4 address?
I don't know the exact answer, but the I/O page in a PDT-11 is emulated by
an 8085A and it's always super slow. I don't know why DATOB would be any
worse than DATO but if DEC thought it was, I'm sure it's true (it shouldn't
have to be a read-modify-write but some PDP-11 models do gratuitous extra
cycles so it may well be). So this isn't actually a Q vs. U difference, it's
a PDT vs. real bus difference, but the LSI-11 conditionals will catch PDTs.
Anyway, thanks Johnny! Good to know that DU and DUV are 2 for the price of 1.
(And it hadn't even clicked that the thing in a PDT is emulating a DUV, so I
guess it's 3 for the price of 1!)
John Wilson
D Bit
