A1200 green screen - seemingly quite random chip mem access issues with diagrom, any ideas?

  • Thread starter Thread starter ctrlbreak
  • Start date Start date
  • Replies Replies 8
  • Views Views 636

ctrlbreak

Active member
AmiBayer
Joined
Jan 28, 2024
Posts
181
Country
United Kingdom
Region
London
I've got an A1200 with green screen, and I'm struggling to diagnose the issue.

Sadly I fear it's not as simple as a broken trace etc, or even bad RAM chip(s), but I'm still hopeful!

I inherited this machine and the first time I turned it on, it got to workbench disk screen, but then started to alternate with green screen, and now always green screen (with KS3.0 and 3.2.2).

Likely leaky cap damage you say? Well... the board was in immaculate condition with no obvious signs of electrolyte damage. I have de-capped (not yet recapped) and there was some leakage immediately below a couple of the caps which is cleaned up but nothing that seemed too bad. I'm not ruling it out, but given the diagrom output it's hard to understand what might be going on.

Diagrom:

I get random results from the chipram testing. Some addresses fail, Bit 10 is always "1" on read - this could indicate a problem with a data line or RAM chip (I think this is D10, but correct me if I'm wrong?), and it detects random amounts of "working" chip memory. Which then always fails later in working memory test, anyway. To me this looks like some kind of instability/inconsistency with the ram access/bus, but not sure where to start?

It's a REV 2B, so I understand it uses each chip to store 8 bits per 32 bit address.

I've checked VCC to the RAM chips
I've checked continuity on a bunch of the data lines and also CAS/RES etc, but all seem to be fine.
Alice is getting warm but not mental
I've checked the PSU voltages and they're rock solid, and the same PSU runs an A1200/pistorm with no issues.

Next step is to scope out some signals I guess (which requires me to get my scope back from a friend!), but I wondered if anyone had experience with similar issues to point me in the right direction?

I have some replacement ram chips but I'm loath to do SMD replacement until I'm a bit clearer on whether they're the issue or this indicates a custom issue (maybe alice or budgie?) or something completely separate.

Thanks in advance! :)


Example diagrom output:

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

Addr $00000400
Write: $FFFFFFFF 11111111111111111111111111111111
Read: $AAAA0400 10101010101010100000010000000000 FAILED

Write: $AAAAAAAA 10101010101010101010101010101010
Read: $AAAA0400 10101010101010100000010000000000 FAILED

Write: $55555555 01010101010101010101010101010101
Read: $AAAA0400 10101010101010100000010000000000 FAILED

Write: $F0F0F0F0 11110000111100001111000011110000
Read: $AAAA0400 10101010101010100000010000000000 FAILED

Write: $0F0F0F0F 00001111000011110000111100001111
Read: $AAAA0400 10101010101010100000010000000000 FAILED

Write: $0F0FF0F0 00001111000011111111000011110000
Read: $AAAA0400 10101010101010100000010000000000 FAILED

Write: $00000000 00000000000000000000000000000000
Read: $AAAA0400 10101010101010100000010000000000 FAILED
Addr $00010400
Write: $FFFFFFFF 11111111111111111111111111111111
Read: $14617741 00010100011000010111011101000001 FAILED

Write: $0F0F0F0F 00001111000011110000111100001111
Read: $FFFFFFFF 11111111111111111111111111111111 FAILED
Addr $00020400
Write: $FFFFFFFF 11111111111111111111111111111111
Read: $14617745 00010100011000010111011101000101 FAILED

...SNIP - SOME TIME LATER (sometimes it doesn't get this far, and the number of blocks found varies):

Addr $00160400 OK Number of 64K blocks found: $01
Startaddr: $00150400 Endaddr: $0015FFFF
- Testing detected Chipmem for addresserrors
- Filling memoryarea with addressdata

- Checking block of ram that it contains the correct addressdata

- Addresserror at: 00150404 00000000000101010000010000000100 A2EAA2AA
- Addresserror at: 0015040C 00000000000101010000010000001100 2B15000C
- Addresserror at: 00150424 00000000000101010000010000100100 00150424
- Addresserror at: 0015042C 00000000000101010000010000101100 3A15002C
- Addresserror at: 00150444 00000000000101010000010001000100 00150444
 
Anyone got any thoughts on these type of memory errors with diagrom and how best to diagnose? I'd expect if it was a single RAM chip that it would be more consistent, so I'm wondering if it's Alice or some other issue... Any thoughts gratefully received! Thanks
 
Anyone got any thoughts on these type of memory errors with diagrom and how best to diagnose? I'd expect if it was a single RAM chip that it would be more consistent, so I'm wondering if it's Alice or some other issue... Any thoughts gratefully received! Thanks
Non expert , does this only happen at address &400 or others? If others then doesn't this suggest the ram adress lines are ok, but perhaps the data I/O lines are suspect. >


Test of writing word $AAAA to $400 FAILED
- Test of writing word $00AA to $400 FAILED
- Test of writing word $AA00 to $400 FAILED
- Test of writing word $0000 to $400 OK
- Test of writing byte (even) $AA to $400 OK
- Test of writing byte (odd) $AA to $401 OK
 
Thanks Elmo.
It's random addresses, sometimes more areas read as ok in the tests and it detects more ram, but then has issues checking if it can use that RAM later. Sometimes (rarely) the initial word writing tests actually pass.
My suspicion was damage to one or more data lines, but I've traced them out and they seem ok at the test points (alice, RAM, VIAs) that I've checked.
Also, because it's not (just) a single bit or set of bits that correlate with a single RAM chip, I'm not convinced it's a RAM chip failure (but also, have never debugged an issue like this, hence my post!)
What's odd is that this M/B was unused for 20 years, and the first couple of times I powered it up it did get to the purple insert disk screen. That's why I assumed it was cap damage initially, but really doesn't seem like it so far.
My suspicion is Alice but I don't want to go replacing her if anyone has ideas on something else! :)
Thanks
 
Hi,

It could easily be one of the DRAM chips.
But you would have to look carefully at the solder joins on these same chips also in BUDGIE, and check the CAS and RAS control signals.
On those lines there are some resistors and capacitors that could be making noise due to some internal failure of these components.

So:
Check Solder joints in DRAMS, BUDGIE and resistors/caps in RAS CAS lines.
Check signals in RAS CAS to see what happen here
The components itself DRAM BUDGIE or some resistor/caps in control lines RAS/CAS find hot points on its or try freezer spray and hairdrier with carefull to see if any changes (we aware BAD solder joins also respond to temperatura changes)

good luck
 
Last edited:
Thanks both.

Do you have a scope to debug css/ras....?
Not in hand but getting mine back from a friend or buying an upgrade soon :)

Check Solder joints in DRAMS, BUDGIE and resistors/caps in RAS CAS lines.
Check signals in RAS CAS to see what happen here
The components itself DRAM BUDGIE or some resistor/caps in control lines RAS/CAS find hot points on its or try freezer spray and hairdrier wit carefull to see if any changes (we aware solder joins also respond to temperatura changes)
Good pointers. Will try these and see how I get on, thanks!
 
As already mentioned Budgie can be the problem
in German so translate
 
Back
Top Bottom