I'm interested in obtaining some Programmer Reference Manuals (PRMs) for some old 1100/2200 Series peripherals.
In particular, I'm interested in a PRM for a word channel disk subsystem (i..e. a 5046, 5056, or 5057 CU with 8450 or 8470 disks drives), a PRM for word channel drum (i.e. a 492 or 1792), and a PRM for a block mux channel tape drive subsystem (i.e. a 5042 with something like a U36N tape drive).

Yes, I've already looked for these manuals on Bitsavers as well as the Unisys support Web site.
They aren't there (or at least not obviously so).
No luck on eBay either.

I assume that I can use the manual for a "Sticky" (STC) 3600 as a substitute for the BMC tape subsystem manual, but that's about it when it comes to substitutions.
Any other substitution suggestions would be welcome as well.

I'm not sure what you want them for but the 8430/8433 disks were word channel disks (IIRC) and the manuals for those are on bitsavers:

http://www.bitsavers.org/pdf/univac/disk/8405_8430_8433/

I would expect the command codes and CCW formats to be more-or-less the same between the various word channel disks.

The only Uniservo PRM that I can find is for the U6C which is ancient. The basic command codes are likely the same but this drive likely to be from the 1107 era or there about. If the language seems a bit odd it is because it was translated from a German manual using Google Translate and what little I could remember of my high school german.

https://www.dropbox.com/s/xuv9w3p2yroejff/Uniservo%20VI%20C%20Technical%20Description.rtf?dl=0

Enjoy

I also found an manual for an FH880 drum. Not specifically the one you were looking for but ...

chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/http://www.bitsavers.org/pdf/univac/1107/UT-2560_FH-880_Drum_Dec61.pdf

On 9/5/2022 8:42 AM, sboy...@gmail.com wrote:
> I'm not sure what you want them for but the 8430/8433 disks were word channel disks (IIRC) and the manuals for those are on bitsavers:
>
> http://www.bitsavers.org/pdf/univac/disk/8405_8430_8433/
>
> I would expect the command codes and CCW formats to be more-or-less the same between the various word channel disks.

No. The early disks used an IBM style controller, interfaced to a word
channel via a device called a Multi-Systems Adapter (MSA). This device
essentially presented a word interface to the channel, but an IBM style
channel interface to the peripheral controller. This was used to allow
Univac to use peripheral devices available for IBM systems. This
included disks, such as the ones listed above, tape drives, and even a
few printers such as the 770. This is the interface described in the
above referenced manuals.

Later (1977?), Univac developed their own word channel disk controller,
the model 5046 (later the 5056, a compatible but faster controller).
This implemented a totally different (and much more advanced) interface
to the word channel (including things like word addressing and automatic
read before write in the controller), but it still supported disks like
the 8430/8433, as well as newer disks like the 8434, 8450, 8470, etc.

Even later, the 5057 controller was the caching controller, and had a
different interface yet.

> The only Uniservo PRM that I can find is for the U6C which is ancient. The basic command codes are likely the same but this drive likely to be from the 1107 era or there about. If the language seems a bit odd it is because it was translated from a German manual using Google Translate and what little I could remember of my high school german.
>
> https://www.dropbox.com/s/xuv9w3p2yroejff/Uniservo%20VI%20C%20Technical%20Description.rtf?dl=0

As I mentioned above, Univac (at least later) tape systems were IBM
compatible tape systems attached through an MSA. If you look at the
manuals referenced above, but substitute the tape commands (from an IBM
or StorageTech tape system manual) for the disk commands in the MSA
command words, you will have most of it (except for the character
translation and formatting stuff, e.g 6 bit Fieldata to/from 8 bit
EBCDIC - used for tape data interchange with IBM systems).

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Monday, September 5, 2022 at 8:42:32 AM UTC-7, sboy...@gmail.com wrote:
> I'm not sure what you want them for but the 8430/8433 disks were word channel disks (IIRC) and the manuals for those are on bitsavers:
>
> http://www.bitsavers.org/pdf/univac/disk/8405_8430_8433/
>
> I would expect the command codes and CCW formats to be more-or-less the same between the various word channel disks.
>

Thank you for your reply.
However, it's my understanding that its the Control Unit (CU) and not the attached disk that determines what sort of commands and status that the "disk" responds to/returns and so I'm specifically interested in disk subsystems containing the work channel controllers I mentioned.
The 5057 is a cache disk controller and so used 5-word EFs rather than the 2-word EFs used by the 5046 and so I can actually live without the PRM for a 5057 subsystem, but I figure it would be "nice" to have anyway.

