All,
More interesting media to get rid of from San Antonio, Texas. This
is a stack of 4 DEC RA-60P disk packs, in their carrying cases, and one
extra carrying case (that pack is probably still in the drive, wherever it
is). Media look to be in OK shape physically, but may be dirty inside.
Contact me at mtapley(a)swri.edu or phone (210)-522-6025 to arrange
pack/ship.
- Mark
All,
I have a stack of Convex 9-track tapes for somebody to make
disappear by paying for boxing/shipping or by picking up, from San Antonio,
Texas. Included in the stack are:
7 inch diameter reels:
Convex Veclib USA V4.0 Dec 13 1988
Convex Veclib V5.0 Jan 31 1990
Convex COVUEdt V1.2 Aug 7 1990
Convex COVUEdt V1.1 Aug 22 1989
Convex CXbatch V1.1 Jun 12 1990
Convex C Compiler V4.0 Jul 19 1990
Convex C Compiler V3.0 Dec 28 1989
Convex OS PatchV8.0.1 Mar 6 1990
Convex OS V8.1 (C1) Jul 19 1990
Convex OS V8.0 (C1) Jan 31 1990
Convex CXBatch V2.0 Dec 22 1990
Convex Fortran V6.0 Jun 12 1990
Convex Fortran V5.1.1.0 Aug 22 1989
Convex 1990 User Group May 10 1990
Utilities v1.0 Jul 19 1990
user grp 1991 Jul 10 1991
tape hand-labelled "bind stuff"
tape hand-labelled "SNMP source"
tape hand-labelled "8.0 patches 3-15-90"
******
tape hand-labelled "Convex user group tape mh (v6.4)
perl v1.29 from lwall@devvax:jpl.nasa.gov."
******
11 inch diameter reel:
ConvexOS V8.0 Jan 31, 1990
Tapes are generally Memorex, all have the gold Convex label on
them. None have been tested probably for decades, and I'm pretty sure they
were stored in warehouses in San Antonio. They look to be in good physical
shape.
ATTENTION Convex computer representatives! If there is any reason I should
not make these tapes available, please notify me at the below addres and I
will comply with your wishes.
Any interested parties should contact me at mtapley(a)swri.edu, or by
phone at (210)-522-6025. Questions welcome, offers to ship more welcome. I
can't keep them for very long.
- Mark
Indeed, it may have been a mech sample.
I have DEC DCT-310s with ES written on them, they were actual
engineering samples for the VT240 team (near same time as Falcon
card develpoment). Mine came from when the Engineering junkbox.
Allison
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Monday, November 19, 2001 10:57 AM
Subject: Re: Intel C8080A chip brings $565 on EBAY
>I've got one pretty old MOTOROLA device, in a 40-pin DIP, the identity of
which
>is a complete mystery to me. In fact, I may have tossed it not long ago,
but
>all it said on it aside from a MOT date code was "Sample." Maybe it was a
>mechanincal ...
>
>Dick
>
>----- Original Message -----
>From: "Allison" <ajp166(a)bellatlantic.net>
>To: <classiccmp(a)classiccmp.org>
>Sent: Monday, November 19, 2001 6:38 AM
>Subject: Re: Intel C8080A chip brings $565 on EBAY
>
>
>> From: John Galt <gmphillips(a)earthlink.net>
>>
>> >There's a rather small community of chip collectors.
>> >
>> >However, there are a few collectors who have been
>> >collecting for over 10 years now who have put togather
>> >pretty vast collections of literally thousands of chips.
>>
>>
>> My only concern is they may be collecting junk, IE: chips that
>> look good, may be rare but are DEAD/useless electronically.
>>
>> >It would be the same as if suddenly someone found
>> >two Intelec bit slice 3002 computers dated 1975 in a closet or
something.
>> >Sure, there might could be more, but if they were common, you guys
would
>> >have already seen one.
>>
>>
>> These were quite common and the basic chipset on an experimentors board
>> was around $495 in 1977. Most were used then relagated to the
engineering
>> junk box. So I'd presume when you say rare, your referring to actively
>> traded
>> survivors as SBC colltors like me may already have one (not yet!).
>>
>> >As far as the color, chip collectors refer to that color
>> >chip as "purple". If you look at it next to a normal
>> >"gray" CerDIP, you can see the difference. Besides,
>> >it would not have mattered had it been black. The fact
>> >is, it's not the white/gold color of a normal Intel
>> >C8080A. The printing on the chip is also somewhat different. My guess
is
>> >it's a late run C8080A that was
>>
>>
>> It's very late run ceramic. Ceramic for chip substrates only comes from
a
>> few
>> vendors one being a beer maker in the rockies a few in the far east and
>> Europe.
>> It was part of the reason why ceramic parts were more expensive and also
>> a near must if the part was required to pass tests for hermetic sealing
>> (military,
>> space or other high stress apps).
>>
>> Ceramic aging/dating:
>>
>> Starting with the 1960s ceramic was white.
>>
>> early White
>>
>> examples were
>> early military Flatpacks(RTL/DTL/TTL)
>> 1101, 1103 ram
>> 1702 eprom
>>
>> first brown parts I'd seen were 2708s
>>
>> brown (light)
>> later dark brown
>> Gray
>> Gray with brownish cast
>> Gray with purplish cast
>>
>> Those were the most common. Eproms were generaltionally in the common
>> ceramic of the time.
>>
>> Allison
>>
>>
>>
>>
>>
>>
>
>heh... actually, Adolph Coors spun-off its non-brewery assets in 1992
>into ACX Technologies, and most recently, CoorsTek (formerly Coors
>Ceramics) was spun-off into a wholly separate company on Jan 1, 2000.
>
>-dq
I know but, in reference to collectable chips it was true to the most part.
I just didn't want to wear out the list with minute details.
Allison
> Back in the early days of 64k DRAMs, the COORS ceramics were described as
having
> too much radioactivity for use in high-density memories. I'm not sure that
was,
> in fact, the case, but somebody seems to have thought so. Do you suppose
they
> fixed that? Coors was a leader, in the '60's in porcelain tooling and other
> such oddities, not to mention having "perfected" the draw-and-iron process
for
> making thin-walled aluminum beverage cans.
My 8k EconoRAM IV, one of the first S-100 boards to use DRAM, used the
very chips that supposedly had that problem. I've been told mine are
OK, but it used to be a bit flaky; however, I always blamed that on
the state of the early S-100 systems and my soldering work on the SOL
to which it was attached... I solder *much* better now... -dq
All,
SwRI is scrapping a big analog recorder rack. Top end contains a
reel-to-reel recorder with big (ie around 24" diameter) tape reels. Model
number looks like EB-3030 or EP-3030. Bottom end of the rack contains a row
of Ampex "Monitor Oscilloscope" devices, what looks like an
amplifier/signal conditioning box, labelled "Datum tape search and control
unit", and a "Datum Time code Generator" with day/hour/min/sec readout.
To go with this is a big *heavy* stack of the tapes it uses.
Yours for shipping or pickup from San Antonio, Texas. I have
digital pictures, 4 jpegs at about 500k each, if you want to see better or
want to web-host, and I can go check specifics if you have specific
questions.
I need a commitment this week if you want it, though, as we need
the space, else we have to trash/recycle.
Please contact me off-list, I'm way behind on reading my digests.
I'm at mtapley(a)swri.edu, or phone (210)-522-6025.
- Mark
"Curt Vendel" <curt(a)atari-history.com> wrote:
(Re: Corvus floppy disk controllers)
> If you run across the schematic I would be willing to pay for any copying
> and postage, thanks again Frank.
Take a look at:
http://www.reanimators.org/tmp/corvus-fdc.d300.tiffhttp://www.reanimators.org/tmp/corvus-fdc.d600.tiff
Both are TIFF class F group 4 scans, one is at 300 DPI, one is at 600
DPI. The "original" that I have is a crappy photocopy so, well, good
luck reading them. I'll talk to Al and see if he wants to adopt these
or point me to a better scan.
The 8" floppy controller also has a space on the board for a
34-pin connector, but it's not stuffed.
I got this controller and schematic from an advertisement in Computer
Shopper in the mid-to-late 1980s, offering an 8" floppy controller for
the Apple ][. Sadly, at the time I didn't have a WDC 1793 data sheet
so my efforts at programming the thing were frustrated and I got
distracted by other things.
Then there's the 5.25" floppy drive. I got that out too and had
a look at it.
The drive is a Corvus model FLP-5, Rev C, s/n 404-G1018-. It's a
metal upright case screwed together and to a half-height 5.25" floppy
drive, in this case a TEC FB504 (which is a double-sided "quad
density" 720KB drive, so I'm guessing 96 tracks per inch) strapped for
DS0 and with terminating resistor pack installed.
The 5.25" drive is connected to a different controller. The
silkscreen on the board calls it a "BUFFERED FLOPPY CONTROLLER", and
there's a handwritten part number, "8010-10149 REV A". It's laid out
differently and is clearly a different design: it's got a NEC D765AC
FDC, and also has a power connector through which the controller card
supplies power to the drive; the power cable and a 34-pin flat cable are
bundled together in a sort of plastic zip-lock wrapper.
I've no idea what this 5.25" drive was used with. Along about 1996
there were some cleanouts of cupboards and storage rooms at The
Wollongong Group (where I worked at the time), and there was this
drive and controller (which I got) and a Corvus hard disk (which I
didn't get). I didn't see a Concept there. I do know that several
folks came from Corvus to Wollongong in the mid-1980s (before I got
there) and guess that they brought this stuff with them.
-Frank McConnell
> -----Original Message-----
> From: Richard Erlacher [mailto:edick@idcomm.com]
> Not to create an issue, but under Windows, that doesn't often
> happen, though
> it's possible, I guess. <ducks to avoid flames> What could
> be going on?
You do realize that you ought to be comparing Mac system 7.x with Windows
3.1? Granted, the OS was frozen in that state for a very long time, but
originally, that was its primary alternative.
Windows 3.1 is not famous for being a real-time system, either ;)
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
> -----Original Message-----
> From: Richard Erlacher [mailto:edick@idcomm.com]
> however. I tried to
> initialize a diskette, and had to wait about 5 minutes after
> the process ended
> before it would let me do anything else, though it did
> eventually let me back at
> it.
That's pretty normal. It will take it a while to flush buffers and wake
back up -- rather, that's what I assume it's doing... :)
> Funny thing, though, is that I remember people claiming that
> MAC OS was
> multitasking. Windows allows me to play a game or whatever
> when I start off on
> a time-consuming task. This guy doesn't seem to want to do
> that. I had to try
> it on the second machine just to verify that the thing was
> not just bum
> hardware. It worked the same on the second box as well.
This gets really tangled right about now. What's your deffinition of
multitasking? Is the hardware capable of it? Yes. The software? Well,
It's co-operative. If you'd asked microsoft about their definition before
Abomination '95, they'd have told you that co-operative multitasking is
still multitasking too...
I have yet to figure out why they couldn't have done the disk reads/writes
in the background while you do some other things. I believe it's likely to
be a "left-over" from early days.
Funny thing is that if you can find a file-manager or the like that will
format disks/copy files, it's pretty likely that you can work around this
particular problem.
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
> -----Original Message-----
> From: gwynp(a)artware.qc.ca [mailto:gwynp@artware.qc.ca]
> You're best bet is to buy a Mac Addict or other magazine that
> has a CD-ROM
> (you do have a CD drive?). Older Macs don't "boot-strap"
> very well. Yes,
> you can get a SEA (self-extracting archive) of Stuffit, but
> it won't do
> you much good. Mac OS has 2 forks per file. One for data, the other
> for code. When you download a file or when you copy a file from a PC
> formated disk everything goes into the data fork. Doing something
> equivalent to "chmod +x file.sea" is impossible on Mac OS without an
> external program, like say Stuffit. *sigh* If you are
> lucky, you'll have
> a recent version of Mac OS which includes Stuffit.
Well, if you'd like a home-baked solution (possibly home half-baked. :), you
can write Macintosh 1.4 meg disks on a peesee type machine (or unix box).
I can possibly provide code for an hfs loadable module for linux, and a
rather generic set of c programs that will read/write mac filesystems.
With that software, and an archive that you can extract the stuffit binary
from, you'd be able to write the proper resource fork to the disk as well,
and have the macintosh know what to do with your program.
> I find this to be one of the most incredible "features" of
> Mac OS. Apart
> from that, as long as you have a real computer nearby, using
> a Mac isn't
> that bad.
I feel the need to defend this "feature." In so much as this allows you to
separate data from code, this is a wonderful idea. The problem, really, is
that apple left their o/s unfinished, and didn't include the proper
utilities to manipulate these things that the system depends so heavily
upon.
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
