On Wed, Feb 17, 2021 at 12:45 AM Josh Dersch <dersc...@gmail.com> wrote:
> > > I hooked the LA up to the two PROM bits that select the AMX input (RACC > UAMX00 H and RACC UAMX01 H), on the ROM & Address Control board. These > come from the PROM at U101 and go through a 74S174 at E97 before heading > over to the DAP board. And during FET.00 we have: > > Addr PCB PCA AMX > 260 44 44 0 > > "0" here selects DR (Destination Register) input to the mux and is > incorrect; it should be 1 (PCB). During a single-instruction-step run, > this value reads out OK on the analyzer. I noted a few other discrepancies > in the capture (all of which match the ucode listing during a > single-instruction step) which makes me think that the high outputs of the > PROM are right on the bleeding-edge of acceptable TTL. I checked out the > signal on the scope while running a BR .-1 instruction (which also doesn't > execute correctly but at least doesn't halt... I don't have a storage scope > to capture this during a single instruction execution) and it looks like > the voltage swing is from about 0.15V to 1.7V or so. > > On the off chance it was the 74S174 at E97 pulling the signals down, I > socketed it and substituted a spare '174 in; no change. I also noted that > the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it > made a difference (it did not.) > > So it seems likely it's the PROM. Looks like I may have some typing to > do, though given that the ROM works well enough at slow speeds I might be > able to dump it with my Data I/O Model 29 and compare it against the > listings in the engineering drawings, to save some time... > > I'll try to dump the PROM tomorrow and see what I get. > > - Josh > A status update here: I've dumped the bad PROM at U101 (and it read out fine on my Data I/O 29, comparing it with the listing in the engineering drawings). A local friend had a spare 11/70 boardset, so while I wait for some (hopefully) NOS bipolar PROMs to arrive, I've installed a spare RAC board. With this installed, instructions execute much better, and after tracing down a faulty Unibus terminator, I got it to run the bootstrap PROM on the M9301! I used my Unibone to boot XXDP+ from an emulated RL02 pack and over the past week I've been running diagnostics and debugging the hardware. Thus far: - Unibus Map registers non-functional: addresses decode but writes have no effect and all reads come back as "0". Replaced bad 8640 bus receiver on the Unibus Map board. - EMKA memory diagnostic hangs the processor in t5 of uAddr 343 (IRD.00), in PAUSE. Traced it down to the HC42 (replaces the original Cache Control Board) board of the Hypercache boardset, lacking any engineering info I swapped this for a spare that I'm fortunate enough to have. The system is now passing all but two diagnostics: - EMKA reports strange errors in banks 50-57 of memory and only with pattern 17; all other banks test fine: MEMORY DATA ERROR PC BANK VADD PADD GOOD BAD XOR MAR BOX MTYPE INT PAT ARRAY 032334 50 157564 05077564 000377 000377 000000 0 ? MJ11 ? 17 ?? 032334 50 156450 05076450 000377 000377 000000 0 ? MJ11 ? 17 ?? 032334 50 155330 05075330 000377 000377 000000 0 ? MJ11 ? 17 ?? 032334 50 154210 05074210 000377 000377 000000 0 ? MJ11 ? 17 ?? 032342 50 154020 05074020 000377 177777 177400 0 ? MJ11 ? 17 ?? 032342 50 153740 05073740 000377 177777 177400 0 ? MJ11 ? 17 ?? 032342 50 153734 05073734 000377 177777 177400 0 ? MJ11 ? 17 ?? 032342 50 153732 05073732 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153730 05073730 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153726 05073726 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153724 05073724 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153722 05073722 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153720 05073720 000377 177400 177777 0 ? MJ11 ? 17 ?? 032342 50 153716 05073716 000377 177400 177777 0 ? MJ11 ? 17 ?? Occasionally testing banks 50-57 will die with a trap to 4 instead. Pattern 17 tests using alternating patterns of "0" and "1" bytes, using byte accesses to memory, I'm curious why only this pattern would fail. Accesses to this area of memory from the console work fine - EKBD fails with: ADDRESS MULTIPLEXER, AMX, CPU INPUTS TEST FAILED. ERROR ADDRESS REGISTER NOT SET CORRECTLY. TEST. CALL AT PC. EXPECTED ADRS. GOT ADRS. ERROR REG. 5 00007524 06000000 05777776 144406 (Note the similar address range to the EMKA failures). I've verified that AMX, etc. are not to blame here. I suspect this issue is related to the memory issue above. I've looked at the MMU hardware to see if address generation is breaking for some reason at these addresses and it seems to be OK. I'm going to keep poking at this, but the complexity of the PEP70 memory board plus the lack of hardware docs is going to make this a challenge. If anyone has any bright ideas, let me know. I suppose that worst case I still have a megabyte or so of contiguous working memory; I can modify the memory size jumpers and patch operating systems to ignore the rest. Better than nothing! Anyway: I'm pretty happy with the progress here, I wasn't expecting this to go as smoothly as it has (knock on wood) for a computer in as sad shape as it was. Total carnage here: 4 bad ICs, one dead clock crystal, a dead Unibus terminator, and a marginal HC42 board. And a few slightly dirty backplane fingers... Gives me hope for the 11/45... - Josh