IIRC, each of these CUs could have 8450 and 8470 disks attached (although not a mixture of both at the same time) including their "fixed head" variants (if any) which had a set of fixed heads that could read from the lower surface of the bottom platter.
I mention this to show that it's the CU that matters as the same disks could be used on the CU5057B, the byte channel version of the CU5057.

> The only Uniservo PRM that I can find is for the U6C which is ancient. The basic command codes are likely the same but this drive likely to be from the 1107 era or there about. If the language seems a bit odd it is because it was translated from a German manual using Google Translate and what little I could remember of my high school german.
>
> https://www.dropbox.com/s/xuv9w3p2yroejff/Uniservo%20VI%20C%20Technical%20Description.rtf?dl=0
>
> Enjoy

Thank you.
I used to have about 3 lineal feet of old peripheral manuals on my desk at work, most of which I didn't use.
The PRMs for the peripheral subsystems I mentioned were the ones that I most often did.

On Monday, September 5, 2022 at 8:52:11 AM UTC-7, sboy...@gmail.com wrote:
> I also found an manual for an FH880 drum. Not specifically the one you were looking for but ...
>
> chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/http://www.bitsavers.org/pdf/univac/1107/UT-2560_FH-880_Drum_Dec61.pdf

Thanks again for the reply.
As I mentioned in my OP, I check Bitsavers and didn't find what I was looking for.

I can't recall how similar the 880 was to 492 or 1792 and so I'd just as soon find a real live manual for the latter drums if I could.

Just as an aside, the last time I ran into a 1792 drum, it was for the first M-Series 2200, the 2200/900.
A customer still had them and word channels were still supported on the 2200/900 and so they wanted to know if they could attach and boot from one.
Officially, drums weren't supported on the 2200/900 (ICLP in particular didn't have a handler for a word channel drum), but it only took a few lines to patch ICLP to boot from a drum and AFAIK it worked.

On Monday, September 5, 2022 at 9:58:44 AM UTC-7, Stephen Fuld wrote:
> On 9/5/2022 8:42 AM, sboy...@gmail.com wrote:
> > I'm not sure what you want them for but the 8430/8433 disks were word channel disks (IIRC) and the manuals for those are on bitsavers:
> >
> > http://www.bitsavers.org/pdf/univac/disk/8405_8430_8433/
> >
> > I would expect the command codes and CCW formats to be more-or-less the same between the various word channel disks.
> No. The early disks used an IBM style controller, interfaced to a word
> channel via a device called a Multi-Systems Adapter (MSA). This device
> essentially presented a word interface to the channel, but an IBM style
> channel interface to the peripheral controller. This was used to allow
> Univac to use peripheral devices available for IBM systems. This
> included disks, such as the ones listed above, tape drives, and even a
> few printers such as the 770. This is the interface described in the
> above referenced manuals.
>
> Later (1977?), Univac developed their own word channel disk controller,
> the model 5046 (later the 5056, a compatible but faster controller).
> This implemented a totally different (and much more advanced) interface
> to the word channel (including things like word addressing and automatic
> read before write in the controller), but it still supported disks like
> the 8430/8433, as well as newer disks like the 8434, 8450, 8470, etc.
>
> Even later, the 5057 controller was the caching controller, and had a
> different interface yet.
> > The only Uniservo PRM that I can find is for the U6C which is ancient. The basic command codes are likely the same but this drive likely to be from the 1107 era or there about. If the language seems a bit odd it is because it was translated from a German manual using Google Translate and what little I could remember of my high school german.
> >
> > https://www.dropbox.com/s/xuv9w3p2yroejff/Uniservo%20VI%20C%20Technical%20Description.rtf?dl=0
> As I mentioned above, Univac (at least later) tape systems were IBM
> compatible tape systems attached through an MSA. If you look at the
> manuals referenced above, but substitute the tape commands (from an IBM
> or StorageTech tape system manual) for the disk commands in the MSA
> command words, you will have most of it (except for the character
> translation and formatting stuff, e.g 6 bit Fieldata to/from 8 bit
> EBCDIC - used for tape data interchange with IBM systems).
>
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Thanks for the reply (and for confirmation about what I recalled about peripheral subsystems).
As for 6-bit to 8-bit translation, I'm not particularly interested in that as it was (IIRC) a non-issue for any of the older 1100s with IOPs thanks to the B-format flag (?) in their CCWs.

