Should be a bit less silent now I guess. ;)
Anyone here exceptionally familiar with the SC-40? I've completed imaging
the drive (just microcode and diags, someone want to finish reversing it
for use in klh10?) and doing the inspection (actually finished weeks ago
but got busy)
Now, I have a tape drive working and attached to it via SCSI...however now
I'm lacking info on how to actually do a tape bootstrap. ;)
http://gewt.net Personal stuff
Here are some hex DEC compatible boards that I just found. If you wish to
make an offer, please contact me off list.
ACT 10103-0, 10104 ON BACK
COMPUTER INTERFACE TECNOLOGY CM7819 =DZ11?
COMPUTER CONSOLES 34D01533
DATA PRODUCTS 257240, 257345 SERIAL INTERFACES
PERTEC GCR/PE READ 107856-02,
GCR/PR READ 107861-01AN DEC # 29-23763-00
107866-01 DEC #
VERSATEC BIPOLAR ALGORITHM PROCESSOR 382441
I've checked Bitsavers. Computer Consoles Inc doesn't appear to have a
presence there, and there's nothing in the Harris or ICL sections (two
rebadgers). Anyone information you guys might have on this machine would be
I had written
I?m in need of an owner?s manual (and ideally, a service manual as
well would be nice) for? a Northern Telecom Spectron D101. This is an RS232
serial datascope, basically a line monitor with some programmability
(displays in binary, hex, ascii, or octal; start tracking on certain
characters; substitute X string for Y string; etc.).
I?ve googled excessively with no results, and also reached out to AEK. Any
chance someone has one in their pile?
FYI, after posting the above I did yet another round of google searches and
this time a manual popped up as the very first search result. Odd. Manual
purchased, and I'll copy and send off to Al if he wants it for bitsavers.
> From: F. Ulivi
> I hope I'm not "offending" anyone in this forum by mentioning an
> emulator, it looks like you are mostly focused on real (vintage)
Absolutely not! Although we do indeed focus on vintage hardware, I think we
all understand how useful emulators can be, and many (most? all?) of us use
them as a useful partner to our old hardware. I certainly do! (If nothing
else, they tend to run a lot faster than the actual machines do! :-)
> From: Josh Dersch
> I finished restoring the 4014's power supply
So I'm curiuous; what exactly did you do, in restoring the supply? (Given
that you'd previously already turned the unit on, and discovered this
behaviour?) Just adjust voltages to spec, or more than that?
Hi all --
Picked up a Tektronix 4014-1 terminal. It's in pretty good shape, nice
and clean and it's in nearly-working condition except that the storage
behavior isn't quite right.
On power-up, write-through doesn't. (That is, characters don't get
stored to the tube.) Clearing the display via the RESET/PAGE key clears
a roughly elliptical region in the center of the display but leaves the
outer edges a mess. The cleared region stores characters properly. You
can see the overall effect here:
After a 2-3 minutes of warming up the area cleared by RESET/PAGE
increases. I haven't run the terminal long enough to see if it
eventually completely erases the screen (while the power supply appears
to be within tolerances, I still need to rebuild/reform it so I'm not
going to run it too long yet).
So far everything else seems to be functioning properly, the cursor
appears properly (and does not write through), input is accepted from
the keyboard, etc. I've been reading through the service manual on
Bitsavers and it describes a very in-depth alignment procedure which I'm
prepared to go through (once I've got the power supplies rebuilt) but I
thought I'd ask here if this problem rings any bells and if there's
anything I should immediately suspect or adjust. You guys know
Thanks as always for the advice,
>So it looks like he made a little cap over the top - that's a very simple
>print. If you can get me dimensions I can print you a few.
Yep that's what I did:
inspiring myself from Rick's drawing (thanks Rick). It's a very small part
though, not sure if you can print something that small accurately unless you
have a professional printer.
The cap I made was 6mm high, 9.6mm in diameter, with a cavity 3mm deep of
6.30mm diameter at the bottom for the capstan to go in. It required me to
reduce the original capstan diameter to the 6.30mm so it could fit in the
cavity though. That's what I was trying to avoid with my two alternate
proposals (for people that don't have a lathe...)
Speaking of which
>I want his lathe. :)
Mwahahaha. Nooooo. It's all miiiiine. Sadly they don't make them anymore, I
got one of the last ones.
Does anyone know how to remove the side skins on an SGI Origin
(specifically a 2200 deskside cabinet). The manual mentions removal of the
top and front, but says that the sides are more tricky and to contact SGI
for the procedure.
I'd like to remove them as there's some minor paint splatter on them, which
would be much easier to deal with off the machine.
I see there's a screw at the bottom of the machine on the rear edge (much
like the one for the front which releases the front skin), but removing it
doesn't seem to let the rear plastic molding drop in the same way, and I
assume this needs to come off first.
From: Sean Caron <scaron at umich.edu>
> You are right, even the interactive performance of the R8K had me a bit
> taken aback...But I understand in its day it really flew on the FP codes;
Yup. The R8000 was pretty specifically designed to be a desktop super, for
some value of "super". And for 1995, it was pretty remarkable. It was the
first superscaler MIPS, and the dedicated FP unit was pretty much pushing
the envelope on single chip tech. But integer performance wasn't a
priority, and you could tell.
> I don't know if this claim was ever really substantiated in the real world
The MIPSPro compilers usually did a really good job of optimizing for the
R8000, and for the jobs it was designed for (non-vectorizable floating
point) it really flew (300ish MFLOPS...which for 1995 was nothing short of
amazing in a desktop).
I would note, however, that the common comparison to the Y/MP is pretty
much pure marketing. The Y/MP and the R8K were on-par for non-vector FP
problems, but as soon as the compiler could substantially vectorize the
problem, the Y/MP could be many times faster than the R8K for the same
In the end, we found the R8K was a nice dev machine (due to a good bit of
source compatibility between the MIPSPro and Cray compilers), but not
generally cost effective, and pretty much outmatched all around by the R10k
> But it's a neat little oddball