<As an aside, there have been laser printer interfaces where the host
<computer gets to control the laser engine control signals directly,
<rather than talking to a 'formatter board' that turns
<text/graphics/postscript/whatever into a suitable bitmap for printing.
DEC LN03P (~1988), a video print engine. Used a bit map in the host
computer wuth serializer, there is still a small embedded micro to cotrol
the basinc mechanics. FYI: due to construction and process laser printers
have to keep the paper moving or the image will be a mess.
The most extreme was the LPS40 (DEC, 12/27/1997) that literally had a
BA23 microvax in the base to do, networking, distributed queue management,
Postscript to raster engine interpretation. It was then handed to a 4board
set (bimaps and display list to raster bitmap engine) and set serially to
the printengine. The printengine had 1 8085 to manage the system, 3 8749s
to manage the mechanics and a 78pg11 to handle the large capacity paper
input. All that was to print complex postscript pages at 40ppm. That
seems obscene but starting one piece of A4 paper every 1.5 second plus
between three and four peices in transit is not a trivial task. Then there
was the Xerox 9700 (120ppm) monster (10+running feet of laser printer.).
<Of course this is a slightly higher level than talking to the mechanics
<directly, since you have a signal to tell the printer to start a page
<rather than having to control the motor and clutches directly. But still,
<the host computer has to monitor the Beam Detect signal and send suitably
<timed pixels to the laser control input.
Beam detect is a sync signal and it's all done in hardware. You get a sync
and start DMAing data to a serializer at a preset clock rate. Not much
different than driving a tube.
<I've seen (and probably still have somewhere) plastic daisywheels with a
<metal pin for the '.' , just to make the last a little longer when used
<like this.
My first plotter was a modified daisy mech, no daisy and a pin brazed to the
solinoid. Good to 200 dpi or so.
Allison
<How big is the LPS40? Can the microvax be programmed ( :) )? BTW, do you
Roughly 30Dx 48Wx 38H.
The microvax was running a downloaded image that was the exec and postacript
interpreter. Programmable, very, as postscript has it roots in forth and
contains all of the same or similar primitives plus the printing
libraries.
<know if the Xerox machines use any kind of common computer? At school, we
Several different ones depending.
Allison
Hello,
Just a quick question; I have an old NEC 3x external SCSI CDROM, and
i'm in need of a CDROM for my VAXstation 3100. Assuming I found the
right cables, could that CDROM be used?
-paul
--
paul(a)paul.dragontear.org [a paradigm of a paramount failure]
>How big is the LPS40? Can the microvax be programmed ( :) )? BTW, do you
>know if the Xerox machines use any kind of common computer?
Many Xerox laserprinters use a J11-based (same CPU chip as PDP-11/73, 83,
84, 93, and 94) controller. Some have it on a Q-bus backplane, but
most J11-based Xerox engines that I've seen have their own custom bus.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Here's someone wanting to sell their PET 2001-32 (new style keyboard).
Please reply directly to the seller.
Reply-to: sharonklee(a)netzero.net
---------- Forwarded message ----------
Date: Sat, 22 May 1999 22:31:36 -0400
From: SLee <sharonklee(a)netzero.net>
Commodore Pet Personal computer with built in screen-- the tag on the back
says "Pet 20001-32" Come with a tape drive and a dual flopy disk drive.
Both are separate from the main unit but connected by cable. The tag on
the back of the dual floppy says "Commodore dual floppy 2040 serial number
407680"
excellent condition. protected with plastic cover
Both are in working condition
Cables are available.
Come with orginial manuals and pet magazine and game magazine
---
Sellam Alternate e-mail: dastar(a)verio.com
-------------------------------------------------------------------------------
Puttin' the smack down on the man!
Coming this October 2-3: Vintage Computer Festival 3.0!
See http://www.vintage.org/vcf for details
[Last web site update: 05/25/99]
> Two large chassis (size of old fridge) rolled into the salvage yard near
> me, labeled MassPar and one of them has 8 big, I think, MFM drives in it.
> Anybody know what this stuff is, or have interest in it? Its cheap, and
> looks intact and very good shape.
It's a massively parallel supercomputer containing thousands of four bit
processors. It's a SIMD model; i.e., the thousands of four bit processors
are all executing the same instruction simultaneously. MassPar was working
on special FORTRAN and C compilers to run the thing. It's controlled by
a Digital Ultrix workstation, either a Firefox or a DECstation 5000 depending
on its age.
Roger Ivie
ivie(a)cc.usu.edu
Yes, '81 was pretty late . . . CP/M-86 came out then, as did PC-DOS.
Within a few years, nobody wanted to be limited by the same systems they
coveted only a few years earlier. By '81, the Apple][ could be equipped
with a Z80 board, a "real" FDC (Sorrento Valley Associates ?) an 80x24
display, and a hard disk if you could afford it. I recently sold the
prototype of the original Apple HDC I made up in the spring of '81 together
with my first ST-506.
Those were the days . . . <sigh>
Today I can still run CP/M but at an effective clock rate of 83MHz on my
notebook . . . designing hardware involves thousands of lines of HDL, weeks
in front of a simulation, and when it's done, I can't even hook up an
instrument small and fast enough to inspect it because even our government
can't afford one. One has to design circuits with 25% overhead so they can
be inspected. Oh, well . . .
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 8:54 PM
Subject: Re: Re[4]: Bringing up a CPM
><If you're writing your own, it might be well to keep in mind that the BIOS
><used in several late-generation CP/M systems used device drivers which
coul
>
>It was late generation in 1981! I started doing it then. CPM had a formal
>product called CP/M+ (CP/M3.0) to extend that idea.
>
><California Computer Systems (CCS) had a pretty nice boot process in which
><they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest
memor
><in which they claimed they could run. It wrote that to the boot blocks,
>
>Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that
>you would run movcpm on to get the xxK version you wanted.
>
><then, under the control of that skeletal system, they loaded a "full-size"
><(you get to define that!) CP/M and transfer control to it. It's pretty
><solid and makes the preparation of a bootable disk a straightforward if no
><a quick process.
>
>Yes and they were doing it a long time back, Compupro too. Kaypro was one
>of the few "boxed" system that had the rom mapped to get a large TPA.
>
><IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
><mapped into the TPA during file transfers, or something on that order. If
>
>Classic.
>
><your machine can handle that, it saves on BIOS size, especially tables,
etc
><and, generally speaking, if the READ operations from the TPA are from
><temprorarily mapped-in PROMs, you can overwrite the TPA in the event you'r
><loading overlays, with complete impunity. That way your
blocking/deblockin
><buffer space can still reside in high memory.
>
>An IMSAI can neither handle that nor not handle that. The basic design
>had no rom! To do that you need a prom card with a little bit of hardware
>to map it with an IO port.
>
>The key here is to get a working system in whatever space... Why, it's the
>development platfrom for itself. Once you have it running and can poke and
>understand it the improvements will come.
>
>Allison
>
>
> -----Original Message-----
> From: Don Maslin [SMTP:donm@cts.com]
> Sent: Thursday, May 27, 1999 6:47 PM
> To: Discussion re-collecting of classic computers
> Subject: RE: What's a "computer console" selectric called?
>
> On Thu, 27 May 1999, Arlen Michaels wrote:
>
<snip>
> > Actually, the biggest challenge in interfacing this thing to a computer
> was
> > to sort out how to read one particular status signal from one of the
> > microswitch contacts in the print mechanism, so your computer could
> start
> > sending the next character at just the right moment before the
> mechanical
> > cycle completely finished. Else your software had to pause a few
>
> Didn't you also have to feed it EBCDIC instead of ASCII in order for it to
> 'understand' what you wanted printed?
>
> - don
>
<snip>
I don't think the Model 735 Selectric could even handle EBCDIC directly. I
seem to recall the electrical interface was defined as tilt-and-rotate
signal names. My Selectric terminal certainly didn't do any translation by
itself from character-codes to solenoid signals, at least not from ASCII. I
had to do translation myself before sending to the printer. One way would
have been with hardware between the computer and the Selectric, eg- using an
eprom to translate each ASCII code into the correct combination of Selectric
tilt-and-rotate signals. My lazier way was to simply put a look-up table in
my driver code, to intercept each ASCII character enroute to the printer and
translate it into the appropriate pattern of solenoid signals first.
Imagine if you had to drive a dot-matrix print head with raw pin-driver
signals instead of the printer hardware figuring it out for you : same kind
of problem.
Some vendors did indeed supply an interface that took ASCII from the
computer and sent the necessary tilt-and-rotate signals out to the
Selectric.
Arlen
--
Arlen Michaels amichael(a)nortelnetworks.com
Nortel Networks, Ottawa, Canada
I called them printing terminals. They had a keyboard, a printer and usually
a serial interface.
Besides IBM, Xerox had the 1610 Printing terminals based on the 630 printer
mechanism. There was one based on the NEC spinwriter printer. GTE had the
Termnet series of printing terminals (300 & 2120s) and of course the
venerableTI Omni 7XX series of thermal printing terminals.
If you find one of these I may have manuals.
Paxton
On May 28, 10:37, Arlen Michaels wrote:
> Subject: RE: What's a "computer console" selectric called?
> > From: Don Maslin [SMTP:donm@cts.com]
> > On Thu, 27 May 1999, Arlen Michaels wrote:
> > > Actually, the biggest challenge in interfacing this thing to a
computer
> > was
> > > to sort out how to read one particular status signal from one of the
> > > microswitch contacts in the print mechanism, so your computer could
> > start
> > > sending the next character at just the right moment before the
> > mechanical
> > > cycle completely finished. Else your software had to pause a few
> >
> > Didn't you also have to feed it EBCDIC instead of ASCII in order for it
to
> > 'understand' what you wanted printed?
> I don't think the Model 735 Selectric could even handle EBCDIC directly.
I
> seem to recall the electrical interface was defined as tilt-and-rotate
> signal names. My Selectric terminal certainly didn't do any translation
by
> itself from character-codes to solenoid signals, at least not from ASCII.
I
> had to do translation myself before sending to the printer. One way
would
> have been with hardware between the computer and the Selectric, eg- using
an
> eprom to translate each ASCII code into the correct combination of
Selectric
> tilt-and-rotate signals. My lazier way was to simply put a look-up table
in
> my driver code, to intercept each ASCII character enroute to the printer
and
> translate it into the appropriate pattern of solenoid signals first.
> Imagine if you had to drive a dot-matrix print head with raw pin-driver
> signals instead of the printer hardware figuring it out for you : same
kind
> of problem.
>
> Some vendors did indeed supply an interface that took ASCII from the
> computer and sent the necessary tilt-and-rotate signals out to the
> Selectric.
Coincidentally, last weekend I was going through old magazines from 1979,
and found a pair of articles by Roland Perry in Practical Computing (the UK
magazine, January/February 1979) describing a Selectric interface.
According to the articles, there were three types: BCD, correspondence, and
BCD-converted-to-correspondence. All of them use tilt-and-rotate codes,
which vary according to the golfball type (BCD or correspondence) and the
keyboards differ as do the golfballs. The interface was pretty simple (8
SSI TTL ICs, 14 driver transistors) but the contacts had to be re-wired to
suit the terminal version. The driver code used a lookup table to convert
ASCII to interface signals, sent 8-bit-parallel from an I/O port on an
8080, with two handshake lines.
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
