test-drb May 1999

test-drb@ccmp.vtda.org

174 participants
659 discussions

What's a "computer console" selectric called?

by allisonp＠world.std.com

<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

25 years, 6 months

What's a "computer console" selectric called?

by allisonp＠world.std.com

<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

25 years, 6 months

More of my annoying VAXstation 3100 questions

by paul＠paul.dragontear.org

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]

25 years, 6 months

What's a "computer console" selectric called?

by CLASSICCMP＠trailing-edge.com

>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

25 years, 6 months

PET 2001-32 available

by siconic＠jasmine.psyber.com

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]

25 years, 6 months

Whats a MassPar?

by IVIE＠cc.usu.edu

> 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

25 years, 6 months

Bringing up a CPM

by edick＠idcomm.com

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 > >

25 years, 6 months

What's a "computer console" selectric called?

by amichael＠nortelnetworks.com

> -----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

25 years, 6 months

What's a "computer console" selectric called?

by Innfogra＠aol.com

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

25 years, 6 months

What's a "computer console" selectric called?

by pete＠dunnington.u-net.com

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

25 years, 6 months

← Newer
1
...
4
5
6
7
8
9
10
...
66
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb May 1999