Re: M8195 SLU died while in use
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 . 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
Re: M8195 SLU died while in use
> one option ... is to buy spare boards so you can board-swap to localize > the problem to one board. > ... > start with another serial card Also, if you get a working serial card to use for a console, and you get a working system as a result, you can then use that ensenble to try and debug the MXV11-B (you'd have to reconfig its serial line to not be the console). You can then try all sorts of debugging steps, e.g. try doing deposits/reads of serial line registers on the MXV11-B to see if you can send/receive characters - and it that doesn't work, you can then try 'toggling' in a simple program to send characters in a stream, so you can look at the inputs/outputs of the EIA chips (those should be findable, even without prints) with a 'scope, to see if they are busted. Etc, etc. Noel
Re: M8195 SLU died while in use
> On Sep 25, 2017, at 8:37 AM, Noel Chiappa via cctalk > wrote: > >> 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 . 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 :( > > > 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)... > > There is a user guide at http://vaxhaven.com/images/6/6d/EK-MXV1B-UG-001.pdf The LED’s are controlled by a single write only register as Noel suggests. You might try to blindly set or clear the leds with a poke to 7524. 1 to turn the LED OFF, 0 to turn ON. By blind, I mean don’t expect any echo from ODT. // I had a M8192 go bad while I was using it a few months ago. One minute fine and then the next it would crash an OS sporadically crash, then failed to boot. ODT was still active, but after using it to look at a few registers or memory locations it would just start streaming garbage to the console until power reset. Confirmed it was only this card. I swapped out the DCJ-11 with no effect, so its definitely the board itself. Other than trying to vary the +5 supply to the backplane within normal margins to see if it would recover, I haven’t had a chance to work on it more. I’d definitely like to understand what form of bit or component rot is going on here when I get more time with it. Jerry
Re: M8195 SLU died while in use
> 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 . 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
