A buddy of mine came through today with some stuff he'd been talking about
for months. In exchange for a place-mat-sized fan-folded UNIX "pocket guide"
>from 1984, he gave me a 360 reference card (IBM p/n X20-1703-4) and another
artifact that I'd only ever _heard_ of before - a data cell (i.e., a noodle
>from an IBM noodle picker/stuffer). It's much larger than I anticipated -
over 2" x 12".
Between the reference card and the textbook I have (Saxon, Englander and
Englander, "System 360 Programming, A Self-Instructional Manual", Prentice-
Hall, Inc, 1968) I'm almost ready to try out that 360 emulator.
-ethan
=====
Infinet has been sold. The domain is going away in February.
Please send all replies to
erd(a)iname.com
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com
Quite true, Hans. The Intel effort to push the industry ahead fell with
this chipset fell flat because software vendors were not willing to
re-architect their existing constructs in order to capitalize on the
advantages a hierarchical structure for the I/O subsystem would provide.
Software simply never evolved to the point at which it fully exploited the
hardware. The degeneration of the initial architecture into what it now is
rather than the more highly abstracted (and more highly evolved) construct
that was presented by the hardware was caused by software vendors' inability
to organize themselves around a unified construct.
Dick
-----Original Message-----
From: Hans Franke <Hans.Franke(a)mch20.sbs.de>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, December 31, 1999 7:48 AM
Subject: Re: 8089 was Re: Hyperion Passport, Apricot, Convergent
Technologies workSlate,
>> >a strange machine -- one of the few MS-DOS boxes to use an 8089 I/O
>> >coprocessor (which I why I got interested in it -- nice chip).
>
>> Hi Tony, I have an 8089 in a CPM machine but I haven't been able to
find
>> out much about that chip. What can you tell me about it?
>
>The 8089 is the supposed I/O Processor for 8086/88 systems.
>Like the 8087 it can be used in an 8 or 16 bit bus system.
>
>Basicly Intel did go for a structure like a /370 alike mainframe.
>A CPU (8086 or 8088), an IOC (8089) and a math extension to the
>CPU (FPU, 8087). Due the nature of the 86 Bus the 8087 did become
>a bit more independant than a /370 math extension. Basicly the
>8086 is designed as ordinary CPU, while the 8089 is optimized for
>I/O - you may call it a super DMA chip, but thats like calling
>a versitale VW Bus a shoping cart. From a system softwares view
>point you may assign the low level I/O drivers to be run on the
>8089, while the 8086 executes the high level functions. For a
>a Disk drive this may give you an SCSI like interface between
>these components - the 8086 supports a control block with (logical)
>drive ID, and block number, while the 8089 translates this to
>controller address, drive number and head/track/sector number
>to programm the FD chips and then initiate the DMA transfer.
>
>For a serial line, this may include low level block drivers
>for packing/unpacking and CRC and block repeat to handle the
>complete transmission of a given data (chunk).
>
>Especialy in a multi tasking environment this gives an enormus
>boost in available processing power. Not to mention the simplified
>OS design. As a standard IOC, the 89 also overcomes the driver
>problems that you get if every I/O has his own, different
>'intelligent' controller.
>
>Well, I guess there may have been some applications, but I doubt
>if this has ever used the full potential of the 86/89 combination.
>The design did realy borrow a lot of good mainframe ideas. Just to
>early ?
>
>Gruss
>H.
>
>
>--
>Der Kopf ist auch nur ein Auswuchs wie der kleine Zeh.
>H.Achternbusch
>From: "Paul Braun" <nerdware(a)laidbak.com>
>It just fascinates me that there are so many of you who run these
>beasts and I'd just like to know why.
It's common for people to laugh at the old minis, but the thing is,
back when they first came out everyone thought they were *wicked* cool.
And what's changed? Unless you've gotten seriously behind on maintenance,
they haven't gotten any worse just because the rest of the computing world
has moved ahead (sort of). They're as great as they ever were.
Also, everything that's been done over the last 30 years will all be seen
as totally obsolete 10 years from now, including the seemingly flashy stuff
that's being done right now. The idea of immediately adopting every steaming
pile of new software laid by Bill Gates, just to keep up, doesn't appeal to a
lot of people. So if you're going to pick something to stick with for as long
as possible, why not pick the last system that you were actually *glad* to use?
Then there's the issue of forward compatibility. 5 years ago MS-DOS was
still pretty entrenched, but now it's as if it never existed. There are
supposed DOS compatibility boxes in the newer OSes but they never seem to be
able to run the one program you really care about. I'm sure this will repeat
itself with native Windows etc. applications, and UNIX has always been a moving
target, so if you write your software for one of those systems you'll probably
have to revisit it (and maybe totally rewrite it) every couple of years for
the rest of your life. Even if the OSes don't grow huge incompatibilities
(which they will), the C language itself is long overdue for fading away.
And the real trouble starts when your favorite language falls out of favor --
try to find an Algol compiler nowadays!
But, I assure you that 15 years from now I'll still have some way to run all
of my RT-11 MACRO-11 code unchanged. Just like it's already possible to run
all my stuff from 15 years ago unchanged. New PDP-11 clone CPUs are still
coming out even now (which means they'll depreciate to hobbyist price levels
in a few years), and of course emulators make your code live even longer
(but maybe I'm biased!). The PDP-11 environment is a lot better suited to
being emulated than PCs are, so even though there might be a way to keep
current versions of Windows awake on future non-80x86 CPUs, I still prefer
to write PDP-11 code when it's something I want to bring with me onto future
machines.
John Wilson
D Bit
I am at the plateau of learning how to configure modules for
inclusion into a Unibus PDP11/44 system... and I'm having trouble
getting off the dime understanding the algoithms involved.
I think I've a pretty good handle on how the grant chain works,
and of course I think I understand the concept of hardware
addressing and interrupt hierarchies and servicing. I just am
having trouble applying my limited knowledge to specific DEC hardware.
Por ejemplo: I dredged the M8256/RX211 out of my 11/34, with the
object of hanging an RX02 on the 11/44. I have a DD11-CK (four slot)
backplane with one slot (4) available. I pulled the grant card, cut
the NPR jumper, and installed the M8256 in the slot. I checked
everything out electromechanically, all seems good: cables in the
right way up, RX02 on and running, all ok.
On boot, the system came up normally until I typed $dir DY0: and
there was a mighty explosion, bits bytes and words rained down on me
and I blew the machine back into ODT. Thence, it refused to boot
again, returning me to the >>> every time, even after I powered it
down and back up again. [ >>> b db0 ]
I then removed the M8256, restored the jumper and grant card, and
all is now well. (....Whhheeewwww...!!!!) I had visions of
irreparable damage and weeks of work and severe depression...
So I assume that the various settings on the RX211 conflict with
the rest of the system. Having the documentation [PDP-11/44 System
User's Guide and the RX02 Floppy Disk System User's Guide] what
process must I accomplish to properly configure the Module so it
'plays well with others'?
A Very Happy New Year to those whose Year is imanently New; and to
everyone else anyway, on the grounds that we all like good wishes.
Cheers
John
OK, I have been thoroughly chastised for my choice of "big iron" to
describe the minis. I know better, and this is proof that one
shouldn't post stuff real late at night.
I appreciate all the discussion. By no means did I mean to imply
that old equals obsolete -- I still use a 20-something HP-35
calculator that does the basic 4 fns plus scientific stuff just as well
as today's little marvels, plus it has the added advantages of being
built like a tank and using RPN. I've used RPN since I was in high
school in the mid-70's and learned early on that it is great for
preventing people from borrowing your calculator. All they have to
do is ask "where's the 'equals' key?" and when you reply "there
isn't one", they stare at you funny and go away.
I'm surprised that most of you do use them for day-to-day tasks. I
guess in my mind I just envisioned most minis in business settings
running business apps -- my exposure to the larger side of
computing has been somewhat limited. The most actual usage I
got was programming FORTRAN IV on a DECWriter connected to
the HP3000 at school. I guess it boils down to "if you know how to
run it, and it does what you need, then it's the right machine for the
job"
I shouldn't be that surprised, I guess, because that's usually the
advice I give people who ask me about dumping a boatload of cash
because the folks at Intel have promised them that the latest whiz-
bang tricked-out PIII box will dance and sing, do the dishes, and
make their 28.8 dialup connection into a screaming multimedia
wonderland. I usually ask, "does your current pc do what you need
it to?" to which the reply is almost always, "Yes."
Then I tell them to save their money and get something better when
the current box dies.
Or I tell them to get a Mac. But that's a different thread for a
different group.
I would like to have a PDP at some point and learn how to use it,
but the pc collection is currently pushing the limits of marital
tolerance, and then I and my computers would have to find a new
place to sleep...........
We now return you to the list, already in progress.
Paul Braun
NerdWare -- The History of the PC and the Nerds who brought it to you.
nerdware(a)laidbak.com
www.laidbak.com/nerdware
Hey all...I am new to this classic computer collecting, but I have been
buying and reselling systems for a few months now. Anyway, I recently
acquired a Hyperion Passport (or is it a Passport Hyperion?), an Apricot, a
workSlate, and some drives, and other stuff (diskettes, or things) that say
Amdek on them. I am just looking on any information I can find on these! I
am attempting to put a value on them, and am trying to decide which to keep,
if any....I am running out of room it seems :-)
Any help would be appreciated!
Sincerely,
Mark Saarinen
<Well, I guess there may have been some applications, but I doubt
<if this has ever used the full potential of the 86/89 combination.
<The design did realy borrow a lot of good mainframe ideas. Just to
<early ?
DEC LN01 used an 8086 and 8089 for the RIP (raster image processor).
The 8089 did the parallel IO to the host (Dataproducts interface)
and the band buffer to video serializer (7+ Mbits/sec). The band buffer
depending on mode was either a 16bit wide scanline segement of binary
data or the 8089 would use the band as raw data and translate it for
font lay down. Both chips were working hard at 12ppm.
Allison
<No offense, Allison, but the 1007 and 1005 controllers won't work with tha
<drive at all, as both 1005 and 1007 are ESDI controllers. You may be
<thinking of the 1006's which come in both MFM and RLL. The 1006 WITH an
<EPROM on it is the RLL version, while the MFM version uses the
<motherboard-resident BIOS to handle the HDD.
I could be off on the 1007 though I have NO edsi drives and am using 1005
and WD1007 (least that what the markings are) and both are PC using D540s.
Also my 1006 was used with them in the current system before I went IDE.
Note we may be talking across part numbers as I have three 1005s that
are each decidedly different from each other yet, the primary part of the
part number is WD1005! I also have 4 flavors of 1002, three differnt
lengths, one surface mount! Of all the PC controllers from WDC I have
about ten, starting with the 1002 also the 1003, 1005, 1006 and 1007.
The only EDSI controller I have is a non WD design and I don't ahve drives
for that.
<ESDI is a high-level interface not at all like the "ultra-dumb"
<ST-506/ST-412 interface this drive claims to have, though it does use cable
<of similar configuration, hence has similar connectors.
Ah, I do know the difference.
<This drive is commonly used with MFM, though its speed control, etc, is
<capable of RLL densities as are most "MFM" drives.
I've found it to be more successful than others though RD53s (micropolus
1325s 71mb) were really nice at 100mb RLL and pretty reliable till they got
old.
Allison
The Computer Museum History Center is delighted to present:
"Recollections of Early Paint Systems"
Richard Shoup & Alvy Ray Smith
January 13, 2000
18:00 hrs
Building 3
(Moffett Training and Conference Center)
NASA Ames Research Center
Mountain View, CA 94035
In the early 1970s, with the advent of 1 Kbit integrated circuit
memories, it became practical for the first time to build a
semiconductor memory capable of holding an entire image and
displaying it on a video monitor -- a picture memory or
"frame buffer."
This led to developments in interactive frame buffers, painting
and drawing programs and other graphics-oriented software at
Xerox PARC, the University of Utah, MIT, the NYIT, and elsewhere,
and ultimately to the entire field of pixel-based graphics.
Dick Shoup built the first video-compatible frame buffer and
painting system, "SuperPaint," at Xerox PARC in 1973. His
colleague and friend Alvy Ray Smith collaborated on SuperPaint,
and then went on to develop the first full-color paint program
and much more at New York Tech in the late 1970s.
In this talk, Dick and Alvy will describe and demonstrate
-- hardware gods willing --the original 1973 SuperPaint
graphics system, and a Windows-based PC emulation of the NYIT
full-color Paint3 program, exhibit historical footage of early
graphics programs and achievements, and tell some stories of
their early adventures in pixel graphics.
Following the lecture, tours of The Computer Museum History
Center's Exhibit Area will be conducted by Center staff.
Refreshments will be served and admission is free.
Attending:
Please RSVP by January 12 to Wendy-Ann Francis.
(francis(a)computerhistory.org) Due to government regulations,
all lecture attendees must register to be admitted to NASA
Ames Research Center. If you are a U.S. citizen or Green
Card holder, please provide your full name and affiliation.
If you are not a US citizen and do not have a Green Card,
please provide your full name, affiliation, citizenship,
VISA type and expiration date, passport number and expiration
date, date of birth, and country of birth.
We look forward to seeing you on the 13th!
This announcement, along with, reference materials, links,
photographs and directions to the event, appears on our
website at:
http://www.computerhistory.org/events/superpaint_01132000/
D.S.
--
Dag Spicer
Curator & Manager of Historical Collections
Editorial Board, IEEE Annals of the History of Computing
The Computer Museum History Center
Building T12-A
NASA Ames Research Center
Mountain View, CA 94035
Offices: Building T12-A
Exhibit Area: Building 126
Tel: +1 650 604 2578
Fax: +1 650 604 2594
E-m: spicer(a)computerhistory.org
WWW: http://www.computerhistory.org
<spicer(a)tcm.org> PGP: 15E31235 (E6ECDF74 349D1667 260759AD 7D04C178)
S/V T12
Read about the latest History Center developments in
"CORE," our quarterly on-line newsletter:
http://www.computerhistory.org/events/core/1.1/