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
All,
For those who did not attend VCF East you missed a great time! On
Saturday, the keynote speaker was none other than Brian Kernighan. You
really missed a treat - right Dave!
Next year, I plan to bring even more stuff (not nearly as much as Dave
did) but more than this year. Dave's island of equipment included the
following:
PDP-8
PDP-11/34
PDP-11/44
DECserver-200
multiple terminals
I'm sure I have forgotten something...
I added:
VAXstation 4000/60
DEChub-90 backplane with a DECserver-90TL and a 16-port DEChub
VT320
a gateway (actually bridge) machine to connect to HECnet only the link
was pathetic
Brian (aka VAXman) added:
VAXstation 4000/30 (aka VLC)
In addition to the "island" Dave had other "exhibits" that I will defer
to Dave for discussion.
Next year we NEED more stuff! This is the official challenge to anyone
on the East coast. We want to see many more of you. If is is DEC it is
needed.
I would also like to personally add my thanks to Dave and Brian for
making this such a treat. Dave is nuts (in a good way) and very
generous. Brian was there for me when my brain could not content with
the sheer volume of noise - helping me to configure the DECservers and
dealing with my fat fingering the keyboard and the license management
facility (LMF). For a while we were Frick and Frack but we managed to
get it together. Thanks guys!
-Steve
Peter,
How exactly do I BOOT the SC-40 from tape? You're the only onw who knows.
;)
I have a compatible HVD tape drive and a properly-written tape...now I
just need to know how to boot it.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Hello,
I've been attempting to (likely incorrectly) get the DEUNA emulation
working in SIMH's KS10 simulator.
Current status:
* Exists
* Has an address
* Has a vector
* Can be enabled
* Can attach to host interface
...and that's as far as I've gotten. Currently having issues getting
TOPS-10 to successfully link for KS10 with ethernet support. Anyone have
a pre-genned MONITOR executable?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
From: Johnny Billquist <bqt at softjar.se>
>I'm curious on exactly how a DEUNA/DELUA works in a KS-10. Does anyone
>know? Does it do 8-bit-byte DMA to the 18-bit memory, leaving the top
>two bits alone. Or does it only work if it do word DMA (would be
>strange, as the controller itself can send and receive odd byte length
>ethernet packets).
This is what the BLTBU and BLTUB instructions are for in the later microcode
(converting between sensible PDP-10 memory and the mishmash you get as a
result of DMA through the UBA to a 16-bit peripheral). Since a DELUA is
not 18-bit-data-aware, it ignores the high two bits of each 18-bit halfword
when doing DMA.
>Is there some potential problem with regards to a PDP-11, which have two
>parity bits for data, which are used for actual data on a KS? (If I
>remember right.)
IIRC you're OK as long as you don't set those bits in memory that the DELUA
will read. I feel like the Unibus documentation changed at some point,
between whether PA/PB are actual parity bits (I think that's what the very
early doc said), vs. being parity *error* bits (and I think PB isn't even
really used -- PA asserted means there's been a parity error detected in the
current DATI/DATIP). I could be wrong about all of this.
John Wilson
D Bit
