Hi Noel, Thanks for the very useful information. I'll do some investigation this weekend and keep an eye out for a spare SLU. Being in the UK makes it quite difficult to find these things.
Thanks again, Aaron. Noel Chiappa via cctalk writes: > > From: Aaron Jackson > > > a PDP-11/73, M8192 CPU, two M8067 RAM, M7195 ... While playing in ODT, > > the console completely stopped responding. > > ... > > The CPU shows 1000, which I believe is fine, and means it's in ODT. The > > SLU card has 1111. I've had a Google and I believe this means it can't > > communicate with the CPU. > > ... > > Does anyone have any ideas? It was working and then it wasn't :( > > Hmm. Well, it's possible something just died. Dead boards are not un-common, > I've found, but to have one die while it's being worked with is a bit of bad > luck... Alas, I can imagine a zillion failures that could produce this symptom > (from EIA driver chip, down to a bus transceiver chip on the CPU). > > > OK, to start with, those LED values. When you say 1000 on the CPU, there's > some ambiguity as to which direction you're reading them; so, which LED is > on? From above the board (component side up), with the contact fingers at the > bottom, the one on the left, or the one on the right? I'm going to assume the > one on the right, which does indeed mean the CPU is claiming it's in ODT. > > While we're on the CPU, is it set to halt on power-up (power up mode 1) or > try and start the ROM (power up mode 2)? I always set mine to halt, on the > grounds that it's easy to start the ROM. > > I'm not familiar with the MXV11-B (M7195), and I couldn't turn up a manual > online, but likely those LEDs are set by software (I can't imagine how one > would turn on a "can't communicate with the CPU" bit in hardware ... unless > it's a flop that's set on power-on, and cleared by the first bus cycle to the > card)... > > > Anyway, there are two approaches to solving this problem. > > So, one option (depending on your budget) is to buy spare boards so you can > board-swap to localize the problem to one board. > > I would recommend getting the spare boards anyway since I would recommend > always having a spare minimal set of boards (CPU, serial line) etc. Without a > 'working' machine - at least to the point of running ODT - it's hard to do > much poking into problems without a lot of pain (i.e. hard work with things > like a logic analyzer or oscilloscope). Being able to board-swap to at least > localize the problem to one board is a big help. > > So, start with another serial card (QBUS serial cards are pretty easy to find > on eBay, and not too expensive), and swap out the MXV11-B, and hope the > serial card you bought works. There are a ton of boards that can do this - > M7940, M8017, M8028, M8043 (the first 3 single line, the last is a quad, but > uses the same connector as the MXV11-B, unlike the first 3). (If that option > is out, I can lend you a known working serial card.) > > If it's not the serial card, the next thing to buy is a spare CPU; -11/23's > are not too expensive, you don't need a /73 to debug hardware issues. > > > The other approach is to debug the hardware. You mention an oscilloscope; do > you also have a logic analyzer? Some things (e.g. checking that when you type > a character, the serial interface presents it to the CPU) are going to be hard > with only an oscilloscope - although I suppose one could program one's > computer to send a constant stream of characters (probably DEL) to the -11. > > I couldn't find a set of MXV11-B prints online - does anyone know of a set? > Without that, if the problem is in the MXV11-B, finding it's going to be > painful. > > Anyway, you could check on the QBUS to make sure the processor is actually > cycling, trying to read the console input status register, waiting for the > 'input character ready' bit to go on. So look at BSYNC and BRPLY, to see if > they are hopping up and down. > > > Oh, I guess there's a third option: send the CPU and MXV11-B to someone who > has a working system, so they can board-swap and check them out. (I've done > this for people...) > > > Bottom line, though: if the fault is in the MXV11-B, unless we can find some > prints for it, you're probably stuck with buying at least a replacement > console serial card. > > Noel -- Aaron Jackson PhD Student, Computer Vision Laboratory, Uni of Nottingham http://aaronsplace.co.uk
