> From: Chuck Guzis
> On 01/23/2018 04:04 PM, Al Kossow via cctalk wrote:
>> they mention they used CATV technology (where the vampire taps come
>> from)
> Wasn't that ChaosNet?
The CHAOS net (capitalization varied, but original docs usually use two words)
hardware did use the heavy-duty CATV cable (not the indoor stuff; I have a
chunk of the heavy-duty kind they used too :-), but not vampire taps; the
transceivers had T-connectors on them, and to install one, one put connectors
on the ends of the cable segments, and screwed them onto the T-connector.
Noel
Hi All,
I got a lovely Televideo 970 terminal from another list-member over the
weekend. Aside from some PSU capacitor issues, it needs a little TLC:
1) The EMI filter had gone open-circuit - it's one of those metal can types
which is integrated with the IEC power input connector. Are these still
obtainable anywhere? It seems like equipment these days just has the
filtering directly on the PSU board, rather than as a separate module. I've
just bypassed it for testing, but I don't want to leave it like that.
2) I have a faulty back-tab, left shift and return key (return's simply
unresponsive, while the other two stick down). Do the keycaps on these
terminals simply pull off, or is there some trick to removal? I did some
experimental prying, but didn't want to try too hard and risk snapping the
switch stem.
I don't know if switches are still available, but worst-case I can swap the
faulty ones with ones for some of the 'special' keys that I'm extremely
unlikely to ever use.
cheers
Jules
I have some sun3/vme systems
Several 3/60
3/260
sparcstation 4/370
SMD disk array for 3/260
The 3/260 and 4/370 have some oddball boards for data (cosys) and
video acquisition (Aviv).
I also have some spare sparcstation 10s and 20s.
I haven't seen sun3 stuff for sale much. Does anyone know approximate
valuations for tested systems?
Regards,
Kevin
> From: Chuck Guzis
> Really, is this any worse than the gold bugs scrapping whole systems
> for the prospective precious metal content?
Well, the latter are presumably in it as a business, whereas it seems these
people do it for 'fun'.
Now there's an idea: perhaps we could convince them that pulling the wings
off flies is a more entertaining hobby?
Noel
I acquired a copy of CP/M-68K and am trying to pull together the
parts for a 9816 to run it. I have Nimitz keyboards, but would like
to find its little brother that matches the size of the 9816
> From: Paul Koning
> The nominal OD of RG-8/U is .. within spec for Ethernet cable.
Oh, OK. I was just used to the 10Mb cable we used being slightly larger than
the 3Mb cable we used.
> Also, Ethernet requires a solid inner conductor (for the tap) while
> RG-8/U may come stranded. (Maybe only in some variants, I'm not sure.)
As can be seen in the photos, the 3Mb stuff (at least, the stuff we used) was
also solid. The diameter of the center was a little smaller on the 3Mb than on
the 10Mb; .16mm versus .23mm; not sure if that was just happenstance, or what.
Noel
A few notes:
The experimental Ethernet speed was in fact 2.94 MHz: It's the Alto clock
divided by 2.
The Alto based printer was called "SLOT" -- Scanning Laser Output
Terminal. It was plugged into the Alto backplane and presented itself as a
hardware peripheral controlled by microcode (as was the case for all Alto
I/O). It was an Alto task, of course.
The vampire tap transceiver used RG-8 cable originally. That's before they
added the lines around the cable and added additional shielding.
The XGP was used at the Stanford AI Lab and was, as mentioned early, a dry
process. And it did use a roll of paper.
> From: Paul Koning
> I[t] just dawned on me that the subject is Apollo the company bought by
> HP, not Apollo the spacecraft. Oh well...
Actually, that stuff has all been saved, and run under simulators; there's
a very comprehensive site here:
http://www.ibiblio.org/apollo/index.html
which will keep anyone entertained for hours.
(I have this bit set that at one point there was a 'project history' page,
but I don't see it, looking quickly now.)
Noel
Greetings to the List from the Snowy Rocky Mountains.
Beautiful clear sunny day here at +9F :)
The SCSI controller on the 68K development system (VMEbus) that I
have cobbled together occasionally hangs after I reset one of the
processor boards (there are four MVME177-005 68060 boards in the VME rack).
The hang then happens when my software touches the SCSI drives via
the ROM'd 68K/Bug I/O primitives and the hang will not go away even
after another reset until I cycle power.
I have never before dealt with SCSI as a programmer - does this sound
like something is configured incorrectly?
There is not much to configure.
I point out that I am not certain that I have the termination
resistors correct.
Thoughts?
I appreciate any advice.
Regards,
Jack
Evergreen Colorado
----------------------------------------------------------------------------------
Jack Harper, President
Secure Outcomes Inc
2942 Evergreen Parkway, Suite 300
Evergreen, Colorado 80439 USA
303.670.8375
303.670.3750 (fax)
http://www.secureoutcomes.net for Product Info.
Jim -
I appreciate the great SCSI information.
The hang is not at all frequent.
I do resets many times during a programming
session as my "marvelous" code hangs or otherwise
goes crazy and into thew weeds :) and I only
see a SCSI hang every few days.
Regards,
Jack
At 10:28 AM 1/23/2018, jim stephens wrote:
>Scsi controllers are very sensitive to resets
>and getting out of step with the state of the bus the initiators they control.
>
>Scsi can have multiple initiators, and you may
>of course have a system which acts as a target,
>but i'm guessing since you said drives, you have
>a pretty common setup, a system with drives
>attached, where the scsi device on your system is the initiator.
>
>One thing that throws off scsi is to do a reset
>which comes from somewhere the initiator doesn't
>know about.? many are not friendly when that
>happens and just end up hung up.? Reset tells
>all the devices to stand down, and it is
>expected that an enumeration of the bus will
>take place by all the initiator(s).
>
>That may have happened if you reset your other
>processors or did something which affected the
>initiator.? And the resets on most systems
>usually hit all components, so I'd be surprised
>if only the one processor was affected.
>
>thanks
>Jim
----------------------------------------------------------------------------------
Jack Harper, President
Secure Outcomes Inc
2942 Evergreen Parkway, Suite 300
Evergreen, Colorado 80439 USA
303.670.8375
303.670.3750 (fax)
http://www.secureoutcomes.net for Product Info.
