[Simh] EXT :Re: The UDA

[Timothe Litt]

On 30-Apr-15 20:41, Johnny Billquist wrote:
> On 2015-05-01 02:03, Timothe Litt wrote:
>> On 30-Apr-15 19:13, Cory Smelosky wrote:
>>> On Thu, 30 Apr 2015, Timothe Litt wrote:
>>>
>> KL only (KLIPA = KL -> CI adapter).  No CI adapter for the KS.
>
> Of course, the curious mind, especially in the light of where this
> thread started, then wonders if not the UDA-50 would be possible to
> use on a KS...?
>
> Hmm, that might fail on that the UDA-50 might not have been able to
> deal with 576 byte sectors... I seem to remember you needed some
> specific versions of CRONIC for the UDA-50 to use 576 byte block
> disks...?
I looked into that after the UDA was released, when the KL was taking
bits of Jupiter to get its CI support.  The UDA50 did not support
576-byte sectors, nor did it support 18-bit data transfers on the
Unibus.   The former could be dealt with in microcode; the latter would
require hardware changes somewhere.  Either in the UDA or in the UBA.

My friends in storage weren't interested in extending the UDA as a
midnight project, and declared it infeasible years later when the
KS-follow-on was an official project and a full evaluation was done. 
The UDA50 had insufficient hardware resources and it would have required
a major hardware revision.  That would have lost the economies of
re-using the UDA.  The Unibus was pretty much at end of life, so an
extended UDA wasn't going to be absorbed by future VAXs & 11s.  And we
would have ended up with, well, the UDA.  Which had its own issues,
including the lack of transfer optimizations.  A new UBA for the KS
wasn't going to happen under the radar, which is how I did what I could
for the KS. 

There were proposals for xBA hardware in the follow-on to map transfers
onto 512-byte sectors, but they had issues.  Among them: Unibus
performance, exchanging removable media (RA60) with the rest of the
family, and file system assumptions.   There was another proposal to
just map 18-bit transfers into 16-bits in the UBA, which was reasonable
- if the UDA took on 576 byte sectors.  I suspect that we would have
ended up with a KS backplane bus -> SDI/STI module instead, though the
development cost would have been rather high.

In any case, the KS follow-on project wasn't allowed to proceed and the
issues were left unresolved. 

You can read some of the documents at:

https://archive.org/stream/bitsavers_decpdp10KDcentPDP10Jun83_1864586/A_Low_Cost_Space_Efficent_PDP-10_Jun83#page/n15/mode/2up

and

http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KD10/KD10_Architectural_Design_Spec_Jul83.pdf

Despite the authoritative style, these were works-in-progress, and
issues remained...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150501/39f1d4c2/attachment-0001.bin>