On 9/5/2022 10:13 AM, Lewis Cole wrote:
> On Monday, September 5, 2022 at 9:58:44 AM UTC-7, Stephen Fuld wrote:
>> On 9/5/2022 8:42 AM, sboy...@gmail.com wrote:
>>> I'm not sure what you want them for but the 8430/8433 disks were word channel disks (IIRC) and the manuals for those are on bitsavers:
>>>
>>> http://www.bitsavers.org/pdf/univac/disk/8405_8430_8433/
>>>
>>> I would expect the command codes and CCW formats to be more-or-less the same between the various word channel disks.
>> No. The early disks used an IBM style controller, interfaced to a word
>> channel via a device called a Multi-Systems Adapter (MSA). This device
>> essentially presented a word interface to the channel, but an IBM style
>> channel interface to the peripheral controller. This was used to allow
>> Univac to use peripheral devices available for IBM systems. This
>> included disks, such as the ones listed above, tape drives, and even a
>> few printers such as the 770. This is the interface described in the
>> above referenced manuals.
>>
>> Later (1977?), Univac developed their own word channel disk controller,
>> the model 5046 (later the 5056, a compatible but faster controller).
>> This implemented a totally different (and much more advanced) interface
>> to the word channel (including things like word addressing and automatic
>> read before write in the controller), but it still supported disks like
>> the 8430/8433, as well as newer disks like the 8434, 8450, 8470, etc.
>>
>> Even later, the 5057 controller was the caching controller, and had a
>> different interface yet.
>>> The only Uniservo PRM that I can find is for the U6C which is ancient. The basic command codes are likely the same but this drive likely to be from the 1107 era or there about. If the language seems a bit odd it is because it was translated from a German manual using Google Translate and what little I could remember of my high school german.
>>>
>>> https://www.dropbox.com/s/xuv9w3p2yroejff/Uniservo%20VI%20C%20Technical%20Description.rtf?dl=0
>> As I mentioned above, Univac (at least later) tape systems were IBM
>> compatible tape systems attached through an MSA. If you look at the
>> manuals referenced above, but substitute the tape commands (from an IBM
>> or StorageTech tape system manual) for the disk commands in the MSA
>> command words, you will have most of it (except for the character
>> translation and formatting stuff, e.g 6 bit Fieldata to/from 8 bit
>> EBCDIC - used for tape data interchange with IBM systems).
>>
>>
>>
>> --
>> - Stephen Fuld
>> (e-mail address disguised to prevent spam)
>
> Thanks for the reply (and for confirmation about what I recalled about peripheral subsystems).

You're most welcome.

> As for 6-bit to 8-bit translation, I'm not particularly interested in that as it was (IIRC) a non-issue for any of the older 1100s with IOPs thanks to the B-format flag (?) in their CCWs.

Ah you young whippersnappers! There were successful 1100 series systems
before the advent of IOPs (which IIRC came in with the 1100/80).
Specifically, the 1108, 1106, and 1110, and their solid state memory
counterparts, the 1100/20, /10 and /40 had only word channels, and no
IOPs (the 1110 IOACU was essentially just a way to repackage channels
separate from the CPU). These systems didn't have CCWs at all, but used
different instructions (Load Function in Channel, Load Input Channel,
Load Output Channel, and a few related instructions) to instruct the
channel to do I/O. So, the 6/8 bit character and Fieldata/EBCDIC
conversions were done in the MSA.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Monday, September 5, 2022 at 5:39:40 PM UTC-7, Stephen Fuld wrote:
> On 9/5/2022 10:13 AM, Lewis Cole wrote:
> > <snip>
> > Thanks for the reply (and for confirmation about what I recalled about peripheral subsystems).
> You're most welcome.
> > As for 6-bit to 8-bit translation, I'm not particularly interested in that as it was (IIRC) a non-issue for any of the older 1100s with IOPs thanks to the B-format flag (?) in their CCWs.
> Ah you young whippersnappers! [...]

Guilty as charged.

> [...] There were successful 1100 series systems
> before the advent of IOPs (which IIRC came in with the 1100/80).
> Specifically, the 1108, 1106, and 1110, and their solid state memory
> counterparts, the 1100/20, /10 and /40 had only word channels, and no
> IOPs (the 1110 IOACU was essentially just a way to repackage channels
> separate from the CPU).

Yes, the 1108 started it all (thankfully for all the paychecks that I was to collect for years afterwards).
But I showed up around the time the 1100/60 was getting ready to go out the door and my "home" system at the time was an 1100/80A.
I could have used a lonely 1108 that sat in the corner of the production floor as my own "personal computer" if I wanted to, but I never did.
Nevertheless, by that time, no matter how the actually appeared as hardware, us young members of the software priesthood could treat them the same as IOUs since that's where they appeared in the MCT (that's Master Configuration Table you even younger whippersnappers) and I'm content to live with this fiction.

> These systems didn't have CCWs at all, [...]

Well, IIRC they had ACWs and I *THINK* there was at least a flag for data chaining so things were at least beginning to evolve towards the light.

> [...] but used
> different instructions (Load Function in Channel, Load Input Channel,
> Load Output Channel, and a few related instructions) to instruct the
> channel to do I/O. [...]

