Electronics > Repair
ADVANTEST R9211B
<< < (11/39) > >>
m k:
There are many things that can be done, even more if you can keep the logic analyzer a bit longer.
But everything is more or less time consuming, more if you're not familiar with what is happening.

Connect the analyzer to 16 highest addresses and put trigger to A22.
If nothing happens you cam assume that no I/O is accessed.
Change trigger to A23, if earlier was nothing maybe here is something, something is generating interrupts anyway.
If A22 and A23 are both off only thing left is DMA controller.

You can also sync to CLK, pin 15 and possibly get a longer set of readings.
m k:
Dang, I forgot the CRT controller, it's of course active and address space is used.
So if first only address is there something is missing.
CRT controller can't be the first only one, if it is then the machine doesn't know that something is wrong.

Assumption is that nothing generate interrupts without activation by the software.
But fault can obviously do its own things.

Other approach can be chip selects and similar pins of all I/O chips.
Then you can have easier trigger and lower amount of needed data.
Include _IPL0-2 and A1-4 pins for interrupts.
Earliest trigger is problematic, maybe a preselector 3to8 chip of those chip selects, that you must find out by tracing some of those pins.
stfjohn:
Forgive my ignorance on the subject (I deal with linear electronics applied to audio): what are the highest addresses (to which pins should I connect the logic analyzer)? Thanks.
m k:
Since we now know that interrupt is happening we can try to go back from there.
Though it's also possible that the interrupt is exactly as it should be.

Since interrupt itself is pretty short it's not very easy to follow, but we can predict that before that interrupt the processor has accessed the chip.
It usually goes so that chip that can do interrupts is reset interrupts off, so processor must activate it first.
Since we know the memory map we can leap to before any I/O chip access, easiest it is to follow how program is forwarding.

Highest CPU addresses A23-20 defines the highest nibble, that is all we need for knowing that I/O is accessed.
Next six addresses A19-16 and A15-14 are for sanity check, that the address is actually what it should be.
(0101 111x 00)
After that we can start wondering what chip is accessed.

But since there is text on the screen we know that CRT controller is accessed, so we can assume that all those addresses are fine.
So only A22 is needed for triggering.

We can continue assuming, so A16 is needed and so are A13-10.
So finally only 6 pins, plenty left for other things then.
(51, 44, 41-38)

Pin 9 for read/_write is always nice to know.
Rest can be pins 24-32 for interrupt process.

So first trig A22.
Then maybe pin 25 or 24, those go down for interrupt, in your earlier picture those were both down, but it can be from multiple interrupt requests.
After that you can check how different pictures combine.
When bottom 4 are the same you know it's the same spot.

If you can use conditional triggers you can try combining different address pins from the earlier memory map picture.

My guess is that only 1st set of I/O map will do interrupts.

What are 3rd set of I/O map names?
RDRE
CS8245B
RDRET
RDBGT
SOFTRST
m k:
Some other things to try if analyzer is about to be returned.
If the machine has an output possibility you can also try dumping results out for later use.

Low left is keyboard controller and its ROM.
The controller chip can generate an interrupt when key is pressed.

So 82C79 pins to the analyzer
4, 10, 11 IRQ, _RD and _WR
12-19 data
21, 22 A0 and _CS

If clock sync needs a POD pin there are two leftovers.
You can also change the last pin of the earlier message for clock, if needed.

Two leftovers can be used for _IPL0 and _IPL1 of the CPU, if possible.
In the earlier picture both signals are down, so if both are connected and only one goes down we know that interrupts are more than one.
You can of course test them one at the time also.

First trig IRQ pin 4.
If IRQ happens you should see the data when _CS and _RD are down.

One possibility is that there is an interrupt, but data is 00, so no key.
The interrupt pin goes down when data is read and stays down if no more data is available.

RTC chip above the keyboard controller seems to have a some sort of an interrupt something, but use of that function is not very probable.
Same with the keyboard controller, but maybe a bit more probable, polling a keyboard is quite usual also.

A square chips near the buzzer and one left from 12V input are D71054.
Is the one a bit down from 12V input also the same?

That chip is a counter/timer and can generate many kind of interrupts.
Pins 9, 18 and 26 as OUTn, it seems to be 8254 clone, mentioned in 3rd block of I/O chips.
But since its function is what it is there is little use for reading it after it generates an interrupt.
So its outputs are merely for triggers and not probable for generating that text on screen, at least alone.

But that is a pretty simple chip so checking how it's programmed is not complex, though doing that with a logic analyzer has some nuances.
Since you're usually just letting the analyzing flow you can't expect that you can see much during single pass.
Those chips are also far apart, so maybe POD wires are too short.

1st I/O block

5E00xx *CSDMAC
5E04xx *FPUSEL
5E08xx *FPUPOL
5E0Cxx *CSFDC
5E00xx *CSGPIB
5E04xx *FDCDMA

FPUPOL can indicate that floating point results are polled, it also has a bidirectional completion signal _SPC for possible interrupt.
FDC is probably for the later use, same with GPIB.

2nd I/O block

5F00xx *CS8279
5F04xx *CS8254A
5F08xx *CSRTC
5F0Cxx *RTC1CLC
5F10xx *BZON
5F14xx *INTCLR
5F18xx *MODESET

BZON can be one timer, INTCLR and MODESET can be what ever.

3rd I/O block

5F20xx *RDRE
5F24xx *CS8245B
5F2Cxx *RDRET
5F30xx *RDRGT
5F38xx *SOFTRST

28 and 34 lines are missing, it can mean that the access area is wider.
Maybe all of those are for timer chips.
A bit tricky to test, legs are closer and one is on the other side.
Maybe you can follow traces backwards.
Use the setting from the earlier massage and leave the last 4 pins out.
One of those free POD pins can go to CPU clock and other three to _CS pins of timers.

For reading timer chip programmings you need at least 8 data and 2 address pins, chip select and write signals.
That's 12 pins, so chip selects from other chips and clock is 3, still 1 free.
There data bits can be connected to CPU, but it can use the whole bus and write two timers at once, so maybe not.
So best practice is to read directly from the chip and one at the time.

For DMA controller you can also use that earlier message setting.
Use last pin for clock and other address pins for DMAC _BEC0-2, pins 29-27.
Since DMAC interrupt is different you can't see what happens, but you should see its general I/O access shortly after interrupt happens.
What has happened must be read out from its registers, so many pins are needed.
But you can also guess the happening from Bus Exception Control signals.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod