Jump to content
IGNORED

800XL red screen


jum
 Share

Recommended Posts

Hi, I have a PAL 800XL with red screen syndrome.

 

I have been trying to troubleshoot the cause of the fault (using the field service and Sams manual), would appear to be something wrong in the address decoding, mmu or roms. I'm kind of stuck now until I can get hold of some chips to swap out.

 

Anyway, I noticed that the signal on the data bus looks a little weird. See attached oscilloscope pics (The light blue signal is a line on the address bus, and the yellow is a line on the data bus).

 

Anyone seen this before or know what causes it?

 

Cheers - James

 

 

 

 

post-4417-0-49843100-1455558076_thumb.jpg

post-4417-0-51970400-1455558086_thumb.jpg

Link to comment
Share on other sites

RED screen...

 

I have seen this when:

OS rom is bad

CPU is bad

DRAM is bad

 

Hard to tell...

You should get yourself a SysCheck II device from Abbuc. This is one of those situations where you can't live without. I have been using it a few times, and it really made life easier.

  • Like 2
Link to comment
Share on other sites

OS is unable to start early initialization. GTIA will often/usually display a reddish brown as background colour on startup, this is normally cleared by OS startup within about 1/2 second.

 

Bad Ram won't necessarily be the cause though if the Ram is outputting data in an unsolicited way it could crash the CPU.

Easy way to test, remove all the Ram, easy so long as it's socketed that is.

 

My order of suspicsion would be CPU, Antic, MMU, OS Rom. This is a lot easier to debug if you have a similar known good machine to test swap components.

  • Like 1
Link to comment
Share on other sites

OS is unable to start early initialization. GTIA will often/usually display a reddish brown as background colour on startup, this is normally cleared by OS startup within about 1/2 second.

 

Bad Ram won't necessarily be the cause though if the Ram is outputting data in an unsolicited way it could crash the CPU.

Easy way to test, remove all the Ram, easy so long as it's socketed that is.

 

My order of suspicsion would be CPU, Antic, MMU, OS Rom. This is a lot easier to debug if you have a similar known good machine to test swap components.

I'll try removing all the RAM (luckily everything is socketed). What should happen if I boot without RAM?

Edit: Removed all the RAM. No difference (red screen as before).

 

I have already swapped the CPU with the one from my broken 5200 (unknown condition). No difference.

 

My 5200 is NTSC, so I don't think I can swap its ANTIC into the PAL 800XL.

 

Atari 600/800s are extremely rare in these parts, difficult to find a known good machine.

Edited by jum
Link to comment
Share on other sites

For the purpose of testing it's fine to use the Antic from NTSC 5200.

Swapped in the ANTIC from my 5200. No change.

 

I was checking the reset circuit again, according to Sams troubleshooting guide. I noticed that there is no delay between power on and 5V on pin 8 of U19 (74LS14). See attached screenshot. Checked capacitor C49 (47uF), it takes 20+ seconds to charge up to around 5V. Is this normal?

 

PS: Thanks for all your replies, I wasn't expecting so much help :)

post-4417-0-85792700-1455740899_thumb.jpg

Edited by jum
Link to comment
Share on other sites

No harm replacing suspect capacitors.

 

The power-on Reset sounds maybe not right. The thing with XL or XE though is that when you press the Reset key it also generates a hardware Reset and would coldstart the machine for you.

That said though, if the circuit generating Reset is faulty then you probably have an issue.

 

Since you have means to monitor individual pins, can you see what the Sync pin on 6502 does on powerup? Normally it should activate each time a new instruction is fetched, ie every 2-7 cycles, occasionally much more due to DMA loss.

  • Like 1
Link to comment
Share on other sites

Seems like the RESET is actually working as expected (I was previously measuring PIN 14 of U19, not pin 8 (doh!)). (See attached reset1,jpg). There is a delay of about 350ms after power on, before RESET goes high. (C49 is charged to about 1.6V before U19 pin 8 goes high).

 

Also attached are traces from the SYNC pin on the 6502 (sync signal in cyan).

post-4417-0-69646600-1455827966_thumb.jpg

