test-drb September 2016

test-drb@ccmp.vtda.org

162 participants
227 discussions

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

9 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

9 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

9 years

More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

by jnc＠mercury.lcs.mit.edu

> From: Pete Turnbull >> The other thing that makes no sense is that the KDJ11-B (M8190) has >> all that extra circuitry on it to support PMI, etc - all of which is >> unused in the 11/73 application! Why not just plug in a (presumably >> cheaper) M8192? In the /73 application, the two are basically equivalent. > Don't forget the LTC :-) ?? The KDJ11-A has an on-board LTC - see EK-KDJ1A-UG-001, pg. 1-7. > Otherwise, you'd need an additional bootstrap card such as an MRV11-D > with -B2 boot ROMs, a DLVE1 (DLV11-JE) for the SLUs, something with an > LTC, and termination. Err, the KDJ11-A has on-board termination: see MP-01890 pg. 1 of 9, on the LHS. > A BDV11 wouldn't work as it doesn't have the ROM capability ?? The BDV11 is a ROM board? (And it works fine in a Q22 bus; the address recognition circuitry uses BBS7, it doesn't look at BDAL 16 and above.) Noel

9 years

National MM57409 "Super Number Cruncher", MM57109 "Number Oriented Processor"

by spacewar＠gmail.com

I finally got my hands on a couple of MM57409 "Super Number Cruncher" chips with 1985 date codes. I think it was probably introduced around 1982. It's a NMOS part with the same concept (though not compatible with) the earlier PMOS MM57109 "Number Oriented Processor", which was introduced in 1977. In both cases, National took their existing 4-bit masked-ROM microcontroller designs (MM5799 PMOS, COP440 NMOS), and the floating point code they'd already written for calculator chips, and turned them into math coprocessors. The MM57109 also had some support for acting as a floating point general purpose processor. The COP4xx has a test mode, so I should be able to dump the ROM of the MM57409. The MM5799 almost certainly had a test mode as well, but I haven't uncovered any documentation for it, so the ROM might have to be dumped optically. The MM57109 uses an 8-digit mantissa, and a divide takes an average of 78ms, and worst-case 223ms. The MM57409 has a 12-digit mantissa, and worst-case dvidie time is 66ms, with no average stated. Both also have a reasonably full complement of functions that would be found on a typical scientific calculator, including transcendentals. Both are quite slow compared to contemporary math coprocessors such as the AMD Am9511A (second-source by Intel as the 8231A), and insanely slow compared to the 8087. I'm tempted to wire up one of these (either kind) to an Apple II, and hack Applesoft to use it as a floating point decelerator. Back in the day, a few companies sold Am9511A cards for the Apple II. Of course, since Applesoft uses binary floating point but these National Semiconductor chips use BCD, the necessary conversion code running on the 6502 would make it even slower. Perhaps Atari BASIC would be a better choice as it used BCD.

9 years

HP-35/45 Simulator for PDP-8

by kevenm＠reeltapetransfer.com

There is a nice HP-16C emulator for Windows - and Android. http://www.wrpn.emmet-gray.com/ Also has Java version (and sources) Keven Miller > ----- Original Message ----- > From: "Marc Howard" <cramcram at gmail.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Sent: Wed 07 Sep 2016 09:53 AM > Subject: Re: HP-35/45 Simulator for PDP-8 > > >> I'd vote for the HP-1xC line myself. You can get 5 different calculators >> (financial, 3 x scientific and programmer) for nearly the effort of the >> first one. >> >> The HP-16C (http://www.hpmuseum.org/hp16.htm) would be especially helpful >> as it can easily be converted to calculate with a 12 bit with carry width >> and octal operation with just a few keystrokes. Even does 1's >> complement/18 bits if you happen to have a PDP-1 lying around. >

9 years

More mystery recycler boards - DEC, Fujitsu(??), Cipher, Emulex

by jnc＠mercury.lcs.mit.edu

> From: Pete Turnbull > all microPDP-11/73 machines had an M8190. The M8192 was mostly sold as > an OEM board. That's so bizarre (although the "Supermicrosystems Handbook", which covers the 11/73, confirms it used the KDJ11-B). So the KDJ11-A (M8192) was not used in any 'PDP-11/xx'? The other thing that makes no sense is that the KDJ11-B (M8190) has all that extra circuitry on it to support PMI, etc - all of which is unused in the 11/73 application! Why not just plug in a (presumably cheaper) M8192? In the /73 application, the two are basically equivalent. (OK, there are two built in serial lines on the M8190 - big whoop.) Both have 8KB caches (although the one in the M8190 has slightly fancier tagging, IIRC), etc, etc. Maybe it's the ROM (which the M8190 has, but not the M8192)? Noel

9 years

ENIAC Simulator

by blstuart＠bellsouth.net

Unfortunately, I won't be able to make it to VCFMW this year. (Those of you who don't know me are probably thinking "So what?" Those who do are probably split between "Aww, that's too bad" and "Good; he's a pain in the...") In lieu of my "sparkling personality" I'm making available the ENIAC simulator I would have exhibited had I committed to coming early enough to reserve a table. If you attended VCFSE or VCFE this year, you may have seen an early version of the simulator. It's now at a beta testable level of operation. The files you'll want to download and some minimal instructions for use are at: http://cs.drexel.edu/~bls96/eniac/eniac.html It's written in Go, so you should be able to compile it on a variety of platforms. For those not wanting to compile it themselves, I've included binaries for several options including Linux/amd64, Linux/arm, FreeBSD/amd64, FreeBSD/i386, MacOS/amd64, and Win/amd64. The Windows version has not been tested at all, and only minimal testing has been done on the Mac version. You'll also need TCL/Tk installed to get the wish program available as used by the GUI. Suggestions, comments, criticisms, and questions are welcome, but it will probably be a few weeks before I'll be able to make time to do anything about them. Enjoy. BLS

