| Electronics > Repair |
| ADVANTEST R9211B |
| << < (13/39) > >> |
| m k:
Something went a bit off again, I think it's better to make a new setting. Earlier can also be from very beginning where very basic tests are on the run. It's also possible that some of the add-on cards are using the FPU. Though Not likely. First use a multimeter and check CPU and FPU data connections. Are next pairs connected? CPU D0 pin 5 and FPU D0 pin 11 CPU D1 pin 4 and FPU D1 pin 10 CPU D8 pin 61 and FPU D8 pin 3 CPU D15 pin 54 and FPU D15 pin 16 Earlier block diagram indicates that they are, it's very possibly so also. My guess is that they are not, somewhere is a transceiver in between. Leave POD 1 CPU addresses as they are. Change POD pins from CPU 53 to 9 and 49 to 22. Then POD 2. Change POD pin from DMAC 31 to 28 and POD pins from FPU 20 to 22 and 19 to 23. Move POD 2 10 to CPU _IPL0 pin 25 and POD 2 11 to CPU _IPL1 pin 24. Trig to POD 2 09, FPU _SPC pin 21 going low. |
| stfjohn:
The connections between CPU and FPU (5-11 4-10 61-3 54-16) are perfect. Unfortunately I can't get Pod 2 to work on the logic analyzer (I suspect it doesn't work at all!).... Only Pod 1 works! |
| m k:
Ok, 16 channels then, not a problem, just few hops more. Since FPU is active we'll continue from there. Directly connected data lines are good, no need to wonder anything. POD 00 68000 51 (A22) POD 01 68000 44 (A16) POD 02 68000 41 (A13) POD 03 68000 40 (A12) POD 04 68000 39 (A11) POD 05 68000 38 (A10) POD 06 68000 24 (_IPL1) POD 07 68000 25 (_IPL0) POD 08 68000 9 (R/_W) POD 09 68000 22 (_BERR) POD 10 32081 23 (ST0) POD 11 32081 22 (ST1) POD 12 32081 21 (_SPC) POD 13 68450 11 (_DTACK) POD 14 68450 29 (_BEC0) POD 15 68450 61 (_UAS) Trig again to POD 12 going low. DMAC _BEC0 was missing last time. If it goes down the DMAC will halt. Earlier CCxxxx address can be high data for DMAC. For that DMAC _UAS must go down. Rest are for FPU and its doings. |
| stfjohn:
here is the latest scan according to your instructions. |
| m k:
Recheck POD 10, 11 and 12. Your earlier foto 2 indicates that POD 07 there and POD 12 here are the same. We must be sure that _SPC pin is the one that we think it is. Keep all connections and change trigger to POD 07 going down. That way you should see when interrupt is actually happening. Then it's also possible that you can see the address triggering it. POD pins 00 to 05 indicates that I/O address is 5F1Cxx. MODESET is 5F18xx and after that is nothing, maybe address decoder has a problem. Bottom left of block diagram has a data bus arbiter PAL chip, it connects to DSP and add-on bus controller. If we take that as a guide we have similar PAL chips conveniently around the main board. You can start checking how those PAL16L8A chips are connected, first half and pin 11 are for input, so 10 inputs, that's addresses 23 and down to 14, not enough. High part of I/O is always 0101 111x so something can easily code that separately, conveniently PAL16L8A has 7 output AND matrix. That possible high part chip could also code other I/O address spaces, actually all from work area RAM and E2PROM to 1M DRAM area, and so is not wasted at all. It also means that one input pin that is not CPU address must be connected between all 5E/5F I/O area PAL chips as a source from high order address coder. One possibility is also that there are two PAL chips for high order bits, for design practicalities. But addresses up from A10 must be there or no final I/O selections. So can you find CPU high address pins connected to input side of PAL chips? |
| Navigation |
| Message Index |
| Next page |
| Previous page |