There was some sort of nursery rhyme I was supposed to learn long ago ... "Ticks and Tocks, Licks and Locks ... ".
I'm afraid I didn't bother to memorize it though as I liked to just say "SIOF!" and later "SEND!".

> [...] So, the 6/8 bit character and Fieldata/EBCDIC
> conversions were done in the MSA.

Well, being a whippersnapper, I didn't bother to care about tape labels until the 1100/90 when the existence of ICLP made it possible to have labelled boot tapes.
Thanks for your recollections of The Good Old Days.

> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 9/5/2022 7:31 PM, Lewis Cole wrote:
> On Monday, September 5, 2022 at 5:39:40 PM UTC-7, Stephen Fuld wrote:
>> On 9/5/2022 10:13 AM, Lewis Cole wrote:
>>> <snip>
>>> Thanks for the reply (and for confirmation about what I recalled about peripheral subsystems).
>> You're most welcome.
>>> As for 6-bit to 8-bit translation, I'm not particularly interested in that as it was (IIRC) a non-issue for any of the older 1100s with IOPs thanks to the B-format flag (?) in their CCWs.
>> Ah you young whippersnappers! [...]
>
> Guilty as charged.
>
>> [...] There were successful 1100 series systems
>> before the advent of IOPs (which IIRC came in with the 1100/80).
>> Specifically, the 1108, 1106, and 1110, and their solid state memory
>> counterparts, the 1100/20, /10 and /40 had only word channels, and no
>> IOPs (the 1110 IOACU was essentially just a way to repackage channels
>> separate from the CPU).
>
> Yes, the 1108 started it all (thankfully for all the paychecks that I was to collect for years afterwards).
> But I showed up around the time the 1100/60 was getting ready to go out the door and my "home" system at the time was an 1100/80A.
> I could have used a lonely 1108 that sat in the corner of the production floor as my own "personal computer" if I wanted to, but I never did.
> Nevertheless, by that time, no matter how the actually appeared as hardware, us young members of the software priesthood could treat them the same as IOUs since that's where they appeared in the MCT (that's Master Configuration Table you even younger whippersnappers) and I'm content to live with this fiction.
>
>> These systems didn't have CCWs at all, [...]
>
> Well, IIRC they had ACWs and I *THINK* there was at least a flag for data chaining so things were at least beginning to evolve towards the light.

Yes, there were ACWs - "Access Control Words (they were what you loaded
into the channels with LIC/LOC or LFC, etc. and what was called
"scatter/gather" I/O, which was the equivalent of data chaining. Here
the ACW, instead of pointing to the data, pointed to a list of ACWs that
pointed to the data.

BTW, if you are interested in all the gory details, the 1108 Processor
and Storage Reference manual is on Bitsavers.

>
>> [...] but used
>> different instructions (Load Function in Channel, Load Input Channel,
>> Load Output Channel, and a few related instructions) to instruct the
>> channel to do I/O. [...]
>
> There was some sort of nursery rhyme I was supposed to learn long ago ... "Ticks and Tocks, Licks and Locks ... ".

I don't remember that. If you remember more, please do tell. Load
Input Channel was indeed called "lick" as a "shortcut" as its
instruction name was LIC. Similarly for LOC. But TIC (transfer in
channel) was, in fact I believe still is, the channel instruction
"Transfer in Channel", but perhaps it just meant the ticking of the
clock. :-)

> I'm afraid I didn't bother to memorize it though as I liked to just say "SIOF!" and later "SEND!".

I understand. But SIOF (and send even more so) required much more
hardware to implement, and in the time of the 1108, that was probably
prohibitive.

>> [...] So, the 6/8 bit character and Fieldata/EBCDIC
>> conversions were done in the MSA.
>
> Well, being a whippersnapper, I didn't bother to care about tape labels until the 1100/90 when the existence of ICLP made it possible to have labelled boot tapes.

Tape labels are a different topic altogether. You needed conversion
to/from EBCDIC to transfer even unlabeled tapes between IBM and Univac
systems. In fact, the format stuff in the Block Mux IOP was a direct
lift of the functionality originally in the MSA, and done for exactly
the same reason. BTW, Univac didn't support labeled tapes of any
variety until IIRC Exec level 33. And you are correct that labeled
tapes couldn't be used as boot tapes until much later.

> Thanks for your recollections of The Good Old Days.

It's fun to take a stroll down memory lane. :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Wednesday, September 7, 2022 at 10:50:56 PM UTC-7, Stephen Fuld wrote:
> On 9/5/2022 7:31 PM, Lewis Cole wrote:
< snip >
> Yes, there were ACWs - "Access Control Words <snip>
>
> BTW, if you are interested in all the gory details, the 1108 Processor
> and Storage Reference manual is on Bitsavers.

