test-drb

test-drb@ccmp.vtda.org

101090 discussions

Start a nNew thread

TK50 with DEC All-in-1

by curt＠atarimuseum.com

Hi Anyone have a TK50 install of this ? Either for sale, trade or loan? Thanks, Curt

10 years

AS400 Model 170 potentially available...

by lbickley＠bickleywest.com

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"

10 years

Y Combinator is restoring one of Alan Kay's Xerox Alto machines

by curiousmarc3＠gmail.com

> > 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

10 years

Q-Bus Memory Diagnostics and Repair

by jnc＠mercury.lcs.mit.edu

> 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

10 years

Q-Bus Memory Diagnostics and Repair

by jnc＠mercury.lcs.mit.edu

> 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

10 years

Components available

by t.gardner＠computer.org

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>

10 years

{wtb} DEC VT100 5 spoke rolling stands

by smj＠ma.sdf.org

I'm looking for a couple DEC VT100 5 spoke rolling table stands. Please contact me privately if you have one available. Thank you

10 years

Powering up a 3741

by coryheisterkamp＠gmail.com

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

10 years

RK05 packs

by jnc＠mercury.lcs.mit.edu

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

10 years

Odd memory error in PDP-11/04

by jnc＠mercury.lcs.mit.edu

> 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

10 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb