Weirdstuff has been offered an AS400 Model 170 located in a data center.
If anyone is interested in purchasing it, let me know off list - please
include the approximate price you'd be willing to pay for the critter.
I'll pass your info on to Weirdstuff so they can decide whether to make
a bid on it or not.
Note: I am not affiliated with Weirdstuff other than as a paying
client. They don't like to see vintage gear scrapped anymore than I do.
Regards,
Lyle
--
73 AF6WS
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
> > On Sep 5, 2016, at 9:30 AM, Josh Dersch <derschjo at gmail.com> wrote:
> >
> > At the LCM, I used an Apple II to test out the Alto's memory -- the
> > Alto II XM uses 4116 RAM chips. I swapped in a row at a time and wrote
a
> > little BASIC program to test for obvious errors. This was
> > time-consuming, but eliminated the obviously bad chips, which helped
immensely.
>
> Oh, that's so simple and clever! Are these 16k chips? I don't have an
Apple II,
> but I wonder if I could use the same trick and plug them in my HP 85
> for which I just managed to burn the service ROM, which has a memory
> test built in.
Josh,
I checked, and the mysterious HP 1818-1396 or 1818-0341 RAM chips used in
the HP-85 appear to be NEC uPD416-2 or MOSTEK 16k chips. They appear to be
pin for pin, voltage and speed compatible with the MOSTEK 4116-3 used in the
Alto. So it looks like I could check the Alto Xerox II-XM RAM chips on my
HP-85.
8 at a time, that might take a while :-). Thanks for the tip, I'd never have
thought about it!
Marc
> From: Jerry Weiss
> I'll give that a try.
Please let us know how you make out with it! :-)
> I've been making do with the SMS 1000 manual for the basic settings as
> well.
Yeah, that's better than nothing. I just looked over my notes from looking
into the CMV-x000, and alas I don't have any useful data to report (yet).
> I ran a different diagnostic w/o parity testing enabled.
That's kind of odd; the top block of results make it look like it's dropping
the 0400 bit (e.g. "S/B", which I assume means 'should be', = 161612, and
"WAS" = 161212 makes it sound like it dropped the 0400 bit); but the block
below makes it look like it's picking that bit (it shows 0 and 0400 under the
S/B and WAS columns for that location).
Eh, no biggie; clearly the 0400 bit has issues! ;-)
> I see stuck bits and address decoding problems. It looks like some
> memory addresses return the contents of another address.
Not sure I see that happening?
If your CPU is an 11/73 (which can directly 'access' [hate that verbism :-]
all of memory from ODT, unlike the 11/23 which is restricted to the bottom
256KB), try playing around with a failing location, and its alternative,
directly, and see if a store of random data into one can be read back directly
>from the other; e.g. set 03561212 to 0, store 0123456 in 03561612, and then
try reading 03561212, etc. Then go back to 03561612 and see if you get
0123456 back when reading it. Etc, etc.
That should quickly verify if the problem is just some locations which
drop/pick bits, or if there are addressing issues.
> I may just clip the power lead on the chip I think is faulty to confirm
> I have the correct target.
I looked at my CMV-x000 boards, and on all of them, the chips are soldered in,
not socketed (which most of the other ones I looked into had, which made
working out the chip<->bit tables very easy - pull random chips, and see what
happened :-).
But your proposed move should let you identify if you have the right
chip. Once done, you might want to check low memory from ODT to make sure you
don't have the banks inverted (i.e. what looks like the top bank is not in
fact the bottom). It probably wouldn't boot the diagnostics, if so, but it'd
nice to find out directly!
> Hopefully the bit ordering matches the board marking and bottom row is
> the highest address of memory banks.
Please let me know what the layout is, and I'll start the Computer History
wiki page for this board with that info.
Noel
> From: Jerry Weiss
> The first is an MSV11-PL 512KB-Q-Bus 22bit.
> Dead to both CSR and Memory address access in ODT.
> ... before start poking around with my scope ... can recommend a
> particular methodology to finding the fault.
Well, the CSR and RAM address detection circuits are separate (page 5 of 11
in the drawings), so since both are not responding, it has to be something in
common: perhaps something on the input side like a bus receiver (e.g. BSYNC,
pg 8), perhaps something on the output side like a control line driver (e.g.
BRPLY, same page), or some of the common circuitry that drives it (e.g. TRPLY
generation on pg. 5).
The way to tackle this is to write a two instruction loop that reads the CSR
(that will be easier to grok than RAM access); it will need a NXM trap
catcher which just does an RTI, too; and don't forget to set up the SP. Then,
pick some likely point half way along the signal path (e.g. MSEL, on the
right hand edge of pg. 5), and see if that's doing what it should. If no,
start moving back upstream; if it is OK, start going downstream from there.
> The second board is a CMV1000 that probably has a bad Memory Chip.
> I don't have either prints or a manual for this board.
Yes, either/both for this, and the sister CMV4000 (same board with 256K
chips) would be really fantastic to locate. I'm in the process of working out
what all the jumpers/mean do, and will work out which chips correspond to
which bits, and document them, like this page:
http://gunkies.org/wiki/CMV-504
However, we're not there yet for this card, so...
> I was expecting bad and xor to be 16bit values, but they appear to be
> mostly 22bit addresses. But then again this isn't a DEC board.
That shouldn't make a difference. I can't make head or tail of the output
either; can anyone else help? (I don't use DEC diagnostics, I have rolled my
own PDP-11 memory diagnostic.)
> The board itself is labeled with bits 0-7 P0 P1 8-15 across the top
Well, that is a good hint... :-)
> Any suggestions as to which chip might be suspect?
Step A is to find out what the failing location(s) are, and what the bad data
is. So either figure out the DEC memory diagnostic output, or roll your own
(you can have mine if you like, I have Unix assembler source, or I can give
it to you in .LDA binary).
Noel
Hi
A friend of mine died recently; he was amongst many things an electronics tinkerer and has a closet full of small parts in bin cabinets (resistors, capacitors, ICs, transistors, hardware, etc.). The ICs look mostly old. His wife and kids have no interest and would like to find a good home for these parts rather than recycle the lot.
They are in Palo Alto CA
Anyone interested in using them could just pick them up in the next week or so.
Any other ideas? Really hate to see these go to recycle.
Tom
(650) 941-5324 <tel:%28650%29%20941-5324>
Hello gents, seeking some advice. I recently brought home my IBM 3741 Data
Station that has been in controlled storage since the late 90?s and was
working at that time. Given almost 20 years has passed, what would be the
best way to power it back up? I believe I have a variac of sufficient size
around and I'm assuming it's a linear power supply but any advice would be
appreciated on the matter.
Thanks,
Cory
From: Paul Koning
> Some IBM systems ... have a "2315" drive which is an RK05.
Yeah, I think that was the original source of these packs. The Diablo 30/31
drives (used on the RK11-C controller before the RK05 was created) were
designed to use 2315 packs.
> From: Tony Duell
> My intention was to put the hub on a spare spindle .. put the platter
> on, turn it round by hand and use a lever-type dial gauge to get
> minimum run-out.
One of the people I buy PDP-11 parts from reports that he actually did this
(using the exact procedure you describe) BITD. Apparently there's some
multi-platter pack that has the same exact platter as the RK05 (2315) pack,
and he had some damaged RK05 packs, and moved platters from the bad
multi-platter pack to the RK05's.
Noel
> From: Paul Koning
> Semiconductor memory, right?
Yup.
> A possible reason would be that the address drivers for that bit, or
> the address decoders in that chip, are busted. The result would be that
> reads and writes always touch the same address in the chip.
Oooh, good point. That's a better explanation of the symptoms than mine,
since it answers the thing that was confusing me ("why it can be either set
or reset with a write, but freezes in one state for reads").
A fully-populated 64KB MS11-J card has 4 rows of 16Kx1 chips, so if the
machine ever runs again, the first thing to check is to see if that bit at
040000 (or 0100000, if it's a larger than 32KB card) is tied to that bit at
0; if not, it's the addressing circuitry in the chip. (Looks like E75, but it
might be E72).
> The fact that other bits repeat every 20 also suggests issues with
> addressing logic.
That I don't think is a memory chip issue, since it causes the entire word to
repeat, and on that card, each bit of the word is in a separate chip.
> From: Jim Stephens
> Is there a hint as far as the affected hardware in that the ODT is
> working, but the ram is not? The rom that is running ODT is also being
> accessed for read correctly.
Good point. So it's probably not something in the CPU that's repeating every
020 locations.
Also, IIRC, that ODT code doesn't use memory, it runs entirely out of the
registers. There's some good reason for that (probably to avoid messing with
the contents of memory), but maybe also so that it runs without working
memory - ISTR that we discussed this at one point here, but I'm too lazy to
look for the discussion. So that's why ODT runs even if the RAM isn't working.
Anyway, if the 020 problem is in the memory too, it's probably the A04 bus
receiver (E55), although it might be the address latch (E88, a 7475) or the
RAS/CAS mux (E99, 74S153). Step a would be to put a scope probe on the output
of the bus receiver (pin 2) and see if it's hopping up and down - if that,
that chip is OK, and the problem is further down the line.
> I don't know if the rom path to the ODT code is different than the ram,
Yes. The ROM for the ODT is stored in the M9301 card (at least, if it's an
11/04, it's probably an M9301 - could be an M9312, too). The RAM is in
another card, an M7847 (MS11-J).
> it is interesting that the console code is being fetched, along with
> the data from the serial controller to communicate with the console
> terminal
Which indicates that the UNIBUS is probably OK; the console serial is on yet
another card, the M7856 (DL11-W); the CPU, RAM, bootstrap and serial line all
talk to one another over the UNIBUS.
Noel