Anyone know? I'd like to own a JX by the way...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Chuck Guzis wrote:
Don't forget the old CDC 6603-Bryant disk! My most vivd reminder of
hydraulic actuators on CDC gear was on the 821 disk. We were running a
benchmark with about eight of these things (connected through a QSE). We
knew that one was leaking, but the leak wasn't enough to take the thing
offline and we had a few hours invested in setting the benchmark up, so we
decided to go with it.
----------------------------------
Billy: Through incredible luck, I never had to work on the Bryants. They
always seemed to break on shifts that I didn't work. CDC starting buying
them in the early '60s. I actually worked on 1604's with Bryant disks. I
think the controller was a 1619. They were horrible to work with, and very
hard on the hands.
For Indutrial Data Products group, we used a few of the old Bryant drums and
single platter fixed disks. STC wrote an OS for these drums in the late
'60's. They put them all the world with the tracking stations. Last one I
saw that was still running was around 1980. Would love to find one now.
The model numbers were 8951 and 8952. One of the most reliable peripherals
ever made, some ran for 15 years, 24 hours a day, without any maintenance.
------------------------------------
Chuck: At some point, a message pops up on the console that 821
Unit-so-and-such
is offline. I run for the thing, forgetting about the lieak, have my hand
out ready to punch the "on/off line" button, hit the puddle of fluid and do
a wonderful imitation of a swan dive. I collect myself, punch the button
and limp back...
------------------------------------
Billy: I don't place the model 821. There was an 841 that might be what
you remember. It had the drives two high in an expandable rack. You kept
bolting chassis together and then put end panels on it. It was hydraulic
too. And leaked like a sieve. The beauty of the two high is that if the
top drive leaked, it would drip on the bottom drive and take it out also.
Two for the price of one! Had big ten high platter removeable disk stacks
and was used on the 3000 systems with a controller called the 3234.
------------------------------------
Chuck: I REALLY don't miss the old hardware. If I wanted to work with heavy
machinery, I'd go back to work in a steel mill.
I'm sure that Billy has had his share of digging shredded ribbon out of the
type train on a CDC 512 pritner, too. Wonderful rewarding job.
Cheers,
Chuck
-------------------------------------
Billy: The 512 was an abomination. It was a rip off of the IBM 1402. To
avoid paying fo patents, Rochester re-invented several wheels. The train
used slugs that ran in tracks, but had no direct connection to each other
(think about a bunch of ICs in a circular tube). Any wear and the timing
changed. So you had to tweak the hammer timing almost daily. It ate
ribbons. And if the operators tried to be cheap and use one to the last
drop of ink, it would disasseble the ribbon and jam the pieces between the
slugs and deep into the hammers. Some times a ribbon change could take an
entire shift.
It also used a paper tape reader for format control. This nasty little
kludge used a sprocket drive on early 512s. When it tore the paper tape,
usually late at night, it would high speed slew paper through the printer,
jam the output stacker, and sometimes break the hammers.
The 512 was probably the most hated peripheral CDC ever produced.
Billy
>
>Subject: Re: Repair methods (was Cromemco 3101/Beehive B150 score)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Date: Mon, 05 Jun 2006 23:21:04 +0100 (BST)
> To: cctalk at classiccmp.org
>
>> Blech. It's awfully had to do anything *interesting* in Pascal...
>
>I assume you've enver seen a PERQ running POS ;-)
>
>-tony
Dont know who wrote the first commant about Pascal. My comment is simple.
It's a programming language, whatever you do will be interesting
or boring in any language. I've seen trash written in every
language under the sun and one thing stands out. Trash is trash.
Allison
Hi all,
I thought I have a working Kennedy 9100 open reel tape drive ...
I copied files to the tape and could .DIR them. The next day it did not work.
Today Edward came for a visit, and I demonstrated the tape drive to show
how it fails. But now it did work again, though it was 100% successful.
Edward checked the card cage inside of the Kennedy 9100 drive.
Two boards are probably missing, and it makes sense *if* the tape was
one of several in a chain, because missing are slot #3: "data terminator"
and slot 8: "control terminator".
So, in a multi-drive setup, I assume these two terminator boards go in
the last drive. In a single drive setup, these boards should be in that
drive. Is this correct?
If so, can somebody help me find these two cards ...?
thanks,
- Henk.
This message and attachment(s) are intended solely for the use of the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by telephone and with a "reply" message.
Thank you for your cooperation.
>
>Subject: Re: SBC6120 (a build-it-yourself PDP-8 clone) Last Buy and EndofLife
> From: William Donzelli <aw288 at osfn.org>
> Date: Mon, 05 Jun 2006 14:49:06 -0400 (EDT)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>> Oh, and anything you want to be reliable......
>
>Also, when sockets are used in large quantities, manufacturing yield takes
>a dump. We have all mashed a pin or two in our lifetimes, trying to get
>something inserted (anyone that hasn't is a liar!). Now multiply that by
>several orders of magnitude on the assembly floor.
>
>ENgineers should try there best to avoid sockets. Period.
>
>William Donzelli
>aw288 at osfn.org
I use them where there are programable parts that can't be blasted in
circuit. Sometimes when the part used is a temporary sub (74ls for a 74HCT).
My preference is machined pin or the better sidewipe when I have to.
However my worst experiences are socketed board for failures that
were the socket itself. TI and RN made a edgewipe that was the absolute
pits for relibility. By edgewipe I mean the narrow edge of the pin
not the wider face. I've desocketed 4 NS* MDS controllers that used them
both kit and factory and all had no bad parts but plenty of inop sockets.
Allison
Sorry for clogging up folks' bandwidth like this, but I'm trying to get in
touch with Lee Davison. Does anyone know if he's still around?
I asked him to have a go at fixing my Jupiter Ace a while back, now I want
the thing back (to try and fix it myself <VBG>) and he's not replying to my
emails (or not receiving them - one or the other)...
Lee: can you contact me offlist either on this address or on
philpem at philpem.me.uk so we can sort this out?
Thanks.
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G VF+UniPod
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 1G+180G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
Hi all,
Is there perhaps anyone here that can answer this question?
ELF executables have program segment headers, containing a field
p_offset that should refer to the offset in the file where the section
of data starts. However, regardless what executable I look at, they all
seem to contain a header that contains a p_offset = 0. This would mean
the absolute start of the file, exactly where the ELF header itself is
located. For example, when I do:
$ readelf -a /bin/bash |less
I get:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x837bc 0x837bc R E 0x1000
LOAD 0x084000 0x080cc000 0x080cc000 0x05350 0x09a94 RW 0x1000
DYNAMIC 0x088fa4 0x080d0fa4 0x080d0fa4 0x000d8 0x000d8 RW 0x4
NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4
GNU_EH_FRAME 0x083790 0x080cb790 0x080cb790 0x0002c 0x0002c R 0x4
The 3rd header contains an p_offset=0. Why? I don't get it.
Bert
Sockets do have their place, but to say no board should be without sockets
expresses a *VERY* narrow viewpoint. Many arcade game boards had sockets and
gave no end of reliability problems. I would certainly agree that prototype
boards probably need sockets, but I would not expand that to a generalization
that all boards need sockets.
> From: "Alexandre Souza" <alexandre-listas at e-secure.com.br>
> No board should be without sockets. Period.
>
> Even in prototype boards, you should use that. They are cheap comparing
> to the price of your time for a future problem diagnose, or for the care of
> the board in case you need to change one or two ICs. Sockets are cheap, love
> them! ;o)
>