I think I've located the SPL install file for ALL-IN-1, anybody know just exactly how difficult this is to install (I've heard horror stories)..
sampsa
I've read my BP2 v2.7 tape. I did it on a UNIX system using Johnny's
tape tools, and I have it a a .TPC file.
The tape read cleanly, but again I do not know where this came
from...it has a handwritten label indicating that it's BP2 v2.7, but it
may have actually been written from the corrupted tape image in the
trailing-edge archive. That archive has been around for long enough for
this to be a concern.
Is there anyone hanging out tonight who would like to assist me in
testing this?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I have located 9-track install tapes of BP2 v2.7 and PDP-11 C v1.2 in
my tape library. They are not original tapes; the labels are
hand-written (not by me) so I don't know their status. I will attempt
to recover them in the coming days.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
So I'm back to hacking on RSX-11M-Plus again, this time in a more
leisurely fashion, and under simh on a laptop since I'm still stuck in
bed with the "Primus Plague" that I caught while at VCF.
I'm trying to install C and F77 from .tpc files in the trailing-edge
archive, and I'm failing miserably. I've attached them to tq0 and have
tried every possible combination of FORMAT=TPC/FORMAT=SIMH, use of
mtcvt23, etc and cannot get past "tape label error on MU0:" from
autoins.cmd.
Doing this under RSTS/E is a breeze, and I expected it to be even
easier under RSX.
I assume I'm not the first person to hit this problem. Before I dig
deeper and spend a lot of time, does anyone know what's going on?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Should be good now!
Regards, Mark
On 03/05/15 09:51, Jim Carpenter wrote:
> Most of the files are inaccessible because of a permission problem.
>
> Jim
>
> On Sun, May 3, 2015 at 4:15 AM, Mark Wickens <mark at wickensonline.co.uk> wrote:
>> I've just uploaded all I have here:
>> http://www.wickensonline.co.uk/static/files/Ultrix/
>>
>> I can't guarantee all the images work, but the images in the v4.4 directory
>> were ripped from original CDROMs by me - so if there is an issue with these
>> they can probably be corrected.
>>
>> Regards, Mark
>>
>> On 02/05/15 14:22, Steve Davidson wrote:
>>> Mark,
>>>
>>> The previous email came from the wrong account. Sorry about that! In any
>>> event do you have the ULTRIX 4.5 and ULTRIX DECnet 4.5 kits in your
>>> collection? Also any other Layered Products for ULTRIX 4.5 would be
>>> helpful.
>>>
>>> Thanks!
>>>
>>> -Steve
>>>
From: Dave McGuire <mcguire at neurotica.com>
>I myself have multiple KS10 systems here, and would love to be able to
>plug DEUNAs into their Unibus chassis at some point and have it actually
>work.
I probably say this every time this comes up: I've heard the point made
that the DEUNA draws too much power to live in a KS10's BA11K along with
the usual mess of stuff. I haven't checked the math but it certainly
wouldn't hurt to make it a DELUA instead, for that reason alone.
At one point I got a minimal start on writing a DELUA driver for ITS, but
it's on my ITS RM80 that may or may not still work.
John Wilson
D Bit
From: Johnny Billquist <bqt at softjar.se>
>I seem to remember having read that they were parity for each byte, but
>looking at a Unibus spec now (from 1979), it seems PB is actually
>indicating a parity error, while PA is reserved for future use.
OK I had PA and PB reversed, but, exactly. I don't know if that means
PA/PB had a slightly different meaning in the early days when the parity
controller was outboard of the core stacks (in that case I'd think you
couldn't mix old and new hardware, which doesn't seem to be a problem),
or else they changed the spec before the hardware hit the streets and
everything is fine (which sounds more like it).
>And the
>slave are expected to generate these signals, and the master is expected
>to check them, so I guess the DEUNA/DELUA should generate/check them, if
>it is a proper Unibus citizen. Which could make life in a KS interesting...
Well, my point is that if it's true that PB is now asserted only on an error
(vs. both being asserted or not depending on the parity of that byte),
then if it *never* gets asserted, everything's fine. Accesses to CSR space
certainly don't check parity so it seems that nothing bad happens if you
don't assert these pins. And I'm thinking the DEUNA/DELUA would stop with
a parity error if it found PB asserted when reading memory with DMA, which
is a good reason to make sure the data structures and buffers you give it
never have the 17th/18th bits set, but otherwise, no sweat. You're giving up
parity checking but the KS10 MMC/MMAs already do ECC and I don't think they
need Unibus masters to be in charge of noticing flaky RAM.
John Wilson
D Bit
