On Wed, Sep 7, 2016 at 1:46 PM, Noel Chiappa <[email protected]> wrote: > > From: Paul Koning > > > 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").
Hmm... I see how that would "work"... interesting. > A fully-populated 64KB MS11-J card has 4 rows of 16Kx1 chips... This is a 64KB M7847 DJ with 72 (4 rows of 18) Mostek MK4027 chips... We did lose at least one of these back in the 80s. I have 1-2 ones needing inspection and repair. Those are far, far down the pile to investigate. This particular board was working through the early 90s before I stopped using it for testing COMBOARDs. I also do have some 256KB boards, > 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). Right. I did some tests like that but I didn't capture the results and I can't reproduce them yet. > > 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. Good point. > Also, IIRC, that ODT code doesn't use memory, it runs entirely out of the > registers. I think that's correct. > 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. Sure. Makes sense. > > 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). M9312, as mentioned. I have many of those. So far, I'm still using the one that was in this machine for 35 years, but I have many others, and several common boot ROMs (DD, RX, RL...) > The RAM is in another card, an M7847 (MS11-J). Precisely. > > 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. Yes. That is "obvious" and I should have immediately realized that the CPU and bus must be happy or I would have no ODT. Must be the RAM, or at least it was before the whole thing stopped responding. Now, it's probably the RAM and the CPU. I did swap back in my first DL11-W and that does (still) stuff up SACK, so it has its own problems. I have one recently working and one recently non-working DL11-W and one that came to me with some obvious mouse damage that might be recoverable - it's in the corner by the 40-pin connector and I think to really clean it, I'll have to remove that connector and clean that entire quadrant, but, again, another problem for another time. Just getting ODT back will be a small win, then debugging the RAM card will be another. So far, the repair has been one 7474 on the console board. Looks like 1-2 more chips will need to be replaced, at least. I do have a few parts of the era. Thanks, all, who chimed in. So far, the observations and advice have been great! -ethan
