Hi
Is there a table of VMS versions and hardware that they support. I know that 7.3 is
the last that supports VAX. But before that, are there limitations to what versions
run on which hardware.
For instance, would VAX/VMS 1.0 run on a VAXstation 4000? Or would 7.3 run on a
11/730?
A somewhat open ended question, but I'm rather clueless to the whole thing.
Also, what separates MicroVMS from VMS?
Thanks,
Pontus.
> From: Tony Duell
> if it behaves as you describe, it would appear that if placed at the
> remote end of the bus it could lock the bus by forcing SACK/ asserted
> (as the M9302 does) if a grant chain is open [and there's a board with
> a pull-up on the grant input just after the break], whereas if it is
> placed at the CPU end it can't.
YP;IF.
But yeah, good point - this smarter board actually works _better_ at the
start of the bus, than at the end.
Noel
John,
Your program worked beautifully writing a SIMH format file on my HP 88780
tape! Thanks a million. Nothing like sending direct SCSI commands to tape
>from DOS. Drivers are overrated ;-).
Marc
================================
Date: Sat, 3 Oct 2015 02:52:36 -0400
From: John Wilson <wilson at dbit.com>
My "ST.EXE" program (available from http://www.dbit.com/pub/ibmpc/util/
including source) runs on real DOS (not Windows) and can write from an
E11-format .TAP file (which SIMH uses a garbled version of, but they're
interchangeable for *even* record lengths which are 99% of the universe) to
a real tape[...] John Wilson D Bit ===============================
I just found these on SVT ?ppet Arkiv (Open Archive).
Aside from the fact that they are fascinating time documents (cloths,
haircuts, way of speaking), these are a little bit of interest to this
community. I guess that since computers were not very commonplace at that
time, SVT really liked to emphasize how modern they were to actually use
computers.
In the 1968 they show a guy that explains that the terminal is connected to
a (IBM) 360/40 computer. Later on the actual machine is shown.
Apparently they replaced IBM by DEC in 1976 since they are showing off two
PDP-11/40 this time.
And in 1982 they put the machines almost on the scene.
http://www.oppetarkiv.se/video/2260421/valvakan-1968http://www.oppetarkiv.se/video/2432414/valvakan-1976http://www.oppetarkiv.se/video/2243834/valvakan-1982
> From: Tony Duell
> Converting between genuine 20mA loop and RS232 is not that hard.
Yes, but I'm i) lazy, and ii) overwhelmed with other projects! :-)
>> there's a 'SACK Timeout Module' (M8264) which I think performs the
>> same function, but at the _start_ of the bus. (I say 'think' because
>> this module is poorly documented - e.g. I don't know of anything which
>> definitely states which slot to plug it into.)
> I remember a 4 bit counter and LEDs, possibly to count errant grants
Yeah, that LED counter looks like a nice feature; I should find one, play
with it.
> I always assumed it went in the last SPC slot
Well, looking at the print (it's in the 11/34 Vol. 2 set that's online), it
looks like it should work plugged in anywhere; the circuit just seems to look
for any BGn/NPG that's been on 'too long', and when it sees one, asserts
SACK.
More complicated than the M9302 circuit, which depends on being last, plus
they could cram that onto the terminator, is probably why they switched to
the M9302 approach.
Noel
> From: Tony Duell
> Yes, it is a pity that the later board set (a) has the jumper to
> disable the built-in console port and (b) has the switchable divider
> allowing higher baud rates so you generally don't need to :-)
Well, except for those of us who don't have any 20mA gear, and want to
standardize on EIA... :-)
> Adjusting the RC clock is not hard given a frequency counter, and it
> doesn't have to be that precise.
The prints actually give the time for the pulse width on the two different
speed groups, so a well-calibrated 'scope should do it.
>> So, how did the M9302 see a 'grant' to start the whole process? Noise
>> on an open input? Or maybe it powers up in that state?
> The grants are the only (I think) unibus signals to be active high.
Yup. A source of great confusion to me when I started working with the QBUS,
where they are asserted _low_!
I'd done a couple of DMA network interfaces on the UNIBUS, and so was totally
familiar with how it worked, and when I recently switched to QBUS (I had used
LSI-11's extensively BITD, but not done any hardware on them), that (and a
few other similar quirks) really threw me until I got a grip on them!
> So if the grant chain is open at any point, the next device along
> (which might be the terminator) will have a grant input which is pulled
> high by the pull-up resistor.
Not always! Some devices (e.g. KW11-P) do have a pull-up, but others (e.g.
DL11) only have a pull-down. I looked through a couple of UNIBUS handbooks,
to see if there was a spec for how to terminate a grant line, and there
isn't, which probably explains the variance in practice.
But any which do have a pull-up will generate a bogus 'grant' when there's a
break in the grant line between them and their upstream. But my theory of
noise on an open input may not apply (unless there are devices with _neither_
pull-up not pull-down - I'l too lazy to exhaustively look at UNIBUS device
prints ;-).
> when that device gets the grant signal it will handle SACK and also
> will not pass the grant on to subsequent devices ... So obviously there
> is no way the grant should get all the way to the terminator. But in
> some cases (I think a device deasserting the request before it gets the
> grant is one) the grant can get all the way along the bus.
Exactly. Device is requesting interrupt, but is e.g. reset at the same time
the CPU grants the interrupt - result, unwanted grant.
> I am not sure why that was deemed to be a problem on later machines and
> not older ones (which run quite happily with the M930 terminator at
> each end of the bus)
I think the deal is that an un-wanted grant can cause things to come to a
halt until a 'grant timeout' (the '75 Peripherals Handbook says this is 5-10
usec) happens, so the M9302 speeds that up.
Interestingly, I think the M9302 was a _later_ solution to this problem in
the 11/34. In the early ones, there's a 'SACK Timeout Module' (M8264) which I
think performs the same function, but at the _start_ of the bus. (I say
'think' because this module is poorly documented - e.g. I don't know of
anything which definitely states which slot to plug it into.)
Noel
I have spent some time on the ill PDP-11/10 this weekend.
I have this machine already a few years, but I recently got an empty
H960 rack, which would be the perfect home for this PDP-11/10.
When I picked up this 11/10, the story with it was "not good".
"We put the boards in the backplane and switched on the machine.
When we saw smoke, we turned it off. We did not know that the boards
had to go in specific slots ..."!
This machine is an 11/10"S" with 16KW core in the 9-slot CPU backplane.
So, possibly the +20V core supply voltage fried ICs. However, a visual
inspection did not show any blown ICs.
After removing all boards (stored in ESD-safe bags), I first checked
the power supply. All voltages are present on the backplanes. DC LO
and AC LO are at 4.6V and have a ripple of 130 mV.
Seems acceptable to me.
Next, I placed the two CPU boards in the backplane. Of course in the
correct slots :-) and connected the console ribbon cable. Power on...
The RUN LED stays on. Alas, it is not the infamous NPG problem. The
console is not responsive, although ENABLE/HALT and then START makes
DATA/ADRRS LED 0 go on. But that's all. Seems like some fault finding
is needed in the CPU and console.
I downloaded "DEC-11-H05AA-A-D_1105um.pdf". In the back are some tests
that you can do. I hope to find the problem by elimination. Chapter 6.11
describes a few useful checks to verify the console stand alone. Great!
All 8 tests check out just fine, but ... the data pattern on the LEDs
is "inverted"! The manual says for test numbers 5, 6, 7, and 8 that the
LED pattern must be 052525, 031463, 007417, and 0003777 respectively.
I got exactly the opposite data: 125252, 146314, 170360, and 177400.
Looking at the schematic I could only explain that by a defective 7404
hex inverter, no longer inverting the input signal. But that seemed too
weird to be true, and I was not sure whether that would be a correct
assumption anyway.
Back home I downloaded "EK-KD11B-MM-001_Jan75.pdf" as a preparation to
some microstepping/debugging of the CPU. To my surprise, in the back is
a chapter 5.11 "Console maintenance". It describes exactly the same
tests, but now the LED data is different ... it is what I am seeing!
So, I am happy to say that the console is eliminated as a problem source.
I guess that the first manual is not for the 11/10 "S" version, although
it surprises me that there would be a difference in the console hardware.
I dug up 3 double-width extender boards and the KM11 maintenance panels,
getting ready to do some microstepping as described in the manual(s).
Keeping both manuals side by side!
If you have some ideas how to proceed checking the CPU, I'm all ears!
greetz,
- Henk, PA8PDP
>
> Date: Sun, 4 Oct 2015 15:01:46 -0500
> From: Jay Jaeger <cube1 at charter.net>
> Subject: Re: COS-310 "BAD DATE"
>
> I doubt that any PDP-8 family OS checks for licensing of any sort.
>
> Back in those days, DEC used the format DD-MMM-YY for dates, so try
> something like:
>
> 04-OCT-78
>
> JRJ
>
Thanks Jay, that worked!
It is different syntax from the COS 300/310 manual that I have.
Time to find a different COS manual.
--
Michael Thompson
>
> Date: Mon, 5 Oct 2015 10:10:52 -0500
> From: Ben Sinclair <ben at bensinclair.com>
> Subject: Re: Trivia Question: Pixar Image Computer
>
> Are any Pixar Image Computers in the hands of collectors? I would love
> to have one of those, even if it didn't do anything!
>
> --
> Ben Sinclair
> ben at bensinclair.com
>
The RICM has two:
http://www.ricomputermuseum.org/Home/equipment/pixar-image-computer
--
Michael Thompson
Unfortunately I wasn't there but I still bring you photos, taken by
Jack Rubin, from this weekend's Vintage Computer Festival Berlin:
https://picasaweb.google.com/102190732096693814506/VCFBerlin2015?noredirect…
I don't have any additional info to go with them, so we'll have to
wait for Jack to return to the console and fill us in. In the
meantime, enjoy the pics!
-j
