English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware

 
 
Thread Tools
Old 30 December 2019, 04:04   #1
retrofriends
Registered User

 
Join Date: Dec 2019
Location: California / USA
Posts: 10
A500 Green Screen. DiagROM says: "raster: NOT DETECTED"

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?
retrofriends is offline  
Old 30 December 2019, 09:14   #2
solarmon
Registered User

solarmon's Avatar
 
Join Date: Dec 2018
Location: UK
Posts: 844
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?
solarmon is offline  
Old 30 December 2019, 13:15   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,796
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?
Toni Wilen is offline  
Old 31 December 2019, 03:39   #4
retrofriends
Registered User

 
Join Date: Dec 2019
Location: California / USA
Posts: 10
Capture from Serial Port

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 is offline  
Old 31 December 2019, 04:06   #5
retrofriends
Registered User

 
Join Date: Dec 2019
Location: California / USA
Posts: 10
Floppy disk

Quote:
Originally Posted by Toni Wilen View Post
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.
retrofriends is offline  
Old 31 December 2019, 10:26   #6
solarmon
Registered User

solarmon's Avatar
 
Join Date: Dec 2018
Location: UK
Posts: 844
Have you checked the RGA (Register Address Bus) signals/traces between Agnus, Paula and Denise?
solarmon is offline  
Old 31 December 2019, 12:07   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,796
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.
Toni Wilen is offline  
Old 31 December 2019, 19:19   #8
retrofriends
Registered User

 
Join Date: Dec 2019
Location: California / USA
Posts: 10
Lightbulb

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 is offline  
Old 01 January 2020, 04:20   #9
retrofriends
Registered User

 
Join Date: Dec 2019
Location: California / USA
Posts: 10
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.
retrofriends is offline  
Old 01 January 2020, 09:59   #10
solarmon
Registered User

solarmon's Avatar
 
Join Date: Dec 2018
Location: UK
Posts: 844
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.
solarmon is offline  
Old 01 January 2020, 11:58   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,796
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.
Toni Wilen is offline  
Old 02 January 2020, 01:54   #12
retrofriends
Registered User

 
Join Date: Dec 2019
Location: California / USA
Posts: 10
Quote:
Originally Posted by solarmon View Post
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.

Quote:
Originally Posted by Toni Wilen View Post
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 is offline  
Old 18 January 2020, 04:04   #13
retrofriends
Registered User

 
Join Date: Dec 2019
Location: California / USA
Posts: 10
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 ]
retrofriends is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Wanted: 120V LCD NTSC+PAL Monitor with a monochrome "Green" option Hi, does anyone k Starglider 2 support.Hardware 2 04 January 2018 17:34
New "Stable" of my DiagROM Chucky support.Hardware 4 07 August 2016 10:28
"Not enough RAM detected"?/"Inappropriate configuration found"? stevsurv Retrogaming General Discussion 15 04 October 2012 21:26
Wanted: A1200 keyboard "green ribbon board" 8bitbubsy MarketPlace 2 20 January 2011 08:01
Paul; The Green Alien - "Tribute" thread... DamienD Nostalgia & memories 25 29 May 2007 23:05

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.12710 seconds with 15 queries