test-drb December 1999

test-drb@ccmp.vtda.org

186 participants
742 discussions

by ethan_dicks＠yahoo.com

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

26 years

8089 was Re: Hyperion Passport, Apricot, Convergent Technologies workSlate,

by edick＠idcomm.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

26 years

Question for you 'big iron' collectors

by wilson＠dbit.dbit.com

>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

26 years

11/44: CSRs and Vectors

by jpl15＠netcom.com

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

26 years

Reply to the "Big Iron" collectors -- Thanks!

by nerdware＠laidbak.com

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

26 years

Hyperion Passport, Apricot, Convergent Technologies workSlate, Amdek, HELP!

by Maddog1331＠aol.com

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

26 years

8089 was Re: Hyperion Passport, Apricot, Convergent Technologies workSlate,

by allisonp＠world.std.com

<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

26 years

[postop] Re: Post-op depression

by allisonp＠world.std.com

<Happy New Year... When I was young I noted that I'd be 46 when the year 2000 rolls around. I dreamed I'd be a women for that. ;) Huggs, Allison

26 years

how many heads, Cylinders on a Quantum 540?

by allisonp＠world.std.com

<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

26 years

Computer History Lecture: January 13, 2000

by spicer＠computerhistory.org

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/

26 years

Jump to page:

2026

2025

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