post-4417-0-25541800-1455827983_thumb.jpg

post-4417-0-00035000-1455827999_thumb.jpg

post-4417-0-91443500-1455828012_thumb.jpg

post-4417-0-72692000-1455828025_thumb.jpg

Link to comment
Share on other sites

  • 2 weeks later...

Seems like the RESET is actually working as expected (I was previously measuring PIN 14 of U19, not pin 8 (doh!)). (See attached reset1,jpg). There is a delay of about 350ms after power on, before RESET goes high. (C49 is charged to about 1.6V before U19 pin 8 goes high).

 

Also attached are traces from the SYNC pin on the 6502 (sync signal in cyan).

 

When SYNC is toggling sometimes, then it seems that the OS could start the very first part of coldstart (RESET) routine. First is to watch every D0...D7 and A0...A15 line. I´ve had some bad CPUs in the past where only one address line was broken. In some cases the system could start, but crashes after a few opcodes, of course. You can see this immediately with your scope.

 

You can use NTSC ANTIC or GTIA for testing, you also should get a picture, but it´s black/white. And if you have a very old "PAL only" television or monitor, the picture may roll. But for a quick test it´s ok.

 

In over 80% of these issues bad DRAM is the reason why the computer won´t start. Even when there are only some bits bad, when the CPU´s stack ($0100-$01FF) is affected, the OS-ROM coldstart subroutine will return to Nirvana - computer hangs. So changing the DRAMs is the first thing you should do. You can use any 4164 DRAM (as also found in some C64, Apple II and some other 8-Bit machines) or 41256 DRAMs (found on a lot of Amiga 500 memory expansions, all Atari ST 260,520,1040 ST/STF (not STE) and so on...).

 

Jurgen

Edited by tf_hh
  • Like 3
Link to comment
Share on other sites

 

When SYNC is toggling sometimes, then it seems that the OS could start the very first part of coldstart (RESET) routine. First is to watch every D0...D7 and A0...A15 line. I´ve had some bad CPUs in the past where only one address line was broken. In some cases the system could start, but crashes after a few opcodes, of course. You can see this immediately with your scope.

 

You can use NTSC ANTIC or GTIA for testing, you also should get a picture, but it´s black/white. And if you have a very old "PAL only" television or monitor, the picture may roll. But for a quick test it´s ok.

 

In over 80% of these issues bad DRAM is the reason why the computer won´t start. Even when there are only some bits bad, when the CPU´s stack ($0100-$01FF) is affected, the OS-ROM coldstart subroutine will return to Nirvana - computer hangs. So changing the DRAMs is the first thing you should do. You can use any 4164 DRAM (as also found in some C64, Apple II and some other 8-Bit machines) or 41256 DRAMs (found on a lot of Amiga 500 memory expansions, all Atari ST 260,520,1040 ST/STF (not STE) and so on...).

 

Jurgen

Thanks Jurgen

All the address lines have pulses, but only 2 data lines seem to have proper pulses.

My 800XL has 4564 RAM chips. I will try swap in some 4164 chips from my broken Apple II and an old XT motherboard.

Maybe I will test my RAM using Arduino:

https://juhannuskameli.wordpress.com/2014/01/05/playing-with-arduino-and-dram/

http://blog.atmel.com/2013/10/14/c64-dram-testing-with-an-atmega8u2/

I also have a very cheap USB logic analyser that I need to learn...

  • Like 1
Link to comment
Share on other sites

  • 1 year later...

FINALLY - SOME CLOSURE!

 

Well today I finally managed to fix the 800XL :) :-D :) :-D :)

 

After lots more probing and investigating and swapping out chips with my 600XL, I noticed with my cheap logic analyser that the correct reset vector ($C2AA?) was not being loaded on reset, meaning OS ROM was not being enabled on reset, which lead me to discover that the 6520 PIA was not pulling the REN line on the MMU high (like ti should be doing). So I swapped out the PIA with the PIA from my 600XL and happy day there was the "READY" text on the screen!

 

(Never thought to swap the PIA before as I have never seen it mentioned as a common failure).

 

Thanks for all the help and cheers! I'm going to have a beer now...

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...