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...
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
