A500 Green Screen. DiagROM says: "raster: NOT DETECTED"

[retrofriends]

Hello all. Help! I have a rev6 A500 MB that gives a green screen. After inserting DiagROM, RGB output flashes green (normal for DiagROM chip mem detection), then just goes black while serial port shows error:

"Detecting if we have a working raster: <> NOT DETECTED"

Using DMM and oscilloscope I have rang out the vcc, grounds, address signals, and data signals to the RAM and there is power/continuity/activity on all. Piggybacked the RAM, and no change. Well, slight change in cadence of error message when U17 mem chip was piggybacked. Then replaced Agnus socket because I noticed a crack. No change. While socket was out, tested traces - they are good.

DiagROM checks the raster I guess to make sure it can draw a screen? Is the raster checked via RAM? Should I continue to diagnose the RAM, or look elsewhere?

[solarmon]

Please can you cut'n'paste the whole of the serial port output when you boot up.

Have you tried the Agnus in another, working A500? Or tried an Agnus from another, working A500?

[Toni Wilen]

It means vertical counter (DFF006) is stuck. (I checked the source).

It can only stop if Agnus thinks genlock is connected (=Agnus detects load on sync lines) but it shouldn't happen unless software also enables genlock mode. It does sound like broken Agnus or possibly shorted HSYNC or VSYNC lines or something like that.

Do you get different diagrom serial output if you disconnect monitor cable?

[retrofriends]

Amiga DiagROM V1.1 - 27-Oct-18 - By John (Chucky/The Gang) Hertell


Testing if serial loopbackadapter is installed: <> NOT DETECTED
- Parallel Code $ff - Start of ROM, CPU Seems somewhat alive
Checking status of mousebuttons for different startups:

Set all Interrupt enablebits (INTENA $dff09a) to Disabled: Done
Set all Interrupt requestbits (INTREQ $dff09c) to Disabled: Done
Set all DMA enablebits (DMACON $dff096) to Disabled: Done

Testing if OVL is working: OK
- Parallel Code $fe - Test UDS/LDS line
- Test of writing word $FFFF to $400 OK
- Test of writing word $00FF to $400 OK
- Test of writing word $FF00 to $400 OK
- Test of writing word $0000 to $400 OK
- Test of writing byte (even) $ff to $400 OK
- Test of writing byte (odd) $ff to $401 OK
- Parallel Code $fd - Start of chipmemdetection

Addr $00080400 OK Number of 32K blocks found: $10
Chipmem Shadowram detected, guess there is no more chipmem, stopping here

Startaddr: $00000400 Endaddr: $00080000

Using $0006CD00 as start of workmem (Base)

- Parallel Code $fa - Starting to use detected memory

Testing if serial loopbackadapter is installed: <> NOT DETECTED
Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <>Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
Detecting if we have a working raster: <> NOT DETECTED
ETC...

[retrofriends]

Originally Posted by Toni Wilen

It means vertical counter (DFF006) is stuck. (I checked the source).

It can only stop if Agnus thinks genlock is connected (=Agnus detects load on sync lines) but it shouldn't happen unless software also enables genlock mode. It does sound like broken Agnus or possibly shorted HSYNC or VSYNC lines or something like that.

Do you get different diagrom serial output if you disconnect monitor cable?

Just tried without monitor cable. No change. Forgot to mention, all socketed chips are known good, but I will try swaps as I become more desperate LOL. I did swap Agnus though. I did see it was register $006 which is the raster's vertical and horizontal position register. The ROM is asking for it, but where is that information coming from? Is it stored in memory? Remember, with Kick 1.3 ROM I get a green screen.

Since you brought it up, I saw the source code of DiagROM too. I think where to start is the conditional statement(s):
*********************************************************
move.b $dff006,d0 ; Load value of raster
bsr WaitShort
bsr WaitShort
bsr WaitShort
move.b $dff006,d1 ; Load value of raster again
cmp.b d0,d1
beq .noraster ; if raster was the same, We assume we have no working raster
move.b #1,RASTER-V(a6) ; it was different so we assume we have working raster.
*********************************************************

So we know that the same register is read twice, and it has the same value in order to fail. This has to point to a specific place to look.

[solarmon]

Have you checked the RGA (Register Address Bus) signals/traces between Agnus, Paula and Denise?

[Toni Wilen]

RGA probably is at least almost working because serial output works (and green screen ). DFF006 not working but serial and color0 working would be only possible if RGA line 1 is broken (bit 2 of address) Which would read from DFF002.B which has static contents.

Diagrom probably would also need to check if DFF005.B bit 0 keeps toggling (high bit of vertical counter).