Thanks for the pointer.
I'll keep it in mind although ISTM that the 1108 was the start of the Univac/Sperry/Unisys to keep outsiders in the dark when it comes to how I/O was done.
IIRC, if I really wanted to know how word ESI worked, I had to look at the earlier 1110 (or was it 1108?) manuals to find out anything ... the 1100/80 manual was virtually useless.
Since the removal of the IOP information from the M-Series Processor and Storage manual, the obfuscation seems complete.

But getting back to my OP, I'm more interested in peripheral subsystems.
I can understand the disappearance of anything having to do with word channel tapes as they didn't seem to last too long, but drums and disks lasted much longer.
Of course, you could have pointed out that I messed up the model numbers of the drum subsystems and didn't mention a controller number (all of which is true), but even using the correct model numbers doesn't get me anywhere either.
Despite their usage on 1100/2200 Series systems, the most information about them (from a programmer point of view) comes from 494 documentation.
I'd like to think that all I'd have to do convert that information (in particular the EF and EI formats) is to pad/strip 6-bits to the high order end of a 30-bit word to come up with the 36-bit equivalent, but I can't find anything that says that is what can/should be done.

But disk subsystems are a different matter.
They existed and were used for quite some time, but I can't find anything about them.
Even the 1100/50 word disk stuff (DSACs?) which were an integrated word channel and 5046/5056 CU just doesn't seem to exist as far as documentation goes.
Your summary of the history of the 5046/5056/5057 is about as good as anything I've run across about them.

< snip >
>> There was some sort of nursery rhyme I was supposed to learn long ago .... "Ticks and Tocks, Licks and Locks ... ".
>
> I don't remember that. If you remember more, please do tell. Load
> Input Channel was indeed called "lick" as a "shortcut" as its
> instruction name was LIC. Similarly for LOC. But TIC (transfer in
> channel) was, in fact I believe still is, the channel instruction
> "Transfer in Channel", but perhaps it just meant the ticking of the
> clock. :-)

I don't recall the gory details of the nursery rhyme and the people who would know about it are dead. :-(
It might not have all been about I/O but rather differences between really old 1100 Series systems and "newer" 1100 Series system in which case the reference to "ticks" and "tocks" might have been a reference to the fact that the dayclock was put into just about every major component except for the operator's console chair rather "Transfer In Channel".

<snip>

On 9/8/2022 12:19 PM, Lewis Cole wrote:
> On Wednesday, September 7, 2022 at 10:50:56 PM UTC-7, Stephen Fuld wrote:
>> On 9/5/2022 7:31 PM, Lewis Cole wrote:
> < snip >
>> Yes, there were ACWs - "Access Control Words <snip>
>>
>> BTW, if you are interested in all the gory details, the 1108 Processor
>> and Storage Reference manual is on Bitsavers.
>
> Thanks for the pointer.
> I'll keep it in mind although ISTM that the 1108

1100/80 ?

was the start of the Univac/Sperry/Unisys to keep outsiders in the dark
when it comes to how I/O was done.
> IIRC, if I really wanted to know how word ESI worked, I had to look at the earlier 1110 (or was it 1108?) manuals to find out anything ... the 1100/80 manual was virtually useless.

I did look at the 1100/80 processor and storage manual, and I agree that
its explanation of ESI was minimal at best. In Univac's defense, I
think ESI was on the way out by then, replaced by "intelligent" terminal
controllers such as the C/SP and the DCS (?)

> Since the removal of the IOP information from the M-Series Processor and Storage manual, the obfuscation seems complete.
>
> But getting back to my OP, I'm more interested in peripheral subsystems.
> I can understand the disappearance of anything having to do with word channel tapes as they didn't seem to last too long, but drums and disks lasted much longer.

Yes. Drums were on the way out by the time of byte channel
availability. Tapes migrated to byte channels because it was cheaper
(no need for an MSA), and the performance was just as good. Disks
persisted on word channels primarily because the 5046 and successors
allowed much more efficient operation, moving a lot of work from the CPU
and or the channel to the controller. This included conversion of
device relative address to cylinder/head/record, performing read before
writes as needed, performing ECC correction, as well as substantially
reducing the number of interactions between the channel and the controller.

> Of course, you could have pointed out that I messed up the model numbers of the drum subsystems and didn't mention a controller number (all of which is true), but even using the correct model numbers doesn't get me anywhere either.

I forget the model number of the drum controllers (IIRC there were three
of them, one for the FH drums, one for Fastrand drums, and one for the
8460 (actual physical disks emulating Fastrands). From memory, each had
a one word EF that gave the function, the unit number and the starting
address. The length wasn't explicitly sent to the controller. The
transfer stopped when the host stopped sending/taking words for a
specified (pretty short) amount of time. This happened when the count
in the ACW was exhausted. The status word was also one word.

> Despite their usage on 1100/2200 Series systems, the most information about them (from a programmer point of view) comes from 494 documentation.
> I'd like to think that all I'd have to do convert that information (in particular the EF and EI formats) is to pad/strip 6-bits to the high order end of a 30-bit word to come up with the 36-bit equivalent, but I can't find anything that says that is what can/should be done.
>
> But disk subsystems are a different matter.
> They existed and were used for quite some time, but I can't find anything about them.
> Even the 1100/50 word disk stuff (DSACs?) which were an integrated word channel and 5046/5056 CU just doesn't seem to exist as far as documentation goes.

I know nothing about the 1100/50.

Again, from memory (as I can't find my copy of the 5046 manual). Most
External Function words (EFs) were two words long. Exceptions were
things like Sense and Read IPL which were one word long.

The first word contained the unit number (4 bits), the function (e.g.
read/write/preseek) 6 bits (?), and (for the read and write) the
transfer length in the low order 16(?) bits. The preseek was the same
except instead of the length, the low order two bits gave a value about
how much time to allow between the seek completion and the expected time
of the disk's rotation to reach the start of the requested record.

For most commands, the second word contained the device relative word
address of the start of the transfer. There were actually two read
commands, Read Data and Read Data Special. The difference was that Read
Data Special allowed the controller to start the transfer from its
internal buffer to the host before all the data for the disk record was
in the buffer. This reduced latency, improving performance, but at the
cost that if an ECC error was detected in the data, the controller
couldn't correct it as the data was already sent to the host. So the
typical sequence used read data special, but if the controller detected
a correctable ECC error, it would report that as an error, and the host
would retry the read using the read data command to get the corrected
data. Of course, this happened very infrequently.

> Your summary of the history of the 5046/5056/5057 is about as good as anything I've run across about them.

Thank you. I hope the above helps you.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

> On Friday, September 16, 2022 at 10:08:43 AM UTC-7, Stephen Fuld wrote:
>> On 9/8/2022 12:19 PM, Lewis Cole wrote:
>>> On Wednesday, September 7, 2022 at 10:50:56 PM UTC-7, Stephen Fuld wrote:
>>>> On 9/5/2022 7:31 PM, Lewis Cole wrote:

< snip >
>>> BTW, if you are interested in all the gory details, the 1108 Processor
>>> and Storage Reference manual is on Bitsavers.
>>
>> Thanks for the pointer.
>> I'll keep it in mind although ISTM that the 1108
>
> 1100/80 ?
>
>> was the start of the Univac/Sperry/Unisys to keep outsiders in the dark
>> when it comes to how I/O was done.

No, I meant 1108.
While the Company seemed to try to document everything in sight in the Good Old Days (in particular in the Processor and Storage manual) in the beginning, I think that changed ... I don't recall them mentioning anything about the designator bit that allowed the 1108 to address beyond 262K.
The implications for I/O seem obvious to me.
If you want to say that this was covered in something other than the R1 manual (UP-4052) that I happen to have and that I should RTFM, I'll accept your observation defer to your expertise.

< snip >

>> But getting back to my OP, I'm more interested in peripheral subsystems.
>> I can understand the disappearance of anything having to do with word
>> channel tapes as they didn't seem to last too long, but drums and disks
>> lasted much longer.
>
> Yes. Drums were on the way out by the time of byte channel
> availability.

Agreed, although as I mentioned before, a customer did ask the Company if they could boot a 2200/900 from a drum for some reason.
Officially, they weren't supported, but the tweaks to ICLP to make it happen were relatively minor amounting to basically adding the monitor interrupt bit to the last CCW in the chain to read in the boot block.

The "good news" is that I stumbled across something for the 1108 recently that basically said that the 1782 and 432 were just cheaper versions of the 880.
Assuming that this is the case, then I should be able to use the 880 manual found in Bitsavers.

< snip >
>
>> Of course, you could have pointed out that I messed up the model
>> numbers of the drum subsystems and didn't mention a controller
>> number (all of which is true), but even using the correct model
>> numbers doesn't get me anywhere either.
>
> I forget the model number of the drum controllers (IIRC there were three
> of them, one for the FH drums, one for Fastrand drums, and one for the
> 8460 (actual physical disks emulating Fastrands). From memory, each had
> a one word EF that gave the function, the unit number and the starting
> address. The length wasn't explicitly sent to the controller. The
> transfer stopped when the host stopped sending/taking words for a
> specified (pretty short) amount of time. This happened when the count
> in the ACW was exhausted. The status word was also one word.

Thanks for the information (as well as the earlier bits in your message that I snipped).

< snip >

>> But disk subsystems are a different matter.
>> They existed and were used for quite some time, but I can't find anything about them.
>> Even the 1100/50 word disk stuff (DSACs?) which were an integrated word channel
>> and 5046/5056 CU just doesn't seem to exist as far as documentation goes..
>
> I know nothing about the 1100/50.
>
> Again, from memory (as I can't find my copy of the 5046 manual). Most
> External Function words (EFs) were two words long. Exceptions were
> things like Sense and Read IPL which were one word long.
>
> The first word contained the unit number (4 bits), the function (e.g.
> read/write/preseek) 6 bits (?), and (for the read and write) the
> transfer length in the low order 16(?) bits. The preseek was the same
> except instead of the length, the low order two bits gave a value about
> how much time to allow between the seek completion and the expected time
> of the disk's rotation to reach the start of the requested record.

< snip >

As luck would have, someone recently sent me a copy of the PRM for the 5056/8470 (UP-9122).
I won't mention who sent me the manual so they don't get inundated with requests for old manuals, but thanks a lot, Masked Man.
Before this, I was left with the U.S. patents for the 5057 and 5057B (4425615 and 5142627, respectively) when it came to the format of the EF words (ignoring extra words added for caching).
So at this point, I think I've got as close as I'm going to come to what I want.

Thanks to everyone out there who helped.

On 9/19/2022 1:35 PM, Lewis Cole wrote:
>> On Friday, September 16, 2022 at 10:08:43 AM UTC-7, Stephen Fuld wrote:
>>> On 9/8/2022 12:19 PM, Lewis Cole wrote:
>>>> On Wednesday, September 7, 2022 at 10:50:56 PM UTC-7, Stephen Fuld wrote:
>>>>> On 9/5/2022 7:31 PM, Lewis Cole wrote:
>
> < snip >
>>>> BTW, if you are interested in all the gory details, the 1108 Processor
>>>> and Storage Reference manual is on Bitsavers.
>>>
>>> Thanks for the pointer.
>>> I'll keep it in mind although ISTM that the 1108
>>
>> 1100/80 ?
>>
>>> was the start of the Univac/Sperry/Unisys to keep outsiders in the dark
>>> when it comes to how I/O was done.
>
> No, I meant 1108.
> While the Company seemed to try to document everything in sight in the Good Old Days (in particular in the Processor and Storage manual) in the beginning,

OK. I never looked at any manuals for systems earlier than the 1108.

> I think that changed ... I don't recall them mentioning anything about the designator bit that allowed the 1108 to address beyond 262K.

Correct, but that is because it didn't exist! The 1108 could only
address of to 262K. There was a third party company that offered to
upgrade an 1108 to 524K by making use of the bit documented as not used
in the 1108 P&S manual, but wasn't Univac,

Later, with the introduction of the 1100/10 and /20, which were
basically the 1106 and 1108 CPUs with semiconductor memory replacing the
earlier machines core memory, addressing up to 524K was supported, and
documented in the relevant manuals which are on line at bitsavers. They
used the previously unused bit, and redefined some other bits to expand
the base register fields.

At the same time as that announcement, they allowed 524K support for
1106s but not 1108s. I believe that the faster cycle time of the 1108
didn't allow time to run with the larger memories. In fact, in order
to make timing with 524K on the 1100/20, they had to slow the cycle time
to 875ns from the 1108s 750ns.

> The implications for I/O seem obvious to me.
> If you want to say that this was covered in something other than the R1 manual (UP-4052) that I happen to have and that I should RTFM, I'll accept your observation defer to your expertise.

No, you are right. The 1108 P&S manual didn't discuss that, because it
didn't exist!

>
> < snip >
>
>>> But getting back to my OP, I'm more interested in peripheral subsystems.

big snip

> As luck would have, someone recently sent me a copy of the PRM for the 5056/8470 (UP-9122).

Good. I believe the 5056 was compatible with the 5046, but it was
faster internally in order to keep up with the faster 8370 disks.

> I won't mention who sent me the manual so they don't get inundated with requests for old manuals, but thanks a lot, Masked Man.

You might consider asking bitsavers if they would scan it, so others can
access it as well.

snip

> Thanks to everyone out there who helped.

As I said before, you are most welcome! It gave me a pleasant stroll
down memory lane! :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Monday, September 19, 2022 at 11:25:44 PM UTC-7, Stephen Fuld wrote:
> On 9/19/2022 1:35 PM, Lewis Cole wrote:
> >> On Friday, September 16, 2022 at 10:08:43 AM UTC-7, Stephen Fuld wrote:
> >>> On 9/8/2022 12:19 PM, Lewis Cole wrote:
> >>>> On Wednesday, September 7, 2022 at 10:50:56 PM UTC-7, Stephen Fuld wrote:
> >>>>> On 9/5/2022 7:31 PM, Lewis Cole wrote:
> >
> > < snip >
> >>>> BTW, if you are interested in all the gory details, the 1108 Processor
> >>>> and Storage Reference manual is on Bitsavers.
> >>>
> >>> Thanks for the pointer.
> >>> I'll keep it in mind although ISTM that the 1108
> >>
> >> 1100/80 ?
> >>
> >>> was the start of the Univac/Sperry/Unisys to keep outsiders in the dark
> >>> when it comes to how I/O was done.
> >
> > No, I meant 1108.
> > While the Company seemed to try to document everything in sight in the Good Old Days (in particular in the Processor and Storage manual) in the beginning,
> OK. I never looked at any manuals for systems earlier than the 1108.
> > I think that changed ... I don't recall them mentioning anything about the designator bit that allowed the 1108 to address beyond 262K.
> Correct, but that is because it didn't exist! The 1108 could only
> address of to 262K. There was a third party company that offered to
> upgrade an 1108 to 524K by making use of the bit documented as not used
> in the 1108 P&S manual, but wasn't Univac,
>
> Later, with the introduction of the 1100/10 and /20, which were
> basically the 1106 and 1108 CPUs with semiconductor memory replacing the
> earlier machines core memory, addressing up to 524K was supported, and
> documented in the relevant manuals which are on line at bitsavers. They
> used the previously unused bit, and redefined some other bits to expand
> the base register fields.
>
> At the same time as that announcement, they allowed 524K support for
> 1106s but not 1108s. I believe that the faster cycle time of the 1108
> didn't allow time to run with the larger memories. In fact, in order
> to make timing with 524K on the 1100/20, they had to slow the cycle time
> to 875ns from the 1108s 750ns.
> > The implications for I/O seem obvious to me.
> > If you want to say that this was covered in something other than the R1 manual (UP-4052) that I happen to have and that I should RTFM, I'll accept your observation defer to your expertise.
> No, you are right. The 1108 P&S manual didn't discuss that, because it
> didn't exist!
> >
> > < snip >
> >
> >>> But getting back to my OP, I'm more interested in peripheral subsystems.
> big snip
> > As luck would have, someone recently sent me a copy of the PRM for the 5056/8470 (UP-9122).
> Good. I believe the 5056 was compatible with the 5046, but it was
> faster internally in order to keep up with the faster 8370 disks.
> > I won't mention who sent me the manual so they don't get inundated with requests for old manuals, but thanks a lot, Masked Man.
> You might consider asking bitsavers if they would scan it, so others can
> access it as well.
>
> snip
> > Thanks to everyone out there who helped.
> As I said before, you are most welcome! It gave me a pleasant stroll
> down memory lane! :-)
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Thanks for the information about the 524K addressing bit.
I didn't know that.

As for passing along the 5056/8470 manual to Bitsavers, I thought about that, but I get the impression from what I've read that they might not want it ... which I hope is not the case.

In any event, thanks again for the information.

> As for passing along the 5056/8470 manual to Bitsavers, I thought about that, but I get the impression from what I've read that they might not want it ... which I hope is not the case.

I'm interested. I still have a backlog of 110x stuff that I haven't gotten to as well

On 9/26/22 2:06 AM, Lewis Cole wrote:
> On Monday, September 19, 2022 at 11:25:44 PM UTC-7, Stephen Fuld wrote:

> As for passing along the 5056/8470 manual to Bitsavers, I thought about that, but I get the impression from what I've read that they might not want it ... which I hope is not the case.

trying again. I'm interested. I still have a bunch of scans in the backlog as well

On Monday, September 26, 2022 at 10:54:03 AM UTC-7, Al Kossow wrote:
> On 9/26/22 2:06 AM, Lewis Cole wrote:
> > On Monday, September 19, 2022 at 11:25:44 PM UTC-7, Stephen Fuld wrote:
>
> > As for passing along the 5056/8470 manual to Bitsavers, I thought about that, but I get the impression from what I've read that they might not want it ... which I hope is not the case.
> trying again. I'm interested. I still have a bunch of scans in the backlog as well

Sorry for the delay in getting back to you.
It's nice to hear that you might be interested in scanning the manual for posterity.

I looked for contact information on the Bit Savers' Website but didn't see anything obvious, so I went poking around until I found an old thread somewhere that said that the contact information was at the bottom of the Web page ... which it was not.
Looking at the CHM Web page, but nothing obvious jumped out there either (research archive and collections access?).

Care to wave your arms at the best way to pass along the manual?