Not really UNIX -- so I'm BCC TUHS and moving to COFF
On Tue, Jan 9, 2024 at 12:19 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
> On the subject of troff origins, in a world where troff didn't exist, and
> one purchases a C/A/T, what was the general approach to actually using the
> thing? Was there some sort of datasheet the vendor supplied that the end
> user would have to program a driver around, or was there any sort of
> example code or other materials provided to give folks a leg up on using
> their new, expensive instrument? Did they have any "packaged bundles" for
> users of prominent systems such as 360/370 OSs or say one of the DEC OSs?
>
Basically, the phototypesetter part was turnkey with a built-in
minicomputer with a paper tape unit, later a micro and a floppy disk as a
cost reduction. The preparation for the typesetter was often done
independently, but often the vendor offered some system to prepare the PPT
or Floppy. Different typesetter vendors targeted different parts of the
market, from small local independent newspapers (such as the one my sister
and her husband owned and ran in North Andover MA for many years), to
systems that Globe or the Times might. Similarly, books and magazines
might have different systems (IIRC the APS-5 was originally targeted for
large book publishers). This was all referred to as the 'pre-press'
industry and there were lots of players in different parts.
Large firms that produced documentation, such as DEC, AT&T *et al*., and
even some universities, might own their own gear, or they might send it out
to be set.
The software varied greatly, depending on the target customer. For
instance, by the early 80s, the Boston Globe's input system was still
terrible - even though the computers had gotten better. I had a couple of
friends working there, and they used to b*tch about it. But big newspapers
(and I expect many other large publishers) were often heavy union shops on
the back end (layout and presses), so the editors just wanted to set strips
of "column wide" text as the layout was manual. I've forgotten the name of
the vendor of the typesetter they used, but it was one of the larger firms
-- IIRC, it had a DG Nova in it. My sister used CompuGraphic Gear, which
was based on 8085's. She had two custom editing stations and the
typesetter itself (it sucked). The whole system was under $35K in
late-1970s money - but targeted to small newspapers like hers. In the
mid-1908s, I got her a Masscomp at a reduced price and put 6 Wyse-75
terminals on it, so she could have her folks edit their stories with vi,
run spell, and some of the other UNIX tools. I then reverse-engineered the
floppy enough to split out the format she wanted for her stories -- she
used a manual layout scheme. She still has to use the custom stuff for
headlines and some other parts, but it was a load faster and more parallel
(for instance, we wrote an awk script to generate the School Lunch menus,
which they published each week).
ᐧ
[TUHS bcc, moved to COFF]
On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling <kevin.bowling(a)kev009.com> wrote:
> For whatever reason, intel makes it difficult to impossible to remove
> the ME in later generations.
Part of me wonders if the general computing industry is starting to cheat off of the smartphone sector's homework, this phenomenon where whole critical components of a hardware device you literally own are still heavily controlled and provisioned by the vendor unless you do a whole bunch of tinkering to break through their stuff and "root" your device. That I can fully pay for and own a "computer" and I am not granted full root control over that device is one of the key things that keeps "smart" devices besides my work issued mobile at arms length.
For me this smells of the same stuff, they've gotten outside of the lane of *essential to function* design decisions and instead have now put in a "feature" that you are only guaranteed to opt out of by purchasing an entirely different product. In other words, the only guaranteed recourse if a CPU has something like this going on is to not use that CPU, rather than as the device owner having leeway to do what you want. Depends on the vendor really, some give more control than others, but IMO there is only one level of control you give to someone who has bought and paid for a complete device: unlimited. Anything else suggests they do not own the device, it is a permanently leased product that just stops requiring payments after a while, but if I don't get the keys, I don't consider myself to own it, I'm just borrowing it, kinda like how the Bell System used to own your telephone no matter how many decades it had been sitting on your desk.
My two cents, much of this can also be said of BIOS, UEFI, anything else that gets between you and the CPUs reset vector. Is it a nice option to have some vendor provided blob to do your DRAM training, possibly transition out of real mode, enumerate devices, whatever. Absolutely, but it's nice as an *option* that can be turned off should I want to study and commit to doing those things myself. I fear we are approaching an age where the only way you get reset vector is by breadboarding your own thing. I get wanting to protect users from say bricking the most basic firmware on a board, but if I want to risk that, I should be completely free to do so on a device I've fully paid for. For me the key point of contention is choice and consent. I'm fine having this as a selectable option. I'm not fine with it becoming an endemic "requirement." Are we there yet? Can't say, I don't run anything serious on x86-family stuff, not that ARM and RISC-V don't also have weird stuff like this going on. SBI and all that are their own wonderful kettle of fish.
BTW sorry that's pretty rambly, the lack of intimate user control over especially smart devices these days is one of the pillars of my gripes with modern tech. Only time will tell how this plays out. Unfortunately the general public just isn't educated enough (by design, not their own fault) on their rights to really get a big push on a societal scale to change this. People just want I push button I get Netflix, they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new...
- Matt G.
Hello, I wanted to share this evening a scan I just finished. It is linked to in this thread where I will continue adding ESS-related materials (for those interested in that sort of thing):
http://www.classicrotaryphones.com/forum/index.php?topic=28001.0
The document therein is the Guide to Stored Program Control Switching, a Bell System document concerning #1 and #2 ESS telephone exchanges and varieties of networking connections. It's interesting in that the guide is three separate little flip decks of cards, some of which can represent steps in a network. Flip to the components you need and the traces at the edges meet to create a diagram of that particular configuration. I quite like the concept, seems like a great way to visualize variable networks.
Anywho, as mentioned I'm going to be putting some more ESS stuff up there, mostly related to 5ESS and 3B20 computers. That seems to now squarely be my main documentation focus since I'm starting to bleed the Bell System UNIX well a bit dry of stuff I can randomly find on eBay. 5ESS and 3B20 are still adjacent enough that I'm sure UNIX-y things will be scattered throughout this material.
Finally, a long shot but is anyone aware of preserved copies (or in possession of) the March 1980 issue of the Bell Laboratories Record? An index on archive.org indicates that issue has a focus piece on the 3B20 which I am quite interested in getting eyes on. I've come across several other copies around this time frame, some of which I've purchased to scan, but not this one yet.
As always happy to answer any questions about what I'm working on or consider scanning jobs for other documentation folks have leads on, happy new year everyone!
- Matt G.
[TUHS as Bcc]
I just saw sad news from Bertrand Meyer. Apparently, Niklaus Wirth
passed away on the 1st. :-(
I think it's fair to say that it is nearly impossible to overstate his
influence on modern programming.
- Dan C.
Dyslexia sucks... sorry, if it was not obvious, please globally substitute
s:STOP/STOP:START/STOP:
ᐧ
On Sun, Dec 31, 2023 at 2:30 PM Clement T Cole via groups.io <clemc=
ccc.com(a)groups.io> wrote:
> Small PS below...
>
> On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io <clemc=
> ccc.com(a)groups.io> wrote:
>
>>
>> I did not say that or imply it. But variable vs. fixed blocking has
>> implications on both mechanical requirements and ends up being reflected in
>> how the sw handles it. Traditional 9-track allows you to mix record sizes
>> on each tape. Streamer formats don’t traditionally allow that because they
>> restrict / remove inter record gaps in the same manner 9-track supports.
>> This increases capacity of the tape (less waste).
>>
>
> In my explanation, I may have been a tad confusing. When I say fixed
> records -- I mean on-tape fixed records, what the QIC-24/120/150 standard
> refers to as: "*A group of consecutive bits comprising of a preamble,
> data block marker, a single data block, block address and CRC and postamble*"
> [the standard previous defines a data black os 512 consecutive bytes] --*
> i.e*., if you put an o'scope on the tape head and looked at the bit
> stream (see page 16 of QIC-120 Rev F - Section 5 "Recorded Block" for a
> picture of this format -- note is can only address 2^20 blocks per track,
> but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that
> means 15728640 unique 512-byte blocks).
>
> STOP/STOP does something similar but encodes the LRECL used [I don't have
> the ANSI tape standard handy - but I remember seeing a wonderful picture of
> all this from said documents when I first was educated about tapes in my
> old IBM days ~50 years ago]. After each record, STOP/STOP needs an
> "Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time
> before continuing the bit stream of the next data block. The IRC distance
> is something like 5-10 mm [which is a great deal compared to the size of a
> bit when using GCR encoding (which is what 6250 BPI and QIC both use).
> These gaps take space (capacity) from the tape, so people tend to write
> with larger blocking factors [UNIX traditionally uses 10240 bytes- other
> systems use other values - as I said, I believe the standard says the max
> is 64K bytes).
>
> Since streamers (like QIC tape) are supposed to be continuous, the QIC
> inter-records gaps resemble fixed disk records and can be extremely small.
> Remember, each bit is measured in micrometers -- about *2 micrometers*,
> IIRC for QIC and around 10 for ½" formats -- again, and I would need to
> check the ANSI spec, which is not handy. But this is a huge space savings
> even with a smallish block (512) -- again - this was lifted from disk
> technology of the day which had often standardized on 512 8-bit byte blocks
> by then.
>
> BTW: this is again why I suspect a TK25 tape is not going to be able to
> read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual
> says it supports four different block sizes [1K/2K/4K/8K]. First, the
> data block format would have to be variable to 4 sizes, and second, the
> preamble would need to encode and write what size block to expect on
> read. Unfortunately, that document does not say much more about the
> physical tape format other than it can use cartridges "similar to ANSI
> Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11
> tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using
> a "single track NRZI dat in a serpentine pattern, with 4-5 run length
> limited code similar to GCR."
>
> That said, most modern SW will allow you to *write* different size record
> sizes (LRECL) in the user software, but the QIC drives and I believe things
> like DAT and Exabyte will only write 512-byte blocks, so somewhere between
> your user program and tape itself, the write will be broken into N 512 byte
> blocks and then pad (with null is typical) the last block to 512 bytes.
> My memory is the QIC standard is silent on where that is done, but I
> suspect it's done in the controller and the driver is forced to send it
> 512-byte blocks.
>
> So, while you may define blocks of different sizes, unlike ½", it will
> always be written as 512-byte blocks.
>
> That said, using larger record sizes in your application SW can have huge
> performance wins (which I mentioned in my first message) - *e.g.*,
> keeping the drive streaming as more user data has been locked down in
> memory for a DMA. But by the time the driver and the controller are
> finished, it's fixed 512-byte blocks on the tape.
>
>
> One other thing is WRT to QIC, which differs from other schemes. I
> previously mentioned tape files - a feature of the ½" physical tape formats
> not typically supported for QIC tapes. QIC has an interesting feature that
> allows a block to be rewritten and replaced later on the tape (see the
> section of spec/you user manual WRT for "rewritten" or "replacement
> "blocks). I've forgotten all the details, but I seem to remember that
> features were why multiple tape files were difficult to implement.
> Someone who knows more about tapes may remember the details/be able to
> explain -- I remember dealing with tape files was a PITA in QIC, and the
> logic in a standard ½" tape driver could not be just cloned for the QIC
> driver.
> ᐧ
> ᐧ
> ᐧ
> _._,_._,_
> ------------------------------
> Groups.io Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#3631) <https://groups.io/g/simh/message/3631> | Reply
> To Group
> <simh@groups.io?subject=Re:%20Re%3A%20%5Bsimh%5D%20Old%20VAX%2FVMS%20Tapes>
> | Reply To Sender
> <clemc@ccc.com?subject=Private:%20Re:%20Re%3A%20%5Bsimh%5D%20Old%20VAX%2FVMS%20Tapes>
> | Mute This Topic <https://groups.io/mt/103433309/4811590> | New Topic
> <https://groups.io/g/simh/post>
> Your Subscription <https://groups.io/g/simh/editsub/4811590> | Contact
> Group Owner <simh+owner(a)groups.io> | Unsubscribe
> <https://groups.io/g/simh/leave/8620764/4811590/1680534689/xyzzy> [
> clemc(a)ccc.com]
> _._,_._,_
>
>
Small PS below...
On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io <clemc=
ccc.com(a)groups.io> wrote:
>
> I did not say that or imply it. But variable vs. fixed blocking has
> implications on both mechanical requirements and ends up being reflected in
> how the sw handles it. Traditional 9-track allows you to mix record sizes
> on each tape. Streamer formats don’t traditionally allow that because they
> restrict / remove inter record gaps in the same manner 9-track supports.
> This increases capacity of the tape (less waste).
>
In my explanation, I may have been a tad confusing. When I say fixed
records -- I mean on-tape fixed records, what the QIC-24/120/150 standard
refers to as: "*A group of consecutive bits comprising of a preamble, data
block marker, a single data block, block address and CRC and postamble*"
[the standard previous defines a data black os 512 consecutive bytes] --*
i.e*., if you put an o'scope on the tape head and looked at the bit
stream (see page 16 of QIC-120 Rev F - Section 5 "Recorded Block" for a
picture of this format -- note is can only address 2^20 blocks per track,
but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that
means 15728640 unique 512-byte blocks).
STOP/STOP does something similar but encodes the LRECL used [I don't have
the ANSI tape standard handy - but I remember seeing a wonderful picture of
all this from said documents when I first was educated about tapes in my
old IBM days ~50 years ago]. After each record, STOP/STOP needs an
"Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time
before continuing the bit stream of the next data block. The IRC distance
is something like 5-10 mm [which is a great deal compared to the size of a
bit when using GCR encoding (which is what 6250 BPI and QIC both use).
These gaps take space (capacity) from the tape, so people tend to write
with larger blocking factors [UNIX traditionally uses 10240 bytes- other
systems use other values - as I said, I believe the standard says the max
is 64K bytes).
Since streamers (like QIC tape) are supposed to be continuous, the QIC
inter-records gaps resemble fixed disk records and can be extremely small.
Remember, each bit is measured in micrometers -- about *2 micrometers*,
IIRC for QIC and around 10 for ½" formats -- again, and I would need to
check the ANSI spec, which is not handy. But this is a huge space savings
even with a smallish block (512) -- again - this was lifted from disk
technology of the day which had often standardized on 512 8-bit byte blocks
by then.
BTW: this is again why I suspect a TK25 tape is not going to be able to
read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual
says it supports four different block sizes [1K/2K/4K/8K]. First, the
data block format would have to be variable to 4 sizes, and second, the
preamble would need to encode and write what size block to expect on
read. Unfortunately, that document does not say much more about the
physical tape format other than it can use cartridges "similar to ANSI
Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11
tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using
a "single track NRZI dat in a serpentine pattern, with 4-5 run length
limited code similar to GCR."
That said, most modern SW will allow you to *write* different size record
sizes (LRECL) in the user software, but the QIC drives and I believe things
like DAT and Exabyte will only write 512-byte blocks, so somewhere between
your user program and tape itself, the write will be broken into N 512 byte
blocks and then pad (with null is typical) the last block to 512 bytes.
My memory is the QIC standard is silent on where that is done, but I
suspect it's done in the controller and the driver is forced to send it
512-byte blocks.
So, while you may define blocks of different sizes, unlike ½", it will
always be written as 512-byte blocks.
That said, using larger record sizes in your application SW can have huge
performance wins (which I mentioned in my first message) - *e.g.*, keeping
the drive streaming as more user data has been locked down in memory for a
DMA. But by the time the driver and the controller are finished, it's fixed
512-byte blocks on the tape.
One other thing is WRT to QIC, which differs from other schemes. I
previously mentioned tape files - a feature of the ½" physical tape formats
not typically supported for QIC tapes. QIC has an interesting feature that
allows a block to be rewritten and replaced later on the tape (see the
section of spec/you user manual WRT for "rewritten" or "replacement
"blocks). I've forgotten all the details, but I seem to remember that
features were why multiple tape files were difficult to implement.
Someone who knows more about tapes may remember the details/be able to
explain -- I remember dealing with tape files was a PITA in QIC, and the
logic in a standard ½" tape driver could not be just cloned for the QIC
driver.
ᐧ
ᐧ
ᐧ
> From: Derek Fawcus
> How early does that have to be? MP/M-1.0 (1979 spec) mentions this, as
> "Resident System Processes" ... It was a banked switching, multiuser,
> multitasking system for a Z80/8080.
Anything with a microprocessor is, by definition, late! :-)
I'm impressed, in retrospect, with how quickly the world went from proceesors
built with transistors, through proceesors built out discrete ICs, to
microprocessors. To give an example; the first DEC machine with an IC
processor was the -11/20, in 1970 (the KI10 was 1972); starting with the
LSI-11, in 1975, DEC started using microprocessors; the last PDP-11 with a
CPU made out of of discrete ICs was the -11/44, in 1979. All -11's produced
after that used microprocessors.
So just 10 years... Wow.
Noel
We should move to COFF (cc’ed) for any further discussion. This is way off
topic for simh.
Below
Sent from a handheld expect more typos than usual
On Sat, Dec 30, 2023 at 7:59 PM Nigel Johnson MIEEE via groups.io
<nw.johnson=ieee.org(a)groups.io> wrote:
> First of all, 7-track vs 9-yrack - when you are streaming in serpentine
> mode, it is whatever you can fit into the tape width having regard to the
> limitations of the stepper motor accuracy.
>
Agreed. It’s the physical size of head and encoding magnetics. Parallel
you have n heads together all reading or writing together into n analog
circuits. A rake across the ground if you will. Serial of course its
like a single pencil line with the head on a servo starting in the center
of the tape and when you hit the physical eot move it up or down as
appropriate.
It is nothing to do with the number of bits per data unit.
>
I did not say that or imply it. But variable vs. fixed blocking has
implications on both mechanical requirements and ends up being reflected in
how the sw handles it. Traditional 9-track allows you to mix record sizes
on each tape. Streamer formats don’t traditionally allow that because they
restrict / remove inter record gaps in the same manner 9-track supports.
This increases capacity of the tape (less waste).
Just for comparison at 6250 BPI a traditional 2400’ ½” tape writing fixed
blocks of 10240 8-bit bytes gets about 150Mbytes. A ¼” DC-6150 tape using
QIC-150 only one forth the length and half as wide gets the same capacity
and they both use the same core scheme to encode the bits. QIC writes
smaller bits and wastes less tape with IRCs.
That all said, Looking at the TK25 specs besides being 11 tracks it is also
supports a small number different block sizes (LRECL) - unlike QIC.
Nothing like 9-track which can handle a large range of LRECLs. What I
don’t see in the TK25 is if you can mix them on a tape or if that is coded
once for each tape as opposed in each record.
Btw while I don’t think ansi condones it, some 9-track units like the
Storage Tek ones could not only write different LRECLs but could write
using different encoding (densities) on the same medium. This sad trick
confused many drives when you moved the tape to a drive that could not. I
have some interesting customer stories living those issues. But I digress …
FWIW As I said before do have a lot of experience with what it takes to
support this stuff and what you have to do decode it, the drivers for same
et al. I never considered myself a tape expert- there are many the know
way more than I - but I have lived, experienced and had to support a number
of these systems and have learned the hard way about how these schemes can
go south when trying to recover data.
Back in the beginning of my career, we had Uniservo VIC drives which were
> actually 7-bit parallel! (256, 556, and 800 bpi! NRZI
>
Yep same here. ½” was 5, 7 and 9 bits in parallel originally. GE-635 has
in the late 1960s then and a IBM shop in the early 70s. And of course saw
my favorite tapes of all - original DEC tape. I’ve also watched things
change with serial and the use of serpentine encoding.
You might find it amusing — any early 1980s Masscomp machines had a special
½” drive that had a huge number serpentine tracks I’ve forgotten the exact
amount. They used traditional 1/2” spools from 3M and the like but r/w was
custom to the drive. I’ve forgotten the capacity but at the time it was
huge. What I remember it was much higher capacity and reliability than
exabyte which at the time was the capacity leader. The USAF AWACS planes
had 2 plus a spare talking to the /700 systems doing the I/O - they were
suckling up everything in the air and recording it as digital signals. The
tape units were Used to record all that data. An airman spends his/whole
time loading and unloading tapes. Very cool system.
> Some things about the 92192 drive: it was 8" cabinet format in a 5.25
> inch world so needed an external box. It also had an annoying habit, given
> Control Data's proclivity for perfection, that when you put a cartridge in,
> it ran it back and forth for five minutes before coming ready to ensure
> even tension on the tape!
>
> The formatter-host adapter bus was not QIC36, so Emulex had to make a
> special controller, the TC05, to handle the CDC Proprietary format. The
> standard was QIC-36, although I think that Tandberg had a standard of their
> own.
>
Very likely. When thoses all came on the scene there were a number of
interfaces and encoding schemes. I was not involved in any of the politics
but QIC ended up as the encoding standard and SCSI the interface
IIRC the first QIC both Masscomp and Apollo used was QIC-36 via a SCSI
converter board SCS made for both of us. I don’t think Sun used it. Later
Archive and I think Wangtek made SCSI interface standard on the drives.
> I was wrong about the 9-track versus 7, the TC05/sentinel combination
> writes 11 tracks! The standard 1/4' cartridge media use QIC24, which
> specifies 9 tracks. I just knew it was not 9!
>
It also means it was not a QIC standard as I don’t believe they had one
between QIC-24-DC and QIC-120-DC. Which I would think means that if this
tape came from a TK25 I doubt either Steve or my drives will read it -
he’ll need to find someone with a TK25 - which I have never seen
personally.
> That's all I know!
>
fair enough
Clem_._,_._,_
>
I've got an exciting piece of hardware to pair with the VT100 I recently got, a Western Electric Dataphone 300. The various status lights and tests seem to work, and the necessary cabling is in place as far as the unit is concerned. However, it did not come with the accompanying telephone. I believe but can't verify yet that the expected telephone is or resembles a *565HK(M) series telephone, the ones with one red and five clear buttons along the bottom, otherwise resembling a standard WECo telephone.
Pictured: http://www.classicrotaryphones.com/forum/index.php?action=dlattach;attach=4…
Thus far I've found myself confused on the wiring expectations. There is a power line going into a small DC brick, one DB-25 port on the back terminating in a female 25-pair amphenol cable, and another DB-25 port with a ribbon extension plugged in. My assumptions thus far have been the amphenol plugs into a *565HK(M) or similar series telephone and the DB-25 then plugs into the serial interface of whichever end of the connection it represents. However, while this is all fine and dandy, it's missing one important part...a connection to the outside world. I've found no documentation describing this yet, although a few pictures from auctions that included a telephone seemed to have a standard telephone cable also coming out of the back of the telephone terminating in either a 6 or 8-conductor modular plug. The pictures were too low-res to tell which.
Would anyone happen to know anything concrete about the wiring situation with these, or some documentation hints, as I've tried some general web searches for documentation concerning Dataphone 300 and the 103J Data Set configuration and haven't turned up wiring-specific information. If nothing else I might just tap different places on the network block of the 2565HKM I've got plugged into it and see if anything resembling a telephone signal pops up when running some serial noise in at an appropriate baud. My fear is that the wiring differences extend beyond the tap to the CO/PBX line and that there are different wiring expectations in the 25-pair as well, this and my other appropriate telephone are both 1A2 wired I believe, still working on that KSU...
Any help is much appreciated, lotsa little details in these sorts of things, but once I get it working I intend to do some documentation and teardown photos. I don't want to take it apart yet and run the risk of doing something irreversible. I want to make sure it gets a chance to serve up some serial chit chat as weird telephone noises.
- Matt G.
FYI: Tim was Mr. 36-bit kernel and I/O system until he moved to the Vax and
later Alpha (and Intel).
The CMU device he refers is was the XGP and was a Xerox long-distance fax
(LDX). Stanford and MIT would get them too, shortly thereafter.
---------- Forwarded message ---------
From: Timothe Litt
Date: Thu, Dec 21, 2023 at 1:52 PM
Subject: Re: Fwd: [COFF] IBM 1403 line printer on DEC computers?
To: Clem Cole
I don't recall ever seeing a 1403 on a DECsystem-10 or DECSYSTEM-20. I
suppose someone could have connected one to a systems concepts channel...
or the DX20 Massbus -> IBM MUX/SEL channel used for the STC (TU70/1/2)
tape and disk (RP20=STC 8650) disk drives. (A KMC11-based device.) Not
sure why anyone would.
Most of the DEC printers on the -10/20 were Dataproducts buy-outs, and were
quite competent. 1,000 - 1,250 LPM. Earlier, we also bought from MDS and
Analex; good performance (1,000LPM), but needed more TLC from FS. The
majority were drum printers; the LP25 was a band printer, and lighter duty
(~300LPM).
Traditionally, we had long-line interfaces to allow all the dust and mess
to be located outside the machine room. Despite filters, dust doesn't go
well with removable disk packs. ANF-10 (and eventually DECnet) remote
stations provided distributed printing.
CMU had a custom interface to some XeroX printer - that begat Scribe.
The LN01 brought laser printing - light duty, but was nice for those
endless status reports and presentations. I think the guts were Canon -
but in any case a Japanese buyout. Postscript. Networked.
For high volume printing internally, we used XeroX laser printers when they
became available. Not what you'd think of today - these are huge,
high-volume devices. Bigger than the commercial copiers you'd see in print
shops. I(Perhaps interestingly, internally they used PDP-11s running
11M.) Networked, not direct attach. They also were popular in IBM shops.
We eventually released the software to drive them (DQS) as part of GALAXY.
The TU7x were solid drives - enough so that the SDC used them for making
distribution tapes. The copy software managed to keep 8 drives spinning at
125/200 ips - which was non-trivial on TOPS-20.
The DX20/TX0{2,3}/TU7x *was *eventually made available for VAX - IIRC as
part of the "Migration" strategy to keep customers when the -10/20 were
killed. I think CSS did the work on that for the LCG PL. Tapes only - I
don't think anyone wanted the disks by them - we had cheaper dual-porting
via the HSC/CI, and larger disks.
The biggest issue for printers on VAX was the omission of VFU support.
Kinda hard to print paychecks and custom forms without it - especially if
you're porting COBOL from the other 3-letter company. Technically, the
(Unibuas) LP20 could have been used, but wasn't. CSS eventually solved
that with some prodding from Aquarius - I pushed that among other high-end
I/O requirements.
On 21-Dec-23 12:29, Clem Cole wrote:
Tim - care to take a stab at this?
ᐧ
