https://www.ebay.com/itm/132933407806
this is interesting because of the price and that all of the Sun drives
I've ever come across had the 800bpi option in them
*Eric Smith *writes:
> On Mon, Feb 11, 2019 at 11:18 AM Al Kossow <aek at bitsavers.org <http://www.classiccmp.org/mailman/listinfo/cctech>> wrote:
>
> >/Does it have the 800 bpi option board? />//
> I haven't yet unboxed it. I took photos of the outside of the destroyed box
> to send to the shipper. The front bottom left corner of the 88780 is
> visible through a hole in the box, and is visibly mangled.
>
I acquired mine as a piece of decommissioned hardware where I worked.?
It came home with me in my car.
Some time later (mid 90s) I loaned it to a friend for some contract work
at <a likely-bankrupt public utility in San Francisco>.? I drove it up
there and delivered it on a cart.? The stars, however, did not align for
getting it back to me the same way so they shipped it to me where I
worked.? There was some damage to the plastic front cover and control
panel mounts.? I was able to repair or work around most of it, and the
unit still works fine to this day. (Well, the plastic take-up reel is
loose...)
Pretty much everything I have that could go in a rack I fetched myself
rather than having it shipped to me.? While one can't always do that, I
recently carted home an HP 3455A multimeter from Los Angeles, some 400
miles.? I was already in the area, otherwise I don't think I'd've made
the round trip just for it.
> Based on the service manual, it appears that option 800 requires:
> * buffer PCA 07980-6xx14 (512K) or 07980-6xx34 (1M)
> * read/write/formatter PCA 07980-6xx31
>
Mine has the 800 bpi option.? Not by inspection, but by operation.
--
Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
Nature abhors straight antennas, clean lenses, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
Card-sorting, Joel. -Crow on solitaire
Hey Kyle.
You can narrow things down a bit by removing the optional Z-buffer and
additional bitplane memory (ZB3 and BP4). While that removes those two
masses of memory out of the equation that still leaves the still massive
amount of ZIPP base video memory. for the later Onyx systems I've only seen
pinstriping when the video memory or supporting glue has been allowed to
overheat. I can't recall if it tests the graphics as well but have you tried
running the ide diagnostics in case that refines the error a little?
-John
>I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've
>got vertical lines appearing on the screen, but not everywhere on the
>screen; that seems to hint at an issue with one buffer having bad memory.
>It was especially evident in the flight simulator demo, where alternating
>frames flashed with and without lines.
>
>The ever helpful self test says, "ERROR: Failure detected in the
>Electronics Module (graphics). press <Enter> to continue".
>
>The system is equipped with the ZB3 and BP4 on a GR1.2.
>
>How can I better diagnose this issue? There are so many RAM chips soldered
>on these three boards. Tracking it down to a single chip sure would be
>nice.
>
>Thanks!
>
>Kyle
although? ?I? think? ?most? production? ? for? switch gear? ?was? ?done? ?with the later? ?32? bit? ?unit
Ed#
In a message dated 2/10/2019 12:49:36 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
telephone? gear?
ed#
In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes:Bringing up a bit of an old thread here, as I just picked up one of theseyesterday. Typed in some example programs, which took far too long thanksto a bouncy keypad. But hey, at least it works!
Were there any real applications for the MAC-8? Haven't been able to findmuch.
Thanks,
Kyle
> From: Jerry Weiss
> it is impressive that UNIX booted successfully without tripping over a
> boundary.
Well, V6 is (or can be configured to be) extraordinarily small, so I'm not
surprised it booted OK without going over the 0170000 mark.
I have this persistent memory that the -11/40 in the CSR group at MIT had only
3 banks of MM-L (@16KB each) when I first got there! Which is plausible; the
smallest V6 config would have about 22KB of core text, and about 2KB of
initialized data. If you cut all the parameters to the bone (minimal number of
disk buffers, etc) you could probably get away with say 6KB of un-initialized
data. That would leave you 18KB for user programs on such a system, a bit less
than their recommendation of 24KB minimum for users, but probably minimally
useable.
We quickly added more memory, I'm sure, but I don't now remember how/what!
Later on it was converted to an -11/45, and then we got an Able ENABLE, but
that would have been a couple of years later.
Noel
> From: Jerry Weiss
> Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
> boundaries.
Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219)
>from the RC11 controller, and that _can_ cross moby boundaries, so clearly it
has the right overflow output; someone just decided not to implement it - the
DR11-B sets ERROR instead on an address overflow. Wierd.
Anyway, it will be interesting to see if RSTS operates correctly once this
problem is fixed...
Noel
Greetings to the List -
I am mounting a couple of heavy (130-pounds each) HP7970e tape drives
to a 19" rack.
The screw holes that mate to the standard spaced holes on the right
side of the drive after you open the case are visible and obvious.
However, the holes on the left are hidden under the heavy die-cast(?)
frame of the drive.
Anyone know how to get to those three screw holes with a horrible disassembly.
There has to be a trick to this that I don't see (so what else is new? :)
Best,
Jack
----------------------------------------------------------------------------------
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.
> From: Fritz Mueller
> If, as you are suspecting, we find damning evidence pointing
> specifically to the RK11
I got an update from Fritz. As you all will recall, the problem seemed to be
a corrupted 'pure text'. So the question was 'when was it damaged, and how'.
After some confusion caused by different OS images (the 'Ritchie' and
'Wellsch' distros), he managed to get a look at the text in main memory after
it was first read in from the file system, and before it was swapped out (it
was showing up damaged after a swap out/in cycle); it looked good at that
point. The copy written out to the swap disk however, not so good.
A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.
We also need to characterize exactly what the fault is, because the DEC RK11
diagnostics weren't finding it, so it seems the diagnostic suite could use an
enhancement....
Noel
> From: Alan Frisbie
> Harbor Freight sells a nice hydraulic lift table for under $200 that I
> have found very useful for that sort of thing. It doesn't go up very high
> (like for the top of a rack), but I used it with some wood blocks
Thanks for the tip! I got one on sale for about US$140; it's _very_ sturdy.
And the top is just large enough to hold two milk crates (available at
Home Depot, BTW), so it's guite easy to build up a stack as high as one
needs to reach the top of a 6' rack.
Noel
> From: Jon Elson
> Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
No; the RK11 spec says "[the two extended memory bits] make up a two-bit
counter that increments each time the RKBA overflows".
The actual error turns out to be slightly different to my guess; there's
a spurious overflow from the low 16-bit register to these bits at 0170000.
I can see how the diags didn't catch that one! Unless you try a multi-block
xfer that walks across the boundary.... A perfect example of Vonada #12.
Noel
All boards are corroded.
May be some can be saved ?
I am offering :
12002 B XL Ctrl 512 Kb 51x0-013 x = ? Pictures available
12001 C CPU 12001-80001 Has the 1AB5-6001 "HP SoS processor" with Two EPROM ( 12001-80006 and 80007 )
Any interest in imaging these ? BUT, ** I ** cannot do it !
A ser Qty TWO 12005-60010 Has the 1AF5-6001 "HP SoS processor"
HP_IB 12009-6x00 x=? with 1AA6-6004 and 1AC5-6001
12021A Cntrl R 12021-60001 has the 3 Eprom
and Nec P16175-12 / Intel D8291A / ? FD1791A
Eprom : 2116, white ceramic, labeled : 5180 - 0144, 0137, 0136 ( U43, U53, U63 )
Any interest in imaging these ? BUT, ** I ** cannot do it !
Backplane 2 column, 4 row .... a slight scrubbing may be enough
Card Cage, if needed : Fine
Power supply seems in great condition. Will check more closely, if needed.
Battery board !!!!! Only the relays and buzzer can be saved !
Case ?? Who would like a case ?? ;-)
TERMS :
Remember : I live in France ( shipping ..... )
Small item ... free
Medium items ( cards ) ..... shipping cost
Large items .... shipping cost plus a fee for packing material and my time.
Will wait a full week, to see if BOARDS are asked for, before making PARTS available.
Picked up this core memory trainer yesterday. Seems pretty obscure.
http://imgur.com/a/TIOvt7r
Has anyone seen one before? Would love to find some documents someday.
Thanks,
Kyle
I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've
got vertical lines appearing on the screen, but not everywhere on the
screen; that seems to hint at an issue with one buffer having bad memory.
It was especially evident in the flight simulator demo, where alternating
frames flashed with and without lines.
The ever helpful self test says, "ERROR: Failure detected in the
Electronics Module (graphics). press <Enter> to continue".
The system is equipped with the ZB3 and BP4 on a GR1.2.
How can I better diagnose this issue? There are so many RAM chips soldered
on these three boards. Tracking it down to a single chip sure would be
nice.
Thanks!
Kyle
telephone? gear?
ed#
In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
Bringing up a bit of an old thread here, as I just picked up one of these
yesterday. Typed in some example programs, which took far too long thanks
to a bouncy keypad. But hey, at least it works!
Were there any real applications for the MAC-8? Haven't been able to find
much.
Thanks,
Kyle
there should be a yellow covered 8x11 manual out there if not.. let me know...
Sent from AOL Mobile Mail
On Sunday, January 13, 2019 Jason T via cctalk <silent700 at gmail.com; cctalk at classiccmp.org> wrote:
On Sun, Jan 13, 2019 at 7:47 PM ED SHARPE via cctalk
<cctalk at classiccmp.org> wrote:
>
> If any the? group? gets the? bell mac? we would love? a scan? or? hi? res? photo of that multi? colored? sheet. It? would? look? nice? printed in the? back? of? a? display? of? ? one of these units? here.We? have? 3 of these units as? I remember...? and? actually? when I? get my hands around them one? will be? up? for? grabs. Please? advise? ------Ed# SMECC
Seconded - I have one of these boards (without the fancy case) but I
have zero docs for it, save for what little is online.? The auction
seemed to have a few booklets, as well as the poster.
j
Been catching up on a backlog of scanning, grab what you like. Manuals
indicated with an asterisk are available for cost of packing+shipping
if you want something printed. This offer will expire in about a week
so please indicate interest early.
Burroughs [1]
* B2000_B3000_B4000 Work Flow Language Reference Manual Oct-1980
* B4000_B3000_B2000 Series BPL Reference Manual Jul-1978
* B4000_B3000_B2000 Series Data Management System II Users Manual Mar-1979
* B4000_B3000_B2000 Series DMS II DASDL Reference Manual May-1979
* B4000_B3000_B2000 Series DMS II Host Language Reference Manual May-1979
BJ-8-B8500 System Reference Manual May 1967
Various B6700 manufacturing documents
Burroughs TD700 manuals [2]
TD700 Central Control Schematic
TD700 Display Assembly (Head Unit) A2
TD700 Keyboard Assembly A1
TD700 Logic and Power Supply Assembly
TD700 Power Supply schematic
TD700 PW Board Assembly driver (interim)
TD700 Unit Travel Log
Misc [3]
* Freedom 220 USERS MANUAL Preliminary Edition
* Microsoft utility software package reference manual for 8080
microprocessors 8102-343-04
* The COPS Programming Manual National Semiconductor Feb 1985 [2]
* Users Manual for the VG-920 Terminal (Tentative)
* CPL is a First Aid Kit by Dr AA Grainger UTAS CC
[1] https://drive.google.com/drive/folders/1GXEU_kWWKo4btixnrQLRa5qFjZm9uqCM
[2] https://drive.google.com/open?id=1iihVNRfkd_zX_PwV30gKQTNLzLcnMEvm
[3] https://drive.google.com/drive/folders/1VEiZs1j11VPBYaZrNUaDxSpKWiZasfCC
> From: Al Kossow
> I have a source tape. I'm trying to figure out why modern tar doesn't
> understand it.
I had an issue reading some TAR's of Unix V7 stuff; I brought up an older
version of TAR under Windoze and they read fine with it. I don't recall if I
figured out what the problem was, or if I just wanted the bits, and as soon as
I had them, dropped it.
Noel
> From: Bill Gunshannon
> What about all the cross compilers that ran on PDP-11's?
Good point; by coincidence, I just found the stuff about the 68K
cross-compiler from Alcyon (in San Diego) which we used at Proteon;
it ran on an -11/73 running Ultrix.
According to the ad sheet, it also ran on VAXen, HP9000s, Textronix 8560s,
etc; OS's were various Unix flavours, VMS, VersaDOS, and Regulus.
I have the man pages for it, the assembler and linker, the c.out format it
produced, etc if those are any use/interest.
Noel
> From: Fritz Mueller
> This seems the best place to start with the LA this weekend then.
I'm going to respectfully semi-disagree! I think that at this point there's a
good chance we can localize to within a gate or two before we start applying
test instuments.
My thinking starts with two pieces of data; i) your discovery that when the
MM trap happens, the end of the pure text segment contains a fragment of code
>from 04000 lower in the text, and ii) the data that the location in main
memory where that _should_ have been is full of zeros - i.e. never been
written into.
The latter is, I think, due to the fact that Unix clears all of main memory
on startup; I think it's just chance that that memory hasn't been used yet
for something else, and is still 0's. (Unix does clear main memory in a few
places during regular operation - e.g. when expanding the stack, the newly
added area is 0'd - but in general, e.g. when swapping in a pure text, it
doesn't seem to bother, which makes sense since it's all about to be
over-written anyway.)
Anyway, those two, together with my previous analysis that this was unlikely
to have happened when the text was first being read in from the file, block
by block, lead me to believe that the likely cause is that the BAR on the
RK11 skipped up a whole bunch (setting the 04000 bit at some point) when it
was reading the pure text back in from the swap, and skipped writing into
that zero-filled block of main memory, putting the stuff that should have
gone there up 04000, instead.
(Why it's swapping the text back in is too complicated to be worth explaining
here; anyone who _really_ wants to know should look here:
http://gunkies.org/wiki/Unix_V6_internals
in the last section, "exec() and pure-text images".)
It's easy to confirm all these suppositions/deductions fairly easily, without
having to connect up, configure, etc the LA: we can just stop the machine
after the text is first read in (in xalloc()) from the file-system, and
confirm that the text looks good there; if so, either the swap-out (albeit
unlikely, since that doesn't account for the 0's) or subsequent swap-in had
an issue. The latter would be easy to confirm: just halt the machine after
the text is swapped in, and see what the RK registers contain.
At that point, as I said, we'll know to within a few gates where the issue
is, and then it'll be time to bring out the LA.
Actually, a plain oscilloscope would do; it's interesting to recollect that
these machines were designed and maintained without benefit of a LA, purely
with an oscilloscope! We're so spoiled now! :-)
Noel
> From: Fritz Mueller
> is it possible for you deduce where Unix _should_ be placing these "bad"
> bits (from file offset octal 4220)?
Yes, it's quite simple: just add the virtual address in the code to the
physical address of the bottom of the text segment (given in UISA0). The VA
is actually 04200, though: the 04220 includes 020 to hold the a.out
header at the start of the command file.
So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
obviously an interesting number.
> Maybe a comparison of addresses where the bits should be, with
> addresses where the "bad" copy ends up, could point us at some particular
> failure modes to check in the KT11, CPU, or RK11...
Here's where it gets 'interesting'.
Executing a command with pure text on V6 is a very complicated process. The
shells fork()s a copy of itself, and does an exec() system call to overlay
the entire memory in the new process with a copy of the command (which sounds
fairly simple, at a high level) - but the code path to do the exec() with a
pure text is incredibly hairy, in detail. In particular, for a variety of
reasons, the memory of the process can get swapped in and out several times
during that. I apparently used to understand how this all worked, see this
message:
https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html
but it's so complicated it's going to take a while to really comprehend
it again. (The little grey cells are aging too, sigh...)
The interesting point is that when V6 first copies the text in from the file
holding the command (using readi(), Lions 6221 for anyone who's masochistic
enough to try and actually follow this :-), it reads it in starting from the
bottom, one disk block at a time (since in V6, files are not stored
contiguously).
So, if it starts from the bottom, and copies the wrong thing from low in the
file _up_ to VA:010200, when it later gets to VA:010200 in the file contents,
that _should_ over-write the stuff that got put there in the wrong place
_earlier_. Unless there's _another_ problem which causes that later write
to _also_ go somewhere wrong...
So, I'm not sure when this trashage is happening, but because of the above,
my _guess_ is that it's in one of the two swap operations on the text (out,
and then back in). (Although it might be interesting to look at PA:165600 and
see what's actually _there_.) Unix does swapping of pure texts in a single,
multi-block transfer (although not always as an integral number of blocks, as
we found out the hard way with the QSIC :-).
So my suspicions have now switched back to the RK11... One way to proceed
would be to stop the system after the pure text is first read in (say around
Lions 4465), and look to see what the text looks like in main memory at
_that_ point. (This will require looking at KT11 registers to see where it's
holding the text segment, first.)
If that all looks good, we'll have to figure out how to stop the system
after the pure text is read back in (which does not happen in exec(),
it's done by the normal system operation to swap in the text and data
of a process which is ready to run).
We could also stop the system after the text is swapped out, and key in
a short (~ a dozen words) program to read the text back in from the
swap device, and examine it - although we'd have to grub around in the
system a bit to figure out where it got written to. (It might be just
easier to stop it at, say, Lions 5196 and look at the arguments on the
kernel stack.)
> a suggestion here to check the KT11 address translation adders ... A
> bug in one of the carry lookahead generators used between the bit
> slices of that adder could cause a mistranslation on only a fairly
> selective subset of virtual addresses
This could be happening, but from the reasoning above about the order that
the blocks of the text are read in, something would have to interfere with
the later read of the higher memory blocks, too, no? So I'd discount the KT11
_for the moment_.
> *IF* that's the case and we can chase the IR trace upstream to the
> place of an unlucky mistranslation, it will be pretty easy to track
> down then in the hw and fix.
It'll be interesting to look at the text after it's read in (i.e. before it's
swapped out). If it's OK there, that's pretty conclusive that it _can't_ be
the KT11 - because from then on, the kernel doesn't _do anything_ to that
binary, except swap it out and in with the RK11. And since those are both
single I/O operations (with swapping on the RK11, at least, which can do
multi-block transfers), _and_ the bottom of the text segment comes in OK (so
the RK11 is being set up with correct disk and main memory addresses for both
the out and in), I can't think of a fault _elsewhere_ in the system that
could cause that 'stuff winds up in the wrong place' error.
I know this is complicated, but look at the bright side: we started with
three apparently un-connected problems:
* R5 trashage
* an 'impossible' MM fault
* bad text data
The first one turned out to be non-existent (my fault in interpreting the
kernel stack in the process core dump), the second was also not really there
(although a hardware fault in the console gave us bad data, so there really
was a hardware issue there), and now we're down to one - albeit a tricky one.
So we were dealing with two un-related hardware problems - now we're down to
one, and hopefully soon will have it isolated to a single sub-system!
(And thanks to whoever gave us the voltage tip, that fixed the first one.)
Noel
On Fri, 2019-02-08 at 12:00 -0600, cctalk-request at classiccmp.org wrote:
> Re: Looking for: 68000 C compilers
There is a GNU OS for the Atari 68k-based ST, TT, and Falcon computers
which might be fun to play with. It is called MiNT. FreeMiNT and
SpareMiNT are two distros. They are available. Aranym/Afros are
current projects. Of course tools are available within.
Best regards,
Jeff
For those who are intrigued by the VAX-11/780, here:
https://www.ebay.com/itm/321399703349
If you can't have a real 780, at least you can have the prints! :-)
Noel
Jack Harper <harper at secureoutcomes-hq.com> wrote:
> I got both drives into the rack this past weekend and I am an old guy
> (67) - I carefully stared at the thing before I started and finally
> figured out that I could, in fact, lift the drive from a waist high
> cart for a few seconds, but definitely could not lift it or lower it
> vertically with my arms - no way - and I would have one shot at
> getting the drives into the rack on the rails.
Harbor Freight sells a nice hydraulic lift table for under $200 that
I have found very useful for that sort of thing. It doesn't go up
very high (like for the top of a rack), but I used it with some wood
blocks to lift a DEC ES45 Alpha system into a rack by myself.
500 pound capacity, 28.5" lift height, $170
https://www.harborfreight.com/500-lbs-capacity-hydraulic-table-cart-61405.h…
1000 pound capacity, 34.5" lift height, $260
https://www.harborfreight.com/1000-lbs-capacity-hydraulic-table-cart-69148.…
Alan Frisbie
Hi Cindy,
Thanks for the email. We have a large inventory of HP gear in Minneapolis. I
have a lot of older HP stuff too from the 1980's and 1990's to current. I
don't know what you are looking for HP1000's? old workstations and servers?
Here is our store but I only listed a very small amount of our stock.....
https://store.flagshiptech.com/
Brad Ziton
HP Product Manager
SKYPE: bradz at flagshiptech.com
Trillian: BradZFTI
bradz at flagshiptech.com
3939 County Road 116
Hamel, Minnesota 55340
(800) 416.8900
t: 763.516.1346
f: 763.516.1310
c: 612.708.3960
RS/6000 pSeries ? AS/400 iSeries ? Sun Microsystems ? HP9000 ? HP Proliant ?
Cisco ? Dell
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
I'm wondering if anyone knows of any CP/M software using GSX-80, which
could be an interesting demo, or game. I have found Kasekastchen (
http://atariage.com/forums/topic/244781-kaesekaestchen-a-new-gsx-based-game…)
(misspelled without accents to make the mailman happy), but it mostly just
freezes after loading GSX-80 on my TS-803 so far (under the 'remote
processor' version of the OS at least).
Thanks,
Pat
> From: Jon Elson
> I'm thinking it is bad memory. ... I think it is just a bad memory chip
Nothing so simple, I'm afraid! The memory actually contains:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
and it's _supposed_ to be holding:
PA:171600: 110024 010400 000167 000016 010500 010605 010446 010346
This together with Fritz's discovery of that first 'bad memory' pattern _elsewhere_
in the binary for the command makes it look pretty likely that some sort of other
error has wound up with stuff being put in the wrong location.
Noel
I know there's an old (I think) official Sega Genesis devkit that's,
erm, "around" on various console homebrew sites. No idea which exact C
compiler is included, but it's not too difficult to find.
> From: Brent Hilpert
> what about the refresh circuitry of the memory board?
> ...
> It might also explain why a number of 4116s were (apparently) failing
> earlier in the efforts ... replacing them might have just replaced them
> with 'slightly better' chips, i.e. with a slightly longer refresh tolerance.
Ooh, excellent idea!
Noel
> From: Fritz Mueller
> It looks like the question boils down to either "how did that part of
> the binary get to that part of memory?", or "how did we end up
> executing out of that part of memory?"
More the former, I think.
UISA0 contains 001614, and physical memory at 0161400 does contain the first
few instructions of the command's binary, so that 01614 is probably correct
for the base address of segment (page) 0, which contains all the code for the
command. (Without looking through the OS's guts, I can't confirm, from interal
data structures, that that's where it decided to put the command's binary.)
The PC at fault time is 010210, which is correct for the frame setup
function, CSV; and looking at the contents of the stack, registers etc makes
it pretty certain it had just done the "JSR R5, CSV" to get there. And
0161400 + 010210 = 0171610, which contains something completely different
>from what's in the command binary at 010210!
> Could still be a memory issue _elsewhere_ that lands us there, of
> course... Could also be a translation error lurking in the KT11, or a
> CPU bug not found by any of the DEC diagnostic suites.
Yup. Like I said, good news is we're down to one problem; bad news is it's
a Duesie!
Noel
> From: Mattis Lind
>> we've also looked at what's in memory at that location, and the low
>> part of the text segment seems to be correct, but there was junk at
>> the top, around the target of the JSR (i.e. at 'csv'). Not just one
>> word, but everything around that location was wrong, which would
>> suggest to me that the cause is not a simple memory failure there.
>> I've suggested to Fritz that we look at that again, to see if what was
>> recorded before is accurate
> Would it be possible to insert a breakpoint or halt and run the
> program, insert original instruction and single step?
I'm not sure that's going to tell us much: the latest development is that
Fritz looked at the actual memory contents again, and it is once again
trash; _almost_ identical to what was there before:
PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144
but with some extra 010000 bits:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
(It's not clear if this represents a real difference, or if that
front panel issue Fritz mentioned caused the contents to be displayed
incorrectly.)
The exciting thing is that if the latter really is what's in main memory,
that '16700 16152' at the PC of the MM trap could indeed generate the MM trap
we're seeing: it's "MOV 26364, R0", and that address is in segment (page) 1,
which is only 03500 long....
If so, i) we're down to one problem (good news), and our problem turns into
finding out how that section of the code got trashed (bad news). Which is not
going to be simple, alas, I suspect. I don't think it's the RK11, because
Unix reads the program image into system buffers in low memory, and that's
clearly working OK in the 'sleep;ls' case. (It may not use the exact same
buffers, though...) It then copies it out to the memory where it's going to
execute from, using an MTPI loop. So maybe the memory still has issues, or
maybe the MTPI isn't working with some main memory locations or or or...
Noel
This keyboard has now been sold!
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Leslie is preparing a list.
She has also contacted another friend who is quitting the biz, to see if
they want to get rid of equip.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
1 keyboard PN 3201072-01 still in plastic and foam (Type 5)
1 metallic type mousepad, never used
1 mouse 370-1170-01, used
1 cable 530-1594-01 used
1 cable 530-1662-01 new
1 cable 530-1442-02 used
1 battery holder that is plugged into the 530-1594-01, used, no battery
installed
These are in my stock. All fits in one box. Make offer.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Pics of equipment on request .
Hi, we occasionally get some.
For example, we have the following:
2x Phones ROLM 61000 in boxes (see photos) ('86 year of manufacture); Bunch
of (see photos):
FAX-MODEM USRobotics 33.6K Model 0459 PN: 00083907
FAX-MODEM USRobotics 56K Model 0701 PN: USR5686D
FAX-MODEM USRobotics 56K V.92 PN: 5686
Let me know what you think.
I'll keep you posted on any antique equipment we will be receiving.
Nick Makarovskiy,
nick at ictcompany.com
Office: +1-781-912-1717 x 710
Direct:+1-781-912-1710
Cell/WhatsApp: +1-617-309-8705
400 Tradecenter, Ste 5900
Woburn MA 01801
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> From: Phil Pemberton
> * Anything not on this list ;)
The TRIX project at MIT-LCS did a 68K compiler very early on (soon after the
first 68K wa released)x, using Steve Johnson's Portable C Compiler as a base.
Noel
At 12:26 PM 2/6/2019, Ethan Dicks via cctalk wrote:
>OTOH, at home, I'd had an Amiga since 1986 and used a variety of
>native tools (Lattice C later SAS/C, and various assemblers either
>commercial or from a Fish Disk).
Somewhere I have the DOS-hosted C compiler for the Amiga that was part
of the first developer kits. I think they were Sage-hosted for a while, too.
- John
Preowned Barcode Ltd
John Gallant
Halifax NS Canada
PH (902) 468 8210
Cell (902)719 6031
Email: sales at preownedbarcode.com
This gent has stuff from the 80s and 90s in the barcode and scanner
departments.
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Last May Steve auctioned off the assets, and and printer/plotter co bought
the name and website. Steve retired to Hawaii. All is gone L
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> Date: Sun, 3 Feb 2019 22:22:42 +0100
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Looking for Limited Function Board
> Message-ID: <20190203212242.GF24947 at Update.UU.SE>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> I'm restoring a PDP-8/a with the help of some
> friends. The CPU is now passing the MAINDECs I've
> thrown at it. The memory is a modern semiconductor
> board my friend Anders Sandahl made.
>
> This machine is pieced together from several others
> and the limited function panel I got does not match
> the backplane I have.
>
> My theory is the DEC simplified the design of the
> boardto cut costs and simpler design is not
> compatible. Mine is labeled (on the PCB):
>
> "LIMITED FUNCTION BD.
> 5411507
> 5011506C-P2"
>
> And the one I need is:
>
> "LIMITED FUNCTION
> 5411165
> 5011167"
>
> However, the picture I have of the other is not so
> good. I may have read the numbera wrong.
>
> I would very much like to buy one to finish this
> project.
>
> /P
F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att
flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett
originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r
det ju att ?terst?lla...
/A
> From: Paul Koning
> Another possibility occurs to me: bad bits in the MMU (UISAR0 register
> ... if UISAR0 has a stuck bit so the "plain" case maps incorrectly
> you'd expect to come up with execution that looks nothing at all like
> what was intended.
One would hope that the DEC KT11 diagnostic would check for this... but just
to be thorough, we have in fact written a short diagnostic which stores every
possible value in each UISA register and checks that it's correct. So unless
there is some sort of pattern sensitivity (e.g. when A is in UISAm and B is in
UISAn), that's not it. Also, and perhaps more significantly, when checked
after the trap happens, all the UISA registers and all the KISA registers
contain correct data. So, unless it's something where _sometimes_ one reads
UISAn and gets X when it actually contains Y, I'm not sure the SARs (PARs) are
involved.
> From: Jon Elson
> OK, here's a really complicated thing to try. If you know the physical
> memory address of ls when it has the problem
We do (see above), and we've also looked at what's in memory at that
location, and the low part of the text segment seems to be correct, but there
was junk at the top, around the target of the JSR (i.e. at 'csv'). Not just
one word, but everything around that location was wrong, which would suggest
to me that the cause is not a simple memory failure there.
I've suggested to Fritz that we look at that again, to see if what was
recorded before is accurate (i.e. if we see the same wrong contents), to make
sure we didn't make a mistake somehow.
> write a machine language program that loads a copy of ls into that
> location and then tries to read it back.
Yeah, it may come to that. One issue we've been having is doing specialized
test programmes; trying to run the C compiler fails. I don't know about the
assembler, though. And as Fritz mentioned, it takes hours to load a new disk
image. I think we've come up with a way around that, though; produce binary
of stand-alone tests elsewhere (I've often/always got a v6 running on
Ersatz-11 here), and load them into the /45's main memory with PDP11GUI.
Noel
So I've been helping Fritz look into his -11/45 problem, and things have
gotten to a point where I'd like to reach out for help, more eyes, etc.
I have to say, I spent almost a decade at the start of my career working on
PDP-11 hardware ('new build' DMA devices, as well as fixing broken stuff), and
software, and this is, I think, the most confusing and difficult problem I
have _ever_ seen on one. Hence the above...
What's _particularly_ confusing and difficult is that it seems like _three_
separate, un-related things all go wrong at exactly (2 of 3) or close to (the
other) the same time. And the machine now passes all the diagnostics that have
been thrown at it, particularly the KT11 and RK11 diagnostics (why this is
important will become clear). So here's what we've found to date.
The failure we're looking at is that an attempt to execute the 'ls' command
under Unix V6 fails; it gets a memory mangement fault, and dumps core.
AFAICT, the shell successfully forks, and its attempt to do an exec() of 'ls'
sort of works (more below), but a few instructions in, we get the MM fault - but
there's even more wrong when that happens (details toward the end below).
I've been looking at the core dump produced by the process, which gives me the
registers at the time of the trap, the user's stack, etc - but not a copy of
the binary code - the 'ls' command is a so-called 'pure text', i.e. the binary
is segregated into separate, potentially shared, read-only 'segment(s)' (only
1 in this case) of the PDP-11's User mode address space, and is not included
in the process dump.
(I use the term 'segment', which is actually what DEC called them in the first
version of the PDP-11/45 processor handbook, because that's what they are, not
pages, as pages are on most systems. I assume they changed to 'page' for
marketing reasons. And please, can we hold debate about this and focus on the
problem? Thanks! :-)
I do have the ability to look at the binary that it _should_ be executing, by
examining the command in its file. Also, Fritz has worked out that he can
patch the MM trap vector (before trying to do the 'ls') to halt the machine
when it happens, so he can read out all the KT11 registers, look at the actual
program in main memory, etc.
First oddity - the problem is dependent on the location of the command in main
memory! If Fritz says "sleep 360 &", to run a trivial command in the
background, and _then_ says 'ls' - it works (so we know the binary of 'ls' on
disk is OK)! We _think_ this is because the process executing the 'sleep'
takes up a chunk of main memory, and thus changes the location of the process
executing the 'ls'.
The problem is that I'm reluctant to try and change anything (e.g. to have the
OS print out anything) because that will change the location of things, and we
may (likely?) will not get the problem. With nothing changed, it _reliably_
fails - I've looked at two different core dumps, and all the essential data
(registers, user stack etc) are identical. The KT11 registers all seems to be
the same, too.
So, on to details.
I'm pretty sure the command only gets a few instructions in before it blows
up. Here are the process' registers, and the _entire_ contents of the user
mode stack:
R0 177770
R1 0
R2 0
R3 0
R4 34
R5 444
SP 177760
PC 010210
060: 000000 000020 000001 177770 177774 177777 071554 000000
010210 turns out to be the first word in 'csv', which is an internal routine
which PDP-11 C uses to build a stack frame - _every_ C routine starts with
a "JSR R5, CSV" instruction as the first thing it does.
So looking at the stack (which looks good; it contains a valid 'argc' and 'argv'
that the process would be started with), and the registers, I'm pretty sure
it does these starting instuctions OK:
start:
setd
mov sp,r0
mov (r0),-(sp)
tst (r0)+
mov r0,2(sp)
jsr pc,_main
_main:
jsr r5,csv
and then blows up on:
csv:
mov r5,r0
So it's the 8th instruction in that blows up (*): but not only is what's in
memory at that location _not_ 'mov r5,r0', it also gets an MM trap that
makes no sense.
(*: In user mode: if you don't have an FPP, the first one will trap, which
UNIX ignores.)
Fritz has looked at the KT11 register when the trap happens, and the PARs and
PDRs all look good. The SSRs contain:
> SSR's: 040143 000000 010210 000000
SSR2 gives the PC at the time of the fault (again 010210); SSR0 shows:
Abort - segment (page) length error
User mode
Segment (Page) 1
which is the first thing that's wrong - neither the instruction that's
_supposed_ to be there (next), nor the one that's _actually_ there, contains
any reference to segment 1!
The _actual_ code it's trying to execute is:
> 171600: 016162 004767 000224 000414 006700 006152 006702 006144
(Per UISA0, text base is 0161400, plus a PC of 010210, gives us 0171610, which
is right in the middle there.) That does not, alas, look anything _at all_
like what's _supposed_ to be there, which is:
010200: 110024
10400 mov r4,r0
167 jmp 10226 (cret)
16
PC-> 10500 mov r5,r0 (start of CSV)
10605 mov sp,r5
10446 mov r4,-(sp)
10346 mov r3,-(sp)
So somehow the command (at least, this part of it - Fritz is going to check on
the first few instructions, but I'm pretty sure they will be OK) has gotten
read in wrong - but that's the least of our problems! 06700 is 'SXT R0', and
neither that nor 'MOV R5, R0' can _possibly_ cause an MM violation - least of
all one on segment 1 (this code is in segment 0)!
I could see there having been an error reading in the command binary (e.g. maybe
the RK11 has an issue), but WTF is happening here?
Just to make things triply confusing, R5 contains trash! The 'JSR R5, CSV' _should
have put the old PC in R5; but that call to CSV is at 030, so R5 _should_ contain
034, not 0444.
Needless to say, this is a real head-scratcher. What's confusing the heck out
of me are the three separate issues, all happening together - R5 contains
junk, the spurious (?) MM trap, etc.
The bad command binary in main memory could be caused by any number of things:
to get it, Unix reads file system blocks off the disk into buffers in low
memory, and then writes them out to the user's memory with MTPI. So an RK11
glitch could be doing it, but also a KT11 problem, etc.
I'm having a hard time seeing a common thread here - maybe a KT11 issue? But
how would that cause R5 to contain trash? That should only involve the KB11.
And the JSR R5, CSV must have been executed more-or-less OK, otherwise how did
it wind up at CSV?
I was wondering if some noise could be causing it - some sort of pattern
sensitiity - but how is it bashing R5 _and_ causing a spurious MM trap? That's
some glitch!
Most of the data above (e.g. SSR contents at trap time) has been re-checked,
and Fritz is going to check the rest (e.g. actual main memory contents for the
start of the code, and the user's stack - to check that the process' core dump
worked OK - although given the consistent stack contents, I'm expecting those
to be good).
I suggested to him that the time had come to apply the logic analyzer; I'd
love to see (from the IR in the CPU) the instruction that faults, and where it
came from. And also what the bus cycle is that's causing the fault; is it the
instruction fetch (possibly) or something that instruction is trying to do?
Does anyone have any comments/insight that could help work out what's going on
here? Or suggestions on things to look at? If so, thanks!
Noel
I don't get replies from here yet, so I have seen no replies to my posts,
nor the posts themselves.
There is a shop that has been in biz for over 25 years that is closing in
California.
I asked for anything old Apple, Sun, HP, IBM, and any old keyboards.
She will call me back tomorrow. She never dealt with the off brands, just
major maintenance contracts.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Unfortunately, they have already scrapped everything! They were distributors
of old HP and IBM hardware.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
If anyone out there needs an EIA distribution panel to go with their
DZ11, here:
https://www.ebay.com/itm/321225351590
are some of the 8-line ones (as used in the later modular back panel
system). The seller (Efi) is good people.
Noel
Daniel Fecteau
6025 Arthur sauv?
Mirabel, Quebec
J7N 2W4
TEL: 450-969-1616 ext 101
Mail: save at savesysteme.com
He has a variety of Model M 122 key keyboards. Contact him if you are
interested.
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> From: Cindy Croxton
> I changed email providers, and received no emails for a week. If you
> tried to contact me, please ask again!
Perhaps 'test' was not an optimal Subject: line - a lot of people think that
flags a message they can ignore, and not even look at - which was not what
you wanted! :-)
Noel
Hi Al.
$ 60, plus shipping ?
I live close to Paris, France. Zip Code : 77310
( Payment through Paypal seems the only way ?? )
On an other subject, did you see my previous cctalk post on imaging HP 1000 L series Eprom ? Any interest ?
Best regards
Gerard
I own a HP 1000 L series 200
Cards are badly corroded at connectors level BUT some other parts are in very good shape.
I can offer,
HP "special SoS" processors : 1AA6-60004, 1AC5, 1AB5, 1AF5 ( - 60001 )
The set of (3) Eprom ....
I cannot image them, but I am willing to send them to someone that will do it.
Al. may be ?
The power supply seems in pristine state. Just have to check more closely if needed.
Other parts ? .... just ask.
"fee" : Eprom, free
Processors : shipping cost
Power supply : shipping cost + a little more for packing material and my time.
I am in France, close to Paris.
I changed email providers, and received no emails for a week. If you tried
to contact me, please ask again!
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
This looks like a project with a ton of potential for archviving media
without having to deal with the asshattery of the kryoflux people.
https://github.com/picosonic/bbc-fdc
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
> From: Fritz Mueller
> I've had a bit of time in front of the machine to repro this and take a
> look. What I actually see is:
> R0 177770
> R1 0
> R2 0
> R3 0
> R4 0
> R5 34
> R6 141774
> PC 000254
Argh. (Very red face!)
I worked out the trap stack layout by looking at m40.s and trap.c, and
totally forgot about the return PC (that's the 0444) from the call to
trap():
0001740 000013 141756 022050 000013 000000 000000 000000 000034
0001760 000444 000031 177760 000000 030351 177770 010210 170010
I clearly should have looked at core(V) in the V6 manual!
The R6 you have recorded is correct for just after the trap; that's
the kernel mode SP, which points to the top of the kernel stack,
in segment 6 (in the swappable per-process kernel area, which runs
>from 140000-1776).
So there is no R5 mystery, I was just confused. Back to the other two!
Noel
> From: Wayne S
> it might be a wonky filesystem. ...
> The corruption probably came because the entire disk was going bad.
This theory is contradicted by the fact (mentioned several times, including in
the message you were replying to) that doing a plain 'ls' bombs, but 'sleep
300 &; ls' works fine.
Noel
> From: Jay Jaeger
> This sort of situation, where DEC diagnostics run OK but UNIX has issues
> was reported to be not all that uncommon - to the point where the urban
> legend was that some DEC FE's would fire up Unix V6 as a sort of system
> exerciser.
Amusing! Never heard that; our -11's were never under maintenance, so DEC FE's
never worked on them.
> Make a copy of ls, and see if the copy also fails
It acts just like the original; fails when run by itself, runs OK when 'sleep'
is also running (in the background).
> From: Bob Smith
> We finally had the cpu backplane replaced
Ow. Not an option for Fritz, I expect. (I dunno - anyone have a spare /45
backplane?)
> From: Paul Koning
> Is there any way to attach a logic analyzer to various data paths on
> this machine?
I had suggested to Fritz that the symptoms led me to believe that it was time
to deploy a LA, especially since the MM trap only occurs once between him
typing 'ls' and the process failing - i.e. easy to trigger on.
He offered me the options of look at the IR or at the UNIBUS - I opted for
the IR so we can see _exactly_ what the machine _thinks_ it is doing! No
report back yet, though.
Noel
> From: Jon Elson
> Does the MMU classify what the error condition was
Yes, there are a series of bits in SSR0 to indicate the particular error:
'non-resident', 'length', 'read-only', etc (and also the segment number the
error's from). As my message mentioned, we're seeing the 'length' error bit
on, and for segment 1 (which the instruction isn't using).
> is it possible to borrow an MMU from somebody else?
Fritz does have a spare board, but it has known errors. We haven't thought about
borrowing one yet, it may come to that.
> If this fault could be caused by memory
Well, _some_ of it could. E.g. if the 'jsr r5, csv' is read as 'jsr r4, csv',
dropping the '1' bit in the register number, that would explain the wonky R5
content - R4 does contain the 034 that should be in R5, I have just noticed.
But that doesn't explain the bogus MM trap. Although I suppose there could be
several different problems, all at the same time.
> does this machine have a cache?
Nope.
Noel
Here's a question for someone who has been around long enough to
remember.
Why did none of the available PDP-11 Unixes support the TU-58?
I have looked at Ultrix-11, V7M and BSD 2.11 (didn't try 2.9
but I suspect if it isn't in 2.11 it wasn't in 2.9) and none
of them had support for the TU-58. Seems to me it would have
been a rather simple device to handle as it ran over a serial
line.
bill
Hi
I'm restoring a PDP-8/a with the help of some
friends. The CPU is now passing the MAINDECs I've
thrown at it. The memory is a modern semiconductor
board my friend Anders Sandahl made.
This machine is pieced together from several others
and the limited function panel I got does not match
the backplane I have.
My theory is the DEC simplified the design of the
boardto cut costs and simpler design is not
compatible. Mine is labeled (on the PCB):
"LIMITED FUNCTION BD.
5411507
5011506C-P2"
And the one I need is:
"LIMITED FUNCTION
5411165
5011167"
However, the picture I have of the other is not so
good. I may have read the numbera wrong.
I would very much like to buy one to finish this
project.
/P
> From: Bill Gunshannon
> Why did none of the available PDP-11 Unixes support the TU-58?
> I have looked at Ultrix-11, V7M and BSD 2.11
The 'TUHS' list might be more likely turn up the reasoning?
Noel
I have made a SA1000 adapter board for my MFM reader emulator. I did a
small run which seems to work so if you are interested email me to get
in on the next order. Prices may get a little better if I get enough
orders.
http://www.pdp8online.com/mfm/http://www.pdp8online.com/mfm/sa1000/sa1000_usage.shtml
I have used it for reading Shugart SA1004 and Quantum Q2040 drives.
Another has used it to replace drive in a TRS-80 Model II 8 Meg drive unit.
Some other items that may be of interest:
Dealing with stuck head problem with Quantum Q2040 drives
http://www.pdp8online.com/q2040/q2040.shtml
Using a DAC to pull the head servo to recover otherwise unreadable data
>from DEC RD53 drive. Also procedure tried for Q2040 but data had been erased
so not successful.
http://www.pdp8online.com/mfm/head_servo/
If you were thinking of joining us for VCF PNW 2019 in Seattle then now is
the time to let me know!
The event is March 23-24th (Saturday and Sunday) with setup the day
before. We still have room for some more exhibits if you are interested in
joining us. If you are going to join us I need to know by Friday, February
8th. If you have told me you were coming but did not complete the
registration form, well, now is the time ...
A description of the event can be found at http://vcfed.org/vcf-pnw .
General information for exhibitors including pictures from last year, a
link to the registration form, and a FAQ can be found at
http://vcfed.org/wp/vcf-pnw-exhibitor-registration/ . Also, yell at me
directly if you have questions
Thanks,
Mike
mbbrutman at brutman.com or michael at vcfed.org
PS: Not exhibiting at the event but interested in unloading some tonnage?
We're doing a consignment area again, and that's open to everybody. Now is
a good time to start cleaning and testing things that you might want to
sell.
Evening folks,
I?m bringing a Sharp MZ80B back to life and have so far fixed a horizontal collapse problem on the video board meaning I can see what it?s prompting for at boot. I remember when I first got this machine back in 2003-ish I dismantled it and discovered some of the tape transport had melted and gummed up the automatic head mechanism.
Fast forward* 15 years and I have the transport in bits again on the bench and I can see that one belt has melted and another is on the way to collapse. Did we ever find a reasonable source of replacement belts? I know a couple of collector friends with 3D printers have printed replacements but this is new tech and I need old tech :)
Cheers!
*sorry, pun intended
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest private home computer collection?
t: @binarydinosaurs f: facebook.com/binarydinosaurs
w: www.binarydinosaurs.co.uk
Does anyone have any DC6525 tape cartridges they would be willing
to part with? One of the Expansion boxes on my VAX has a TKZ10
but none of the older QIC tapes I have can handle the format from
this drive.
bill
My google-fu is failing me; forgive me.
Is the Tandy DWP-220 daisy-wheel printer a rebrand/OEM of someone
else? In particular, can I find ribbons and font wheels under another
manufacturer?
KJ
My PDP 11/40 suddenly lost it's ability to boot RL02 disks except the XXDP
disk. I have two drives, both boot up an XXDP (I have more than one) just
fine, but any formerly-working RT-11 (v 5, 5.1, 5.3) no longer boots, it
just hangs. I have been troubleshooting, running the 11/40 XXDP tests, but
they seem to just hang too. And I am not a big fan of XXDP anyway. I have
cleaned the drive heads, the disks are ok. I can load BASIC just fine from
PDPGUI "tape" through the serial card (M7800)
Any off the cuff suggestions why this specific issue would arise? Power
seems ok, looking for dumb reasons that I missed. I have swapped out CPU
cards, does not make any difference. I am pretty sure it's a UNIBUS
interference issue, at least that's my working theory. I suppose there may
be an RT-11 boot instruction call or routine of the CPU that XXDP does not
exercise explaining why XXDP boots. Maybe RAM locations.
In the end I just have to work through everything, but I am open to
suggestions to help cut down the time spent diagnosing the problem.
Thanks in advance, I will be around tonight (East Coast USA Time)
Bill
Random question
would you prefer having, if you had to pick only one, the original PDP
11/70 or the newer "blue cabinets" PDP 11/70, assuming both were complete
configurations with racks of storage etc as they would have been sold, more
or less.
Assume space and power are not issues, consider just the machine itself.
Bill
Those reading through the recent "PDP-11/45 RSTS/E boot problem" thread here will know that I've gotten to some corners of my 11/45 CPU now that don't match up with the commonly available engineering drawings.
My /45 is an early serial number (#152). So far I've verified hardware differences on at least my M8100 and M8105 cards and spares, relating to parity error abort handling. I would really like to track down any of the following resources:
- PDP 11/45 system engineering drawings *earlier* than those currently available on bitsavers (Jun '74)
- Any PDP 11/45 backplane wire list (what looks to be a wire list in the currently available engineering drawings is actually only a breakdown of the power harness.)
- PDP 11/45 ECO information, particularly the following:
M8100 00003
M8103 00005
M8105 00005
M8106 00007, 00008, 00012, 00012A
M8110 00008
KB11-A 00015
Bitsavers seems to have a DEC-O-LOG for M8105, but this does not contain specifics on cuts and jumps for ECO 00005, referring only to the associated "kit". DEC-O-LOGs for the other processor boards are missing.
If anybody thinks they might have any of this info squirreled away anywhere, I'd really love to find out more about it!
Parts of the ECO's are pretty easy to figure, just by comparing the state of my existing boards to the '74 drawings. But other parts not so much...
thanks much,
--FritzM.
Hi,
I knew that since ~20 yrs, but I didn't know the affected gcc
version(s). According to http://toni.technetium.be/hacker/pragma.htm
this "special" pragma handling should be in gcc 1.34.
But I cannot find gcc 1.34. ftp.gnu.org has gcc-1.30.atari (where the
sequence doesn't exist), and gcc-1.35 (where it's "#if 0"ed).
Does anyone know where to find the source code of gcc 1.34?
regards,
chris
From: Jay Jaeger
> Here is what I have for drawings:
Wow. You have some very desirable stuff there! Let me point at a couple
of things of particular interest:
> B-TC-FP11-C-6 FP11-C (Print Set MP00038) December 75
> [M8126, M8127, M8128, M8129]
AFAIK, prints for the FP11-C are not available online:
http://manx-docs.org/details.php/1,9306
so those of us with an FP11-C would be particularly grateful if you could
scan those and make them available.
> EK-KT11C-MM-005 KT11-C, CD Memory Management Unit Maintenance Manual
Not available online; the earlier DEC-11-HKTCA-C-D KT11-C Memory Management
Unit Maintenance Manual is available online, but doesn't cover the -CD. This
one is in the fiche set, but it's a pain to work with (especially since my
fiche reader burned out its bulb recently :-), so it's a 'nice to have',
scan-wise.
> EK-MS11A-MM-006 MS11-A,B,C memory System Maintenance Manual
Agaih, not available online, but in the fiche. Ditto 'nice to have'.
Of course, anything you've got that's not online should be scanned
'eventually' (I have several of those myself, sigh).
Noel
> Sorry, but no. It?s grossly offensive for things that work perfectly well and that someone might actually find useful to go to scrap. There?s tons of useless and broken junk that our civilization can mine for scrap, we don?t need to actually destroy things that have actual value.
>
> If someone isn?t able to sell for the price they?d like to get, maybe the market won?t bear that price and they need to lower it. Scrapping should be a course of last resort, a way to recover value from something you can?t even give away, not a competing outlet for goods.
>
> -- Chris
While I also don't like scrapping out things that work or can be
repaired relatively easily, a saying I use in a variety of situation is
"don't force your limitations on me, I have enough of my own."
That said, I VERY much appreciate the free pile at VCFMW that allows me
to get rid of stuff that will go to a good home rather than go to
landfill or scrap (I DON'T DO EBAY!!!) Many times I find free to be far
to expensive for most people including myself (think
postage/shipping/prep time.)
> From: Fritz Mueller
> I would really like to track down any of the following resources:
> - PDP 11/45 system engineering drawings *earlier* than those currently
> available on bitsavers (Jun '74)
My KB11-A prints have an 'overall' date of "4/76" (on the front page), but
prints within the set seem to be older.
E.g. my M8100 prints are dated 2/72, and none contain any entries in the
'Revisions' block (lower left). However, they are marked as Rev. D, which is
newer than the KB11-A prints at Bitsaver, which are marked as Rev. C. So I
have no idea what changed to cause the rev update! (The first drawing, the
board layout, does show a listing for 'D', so maybe it was just a layout
change?)
The boards aren't all the same rev, though: the M8102 in mine are marked Rev.
C.
My KT11-D prints are dated "5/72" (on the front page), and the M8107 prints
are hand-marked as Rev. A, but the M8108 pages have mostly been replaced with
'yellow-sheet' updates with Rev. F, dated 6-'73.
Noel
At 07:13 PM 1/28/2019, dwight via cctalk wrote:
>When looking at the 45 minutes, also consider the various overheads involved.
>They are in business. Time is money.
Space is money. Organization is money. Information is money.
Advertising / listing for sale takes time and money. And it all only
gets worse if the item is heavy, dirty, or leaking.
- John
Hi,
I'm looking for some (technical!) information on the HP E2447AA or
E2447AB probe pod (for using a HP logic analyser to monitor a 68000 CPU).
I need to probe a DIP64 packaged 68HC000, but the E2447AA/AB are for PGA
parts. So I figured I'd make a "top hat" PCB to adapt the 68k to a bunch
of HP transition headers.
The E2447AA delays the UDS and LDS signals before passing them to the
analyser. Does anyone know how much of a delay is introduced compared to
the original signal?
Thanks,
Phil.
Kudos to Jesse for working with me offlist, I feel I've gotten a good deal. I appreciate the offers to help purchase, very much, but I got this taken care of directly with Jesse and I'm happy.
We have to understand, as others pointed out, that if no one speaks up for stuff at a price that can keep the parts houses in business then the parts won't be around. By the same token, the parts houses have to know we can't pay typical full price that corporations/military can. We must be willing to pay something above scrap value, of course.
I ask folks to keep an open mind and give Jesse a fair shake moving forward.
Best,
J
On Thu Jan 24 16:26:48 CST 2019, Electronics Plus sales at elecplus.com
said:
> I just got off the phone with Jesse at Cypress. He said he did not post
the
> gold and tantalum items on ebay. It is someone else, trying to cast a bad
> name on him.
Sorry, but this doesn't really check out. Jesse sent an email to the list,
original subject 'Hewlett-Packard 3000, 9000, Itanium (HP-UX & MPE/iX)
Servers, Storage Arrays, Replacement Parts, Maintenance, & Disaster
back-ups' and put his email and website in the message. Going to that
website, cypress-tech.com, we can go to the 'ebay store' page where the
apparently official ebay store of Cypress Tech is linked to. Following the
link, http://stores.ebay.com/Cypress-Technology-Inc we see that this is the
same seller as the original gold scrap ebay link,
https://www.ebay.com/itm/382505855460
Here is the list of reasonable possibilities that I can think of:
- Somebody sent a fake email, from a fake Cypress-Tech.com, and made a fake
ebay page with the sole purpose of defaming this person (I'll admit, not
entirely out of the realm of possibility if there were someone with a
grudge against him)
- Jesse does not maintain full exclusive control over the ebay store, and
one of his coworkers/employees have posted the gold scrap auctions without
his knowledge (I suppose this is possible)
- You've been lied to, or otherwise you made a mistake
Please correct me if I've made an error somewhere, and please don't take
this as a personal attack of any kind. I don't have any interest in this
matter really, but my BS detector was showing a reading, so I checked it
out a little deeper and that's what I found.
Best Regards,
Joe Zatarski
> From: Fritz Mueller
> it flagged a bunch of memory locations that weren't reported by my much
> simpler diagnostic (which only does all-ones/all-zeros passes looking for
> stuck bits at this point.)
What is is complaining about?
> The MAINDEC memory diagnostic is bulky and complicated, and it takes
> several minutes to re-download it after a power cycle, so it's not
> exactly convenient to use while troubleshooting.
Would it be possible to put it on a disk and boot it from there? If it's in
some documented format (e.g. .LDA), I can easily produce a Unix disk with it
on, if that would help (although loading the image onto the physical pack
would take forever, I guess - although you could let it run overnight).
It's probably not worth trying to devise a way to load individual files onto
a Unix disk over the serial line until Unix is working reliably, so the
program can run under Unix (otherwise a stand-alone program would have to
include file-system code).
> I'll probably be beefing up my smaller diagnostic with a few more tests
> (including parity).
One of the first things to add is to store each location's address in it during
a set-up pass, and check to see that it's still there during the checking pass.
> Went ahead and tried both RSTS and Unix again after the above repair,
> and saw the same fault behaviors from both (sadness).
Yeah, sounds like you still have memory issues (per the diagnostic grumping).
> I tried enabling trap on parity error in the MS11 CSR before running my
> diagnostic, but it didn't trap, even though it did flag parity error(s)
> in the CSR. So maybe I *also* have a bug I haven't yet addressed in
> parity handling within CPU.
Starting the CPU (i.e. 'START' switch) or an INIT instruction will clear
the 'trap enable' bit in the MS11-L CSR.
I'd modify your program to set it, and check to see if you're getting
parity error traps. (Clearly, if that hardware - either in the MS11-L,
or the CPU - isn't working you need to look at that first.)
> some of the earlier ones support setting a bit to determine whether
> parity errors will halt or trap the CPU
Huh? I was just looking at parity in the MM11-L and MM11-U (to see if
parity needed to be enabled on them, or if it's always on by default),
and I didn't see that. Also, there's no way I know of, on the UNIBUS,
for anything to halt the CPU (the QBUS has such as line, but not the
UNIBUS). Which memory has this feature?
> I'm curious how OS init code sniffs out what memory CSRs there are,
> determines their specific flavors and, in a heterogeneous system,
> determines how much address space is under the auspice of each CSR?
Unix V6 does nothing at all with parity (doesn't enable it in memory modules,
although the memory that was extant at the time - MM11-S, MM11-U, etc - did
support it as an option).
If one turned it on, the code _would_ catch the trap and 'panic' (print a
message and halt operation). It would be pretty easy to modify the code to
send a signal to the process if it happened in User mode. I'm not sure there's
much to be done if it happens in Kernel mode.
V6 sizes memory by doing a read every 0100 bytes (of the xxxx00 byte), looking
for success or a trap. If that succeeds, it clears the 32. sequential words
starting at that address, and then tries the next 0100. (So if you modified
the code to enable parity traps, you wouldn't hsave to deal with bad parity
left over from random contents at power-on....)
> The 11/45 prints show a jumper (W1, lower left of sheet UBCB) that
> looks like it would entirely disable Unibus parity error detection if
> removed.
Yup, that's what it looks like to me too..
> when I pulled and examined my UBC board (and also looked over my spare)
> no such jumper or any associated pads were anywhere to be found! So maybe
> this was either added/removed from later etches of the UBC?
Well, if you have an M8106, you do have a KB11-A; in the later /45 CPU, the
KB11-D, that has been replaced by the M8119 - but that still has W1! (The
KB11-D prints are in MP00039, 11/55 Vol 1.) I looked on my M8119, and W1 is
indeed there - it's a 0-ohm 'resistor' (single black band) just less than
half-way up the 4th column of chips, with a '1' next to it in the etch. The
M8106 board layout drawing (a couple of pages back from UBCB) does show W1 -
upper left corner of the board, next to E84.
Noel
all the 3000 stuff too? sorry to hear that Al.. ?back in the 80s would visit him nice guy glad to hear he is,still alive. ?ed#
...
-----Original Message-----
From: Al Kossow via cctalk <cctalk at classiccmp.org>
To: cctalk <cctalk at classiccmp.org>
Sent: Sat, Jan 26, 2019 07:49 PM
Subject: Re: OT Parts houses & scrappers
On 1/26/19 5:40 PM, ED SHARPE via cctalk wrote:
> Is? Larry? at? Crisis computer still around?
He is in Sacramento. Most of what he had was scrapped 15 years ago.
A large number of Bay Area people were involved in saving what could be saved.
I ended up with a lot of 9000/300 stuff. I didn't go after any 21xx stuff because
I had literally hundreds of boards. All were stolen from a storage container
about a year ago.
Gentemen,
All of you have at one time expressed interest in all or part of this
rack full of Alphaservers and one of you even talked about driving a truck
up from Montana and taking it all home.
Are any of you still interested?
First priority goes to anybody willing to come up here and pick up all or
part of the collection. I will consider shipping if that is what it comes
down to but the packing and transprotation will be expensive for the DS15
and extremely expensive for the other units.
--
Richard Loken VE6BSV : "...underneath those tuques we wear,
Athabasca, Alberta Canada : our heads are naked!"
** rlloken at telus.net ** : - Arthur Black
Is? Larry? at? Crisis computer still around?
Jay? used to? know him? too back? years ago.
Ed#
In a message dated 1/26/2019 6:35:21 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
> That sounds all well and good.? Until you something unexpected and
> unknown when you are at an auction for something else.? There's only so
> much self education you can do on a smart phone 10 minutes before the
> auction.
Start now with the research. You can gain quite a lot knowledge from
the various scrap forums and Youtube videos.
--
Will
> From: Electronics Plus
> I did not bring the stuff home. ... Call John Adler ... he owns the
> stuff in the sheds.
Now I am completely confused. What happened to the online spread-sheet that
some of us filled out? Did that go to him? If so, does the fact that we've
heard nothing means our offers were not interesting? If not, are we now
supposed to call instead?
Noel
> From: Fritz Mueller
> those PDP-11's have their toggles set for V6 single-user boot! :-)
Very observant! (Although I guess you've been using that a lot recently! :-)
> From: Paul Koning
> Was the 11/74 ever shipped?
I don't think so. (Well, I vaguely recall rumours of a couple going out on
beta-test; too busy to chase down where I saw that.)
Noel
> From: Paul Koning
>> Also, I still need images of a few things: -11/60 and -11/94 front
>> consoles, the original LSI-11 card, the KDJ11-E, and most of the DEC
>> QBUS boxes. (Yeah, I could try looking for free images
> Google "pdp11/60" turns up some good pictures, one showing the console
> panel closeup is from a UK computer museum.
Which one - 'computermuseum.org.uk'? Many of the pictures I saw online were
on pages with copyright notices. I was actually hoping someone who _has_ one
the the things I listed would take a picture and send it to me.
> It seems like a problem caused by taking the photo with flash; lit by
> ambient light it would probably look better.
They are in low-light locations; without flash it's a long exposure and I get
blurring because my hand isn't steady enough. And I don't feel like moving
them, or re-doing the lighting - too many higher priority things to do.
> A variant of the LSI-11 is the H-11 sold by Heathkit. .. it would be
> worth mentioning.
I've seen some go by on eBait, so I have an idea of the value, but I
couldn't get enthusiastic about listing them.
> Do you want to show the PRO system boards? And maybe the I/O boards?
Again, not enthusiastic enough to put in the work...
> In the discussion of boards, you might mention that "FLIP CHIP" often
> appears ... And there will be a "digital" logo, the 7-box kind.
OK, I will add that.
> (on older boards?All boards? Many boards regardless of age?)
It's spotty, and seems to die out later on. The -11/40 boards have it, but
for the -11/45 and -11/70, some do, and some don't. None of the KDF11 or
KDJ11 QBUS CPU boards do.
> The "Miscellaneous Digital Equipment Corporation PDP-11 Information"
> link lands me on a "Forbidden" error page.
Ooops. Fixed. Thanks.
> Zane Healy
> Don't forget the quad-height /73 board, it's much nicer than the
> dual-height boards.
That's the KDJ11-B, no? That's there.
> Is a /44 really worth that much now?!?!
Hey, one just went for more than that: eBait #183624991924, $3K! Admittedly,
that one was loaded, but the page does say "a number of factors will cause
them to vary considerably from the numbers given here ... Exactly which
peripherals and memory are included".
But I did adjust the number a bit - the boards are going for about $50 each,
and add in a BA11-A, it's probably $700 for a bare machine. Actually, I
really need to check all the numbers.
But I think I'd rather get the QBUS boxes sorted out first; I pretty much
only know the BA11's. If someone could tell me what later boxes to list,
above the BA23, (which I also need an image of), that would be very helpful.
Noel
In Japanese, but interesting.
http://www.geocities.jp/kugimoto0715/index.html
Talks about interfacing old school high current 5V interfaces like FDD or
SASI/SCSI into into lower voltage lower current RPI pins.
Warner
this? did not seem to? go though? when I? sent? as? a reply.--------------------------------------------------------------------
Glad? to? Hear? Jay -? I guess the? timeshare systems? were about the only? thing? I? ever? saw? those board? sets in.
ok~To? refile my? slightly? prior? ?message under? ?perhaps a better? title
I have? one? foot in each HP community? ?The? real production one and the? Collection of? vintage HP Gear? one.
I have had no complaints about? Jesse? ? from the? ?people? the? do data processing? with HP machines and have always? found him to be? friendly and timely in responses.
This? goes? for? Cindy? as? well.
Be? nice? to our? dealer? friends? they? can? help you. Maybe? not? today? but? ?you? will need? assistance some day and it is good to have them there.
well darn it... be? nice to everyone. eh?
Ed Sharpe archivist? for SMECC
In a message dated 1/25/2019 10:36:09 AM US Mountain Standard Time, cctech at classiccmp.org writes:
Kudos to Jesse for working with me offlist, I feel I've gotten a good deal. I appreciate the offers to help purchase, very much, but I got this taken care of directly with Jesse and I'm happy.
We have to understand, as others pointed out, that if no one speaks up for stuff at a price that can keep the parts houses in business then the parts won't be around. By the same token, the parts houses have to know we can't pay typical full price that corporations/military can. We must be willing to pay something above scrap value, of course.
I ask folks to keep an open mind and give Jesse a fair shake moving forward.
Best,
J
Sparcom Drive95 3.5 inch disk drive for the 95lx
Both? NOS in? box? was unsold inventory? from? computer exchange? ?in Phx? (my old? company...? ?these turned up in relatives? garage...)? ?one? has? manuals and all paper? work? one? has? no manuals and paperwork? but? NOS
I will offer? for? ?sale? and? ? ?even better if? you? buy? both. you? buy? both!? Offered? for? offers here? ? next? stop? ebay? if? no one here interested.? Sold? as? is.Ed#
Glad? to? Hear? Jay -? I guess the? timeshare systems? were about the only? thing? I? ever? saw? those board? sets in.
ok~To? refile my? slightly? prior? ?message under? ?perhaps a better? title
I have? one? foot in each HP community? ?The? real production one and the? Collection of? vintage HP Gear? one.
I have had no complaints about? Jesse? ? from the? ?people? the? do data processing? with HP machines and have always? found him to be? friendly and timely in responses.
This? goes? for? Cindy? as? well.
Be? nice? to our? dealer? friends? they? can? help you. Maybe? not? today? but? ?you? will need? assistance some day and it is good to have them there.
well darn it... be? nice to everyone. eh?
Ed Sharpe archivist? for SMECCIn a message dated 1/25/2019 10:36:09 AM US Mountain Standard Time, cctech at classiccmp.org writes:
Kudos to Jesse for working with me offlist, I feel I've gotten a good deal. I appreciate the offers to help purchase, very much, but I got this taken care of directly with Jesse and I'm happy.
We have to understand, as others pointed out, that if no one speaks up for stuff at a price that can keep the parts houses in business then the parts won't be around. By the same token, the parts houses have to know we can't pay typical full price that corporations/military can. We must be willing to pay something above scrap value, of course.
I ask folks to keep an open mind and give Jesse a fair shake moving forward.
Best,
J
On Thu, 24 Jan 2019, John H. Reinhardt via cctalk wrote:
> I also know I think other have their dibs in first.? But if they wash out...
Thanks John, I will keep you in mind.
--
Richard Loken VE6BSV : "...underneath those tuques we wear,
Athabasca, Alberta Canada : our heads are naked!"
** rlloken at telus.net ** : - Arthur Black
Holly smokes... 1st, Cindy thanks for calling me and vouching for me on
this list but let me clear something up here....
A. the ebay ads are mine and I put all content up there.
B. there reflects different locations (Largo, Clearwater, Land o lakes)
all around the Tampa area. We have been in that area since about 1995
and address have changed several times because we have moved .
C. The ebay ads are not all corrected with the current address since I
didn't thing that was going to be any kind of issue ever. I have like
400 running ads and you have to individually correct each one.. again, I
really never and up until this moment thought it was ever an issue since
selling on ebay since 1997.
D. some of the older 1k and older board ship from Pittsburgh because
thats where I split my time between Tampa and Pittsburgh and the really
old stuff is in Pittsburgh.
E. I never even posted my ebay stuff on here, I did an intro and posted
some stuff I was looking for.. Heck, I never even contributed to the
ebay thread.
Jesse
I have? one? foot in each HP community? ?The? real production one and the? Collection of? vintage HP Gear? one.
I have had no complaints about? Jesse? ? from the? ?People? the? do data processing? with HP machines and have always? found him to be? friendly and timely in responses.
This? goes? for? Cindy? as? well.
Be? nice? to our? dealer? friends? they? can? help you. Maybe? not? today? but? ?you? will need? assistance some day and it is good to have them there.
well darn it... be? nice to everyone. eh?
Ed Sharpe archivist? for SMECC
In a message dated 1/25/2019 10:18:12 AM US Mountain Standard Time, cctech at classiccmp.org writes:
Hello to all IBM 5100 owners,
I have started disassembling and commenting the Executable ROS of the 5100
that a kind soul has exctracted and provided me with the dump.
I've come across an inconsistency with the Maintenance Information Manual
as found on the net. I have both SY31-0405-2 and SY31-0405-3.
The issue is the description of the control I/O commands for device 1
(non-executable ROS selects). The manual says bit 12 is APL select and bit
13 is BASIC/Common select (page C-4), and that matches the block diagram
on page 5-20.
But in fact, the code uses the bits as defined for the 5110 (12=select
BASIC, 13=select APL, 14=select Common) and therefore, the 5100 must be
different from the system described in the MIMs.
So here are two questions:
- Does someone have a newer version of the MIM, i.e. SY31-0405-4 or greater?
A scan would be wonderful, especially because the scans for the
available MIMs are horrible...
- Are there known major revision changes in the 5100 line?
Christian
PS:
I really mean 5100, not 5110 or 5120 ;-)
Cypress Technology, Inc. is a HP hardware vendor specializing in selling
and supporting Hewlett-Packard HP 3000 (MPE/iX), 9000, and Itanium
(HP-UX) servers, workstations, parts, and all related peripherals. We
offer HP hardware from the early 1990's to the current date.
We offer but are not limited to the following HP items:
HP IA64 Itanium Integrity servers
HP 9000 Enterprise HP-UX servers
HP 9000 Visualize HP-UX workstations (PA-RISC and Itanium)
HP 3000 MPE/iX PA-RISC servers (aka e3000)
HP 1000 Series classic servers, parts, and peripherals
HP VME Industrial workstations, VME CPU boards, peripherals, and parts
HP ABB Advant Stations / RTA Real Time Accelerator platform / OSC / 800xA
HP Memory, disk arrays and drives, tape drives, CPUs, data
communications, & networking solutions
HP Enterprise Storage, XP, 3Par, Hitachi, EMC... Disk Arrays and drives
HP spare parts for all lines
We specialize in HP servers and workstations that support the following OS:
Linux, HP-UX, HP Unix, MPE/iX, OpenVMS, and MS Windows
. Contact us if you want a price quotation on any HP servers,
workstations, hardware, or services.
. Contact us if you wish to sell or trade for any hardware.
. Contact us if you have any questions.
. We offer hardware and software support.
. We offer migrations service for HP-UX and MPE/iX platforms.
. We provide parts and servers for discontinued HP items
. We sell to large and small corporations, World governments, military,
suppliers, re-sells, and end-users
. We buy off-lease bulk and surplus hardware
. We ship and export Worldwide to every country.
www.Cypress-Tech.com
Thank you
Jesse Dougherty
Cypress Technology, Inc.
Land O Lakes, Florida USA
Phone 888-954-3414 / (cell) 412-589-3779
jesse at cypress-tech.com
jesse.cypresstech at gmail.comwww.linkedin.com/in/jessedougherty