It still would not explain why KS ROM causes green screen. It is possible there is also other faults.

[retrofriends]

Wow guys thanks for the new direction! I also noticed the lines going through to Denise and Paula. Further research on my part is on today's agenda. I will report back with more info, and likely more questions.

[retrofriends]

Okay, so the RGA traces are all good. Every trace seems good. I checked the traces from the data path to the 68k and Agnus. As mentioned I tested all address and data traces. This motherboard is in good condition, and I am at the point where I believe all traces are good. Looking for a bad discrete.

I decided to pull the oscilloscope out again and compare signal between two r6 motherboards. I did find that the OE on the bad motherboard was stuck high. Signal comes from Gary pin 3 via a tested-good resistor. I replaced Gary - no change. Is OE stuck high because computer won't start, or is it the cause? (chicken or the egg LOL) Tested all traces to/from Gary and they are all good. Does anyone know the conditions in which Gary sends square-wave signals on pin3? Kinda looking at U33, but that's a guess.

[solarmon]

I assume you mean the _OEL signal? This should be active low, so if it is stuck high then then the 74LS373 logic chips will not not output any data. There should be constant low/high activity on the_OEL signal - so something must be pulling it constantly high.

Check continuity/resistance of Gary pin 3 to VCC to make sure it is not shorted to it.

But like you said, something else might be causing Gary to pull _OEL high.

[Toni Wilen]

Stuck _OE probably means CPU reads would not work correctly when reading chipset side bus (and would explain all problems, green screen and vertical counter returning static data and working serial writes and ROM reads).

Does LATCH Gary signal change state?

As was already said, measure the pin and also try disconnecting it from socket (by carefully bending it). If pin starts changing state (it is output pin), something is wrong with either TTL latch chips or line is shorted to something.

Do you get normal PAL/NTSC timed pulses in Agnus vsync and hsync lines? If they do appear normally, vertical counter inside Agnus has to count and problem is almost guaranteed to be outside of Agnus.

[retrofriends]

Originally Posted by solarmon

I assume you mean the _OEL signal? This should be active low, so if it is stuck high then then the 74LS373 logic chips will not not output any data. There should be constant low/high activity on the_OEL signal - so something must be pulling it constantly high.

Check continuity/resistance of Gary pin 3 to VCC to make sure it is not shorted to it.

But like you said, something else might be causing Gary to pull _OEL high.

Gary Pin 3 is not shorted to VCC. Also verified other end, pin 1 on LS373 is not shorted to VCC. Good suggestion.

Originally Posted by Toni Wilen

Stuck _OE probably means CPU reads would not work correctly when reading chipset side bus (and would explain all problems, green screen and vertical counter returning static data and working serial writes and ROM reads).

Does LATCH Gary signal change state?

As was already said, measure the pin and also try disconnecting it from socket (by carefully bending it). If pin starts changing state (it is output pin), something is wrong with either TTL latch chips or line is shorted to something.

Do you get normal PAL/NTSC timed pulses in Agnus vsync and hsync lines? If they do appear normally, vertical counter inside Agnus has to count and problem is almost guaranteed to be outside of Agnus.

When Gary pin 3 is lifted it is still high (on lifted pin). LS373 pin 1 is now at ~2v. There must be an input to Gary that tells him to start the OE. Let me compare other signals on Gary's pins.

Pin 1-2: same
Pin 3-4 (OEL/OEB): Stuck high on bad MB
Pin 5-9: same
Pin 10-17: same
Pin 18,19,20 (_RAMEN,_BLISS,_RAMGEN all from/to Agnus): Stuck high on bad MB
Pin 21-24: same
Pin 25 _Latch: same
Pin 26 -32: same
Pin 40-48: same

Data lines
Pin 33: same
Pin 34-37:high on bad mb
Pin 38: same
Pin 39: high on bad mb

The variance in the data lines could be normal for a board that won't start?

[retrofriends]

Problem solved. DiagROM will report a Raster error if it is able to address the DRAM, but cannot get the correct data. This would have to be either the Data Path logic (theoretically), or the DRAM itself. In my case, it was the DRAM. ONE chip was bad. Please post if you know more about this.

I spent many hours looking for bad traces and bad logic. It really threw me that the "piggybacking" method of diagnosis did not work. Also DiagROM got past its initial chipmem detection (probably just an addressing phase?). So I quit looking at the DRAM and the goose-chase ensued. Output enables to the LS373s are stuck high on Gary, but this was just because the A500 couldn't finish starting because of bad DRAM (chicken and the egg).

Video of this board on YouTube:

[ Show youtube player ]