9 years

RK05 packs

by jnc＠mercury.lcs.mit.edu

So I have a fairly large group of 16-sector RK05 packs (i.e. PDP-8, -12) which I have no use for, which I would like to trade for 12-sector RK05 packs (i.e. PDP-11). Anyone have any of the latter, and need the former? Alternatively, if anyone has any head-crashed 12-sector RK05 packs, I would be interested in buying them (or trading something else) for them. (I am reliably informed that one can replace the platter on an RK05 pack without too much work, so I'd transplant the 12-sector hubs into the packs I already have). (Replies to me, please, not the whole list - unless there's some point you wish to make which would be of general interest.) Noel

9 years

Odd memory error in PDP-11/04

by jnc＠mercury.lcs.mit.edu

> From: Ethan Dicks Let's look at this one first, this is probably the easier to solve. >>> 2) Setting D10 in location 000000 results in D10 set in all the >>> locations >> Sorry, didn't follow that? Did you mean that if you store 02000 in >> location 0, all other locations now report the 02000 bit set? > Only 04000, but, yes. Ah. That's D11. :-) > If I set that bit in location 0, or other locations, it gets set in all > locations. If I clear that bit, it clears. So that's likely in the memory (although I suppose it could be the CPU, _somehow_). It sounds like there's a latch somewhere in the output path (because it affects all locations right away, not just once you've written to them) that's getting set one way or the other, and and then, won't change. I suspect the problem is with the flop for that bit, not in the circuitry that's clearing/clocking that flop, since it only affects that one bit. Looking at the MS11-J prints, there is indeed a '174 latch in the output path; the one for D11 is in E30 (input pin 14, output pin 15). You might want to throw a scope on it, and see if it is indeed acting consistently with the symptoms (to make sure this is actually the cause). Although why it can be either set or reset with a write, but freezes in one state for reads, is puzzling. I'd suspect control circuitry, but it's only that one bit. I don't think it can be something on the input side, because the memory chips have input and output on separate pins, so if something was hanging on the intput side, it shouldn't make it through the chip. > Something appears to have died while I was powered-on and testing last > night and now, the run light goes off right away after hitting boot, > and I don't see the address lines or the data lines flickering. Yeah, sounds like the CPU is halting. It's probably going to take a logic analyzer to figure out what's going wrong. Too bad that machine doesn't have a real front console, that would probably let you figure out what the problem is. Noel

9 years

← Newer
1
...
14
15
16
17
18
19
20
...
23
Older →

Jump to page:

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