jum Posted February 15, 2016 Share Posted February 15, 2016 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 Quote Link to comment Share on other sites More sharing options...
Marius Posted February 15, 2016 Share Posted February 15, 2016 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. 2 Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 15, 2016 Share Posted February 15, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
ClausB Posted February 16, 2016 Share Posted February 16, 2016 What's the time scale on your scope traces? Quote Link to comment Share on other sites More sharing options...
Paul Westphal Posted February 16, 2016 Share Posted February 16, 2016 Open it up and take off the RF shield. Power on the system. After a minute, see which chip(s) get HOT. That's your culprit. It's old school, but it works. 1 Quote Link to comment Share on other sites More sharing options...
jum Posted February 16, 2016 Author Share Posted February 16, 2016 What's the time scale on your scope traces? 1us (microsecond) Quote Link to comment Share on other sites More sharing options...
jum Posted February 16, 2016 Author Share Posted February 16, 2016 (edited) 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 February 16, 2016 by jum Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 16, 2016 Share Posted February 16, 2016 If the CPU is good but the (now removed) Ram was causing crashes, then you should get a black screen every time. 1 Quote Link to comment Share on other sites More sharing options...
ClausB Posted February 16, 2016 Share Posted February 16, 2016 The yellow scope trace looks normal for data lines. The 6502 only drives the data bus for about half of each 560 ns cycle and you are seeing the undriven bus charging up during the other half, looking like a sawtooth. 2 Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 16, 2016 Share Posted February 16, 2016 For the purpose of testing it's fine to use the Antic from NTSC 5200. 1 Quote Link to comment Share on other sites More sharing options...
jum Posted February 17, 2016 Author Share Posted February 17, 2016 (edited) 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 Edited February 17, 2016 by jum Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 18, 2016 Share Posted February 18, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
jum Posted February 18, 2016 Author Share Posted February 18, 2016 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). Quote Link to comment Share on other sites More sharing options...
jum Posted March 1, 2016 Author Share Posted March 1, 2016 Wrote a little Arduino sketch to test the MMU (PAL16L8): http://hackaday.io/project/9932-arduino-vs-pal16l8 Results seem to indicate that it is functioning normally (output states for given input states match as per mmupal.src). However there is still a possibility that the chip is flaky under real conditions. 1 Quote Link to comment Share on other sites More sharing options...
+tf_hh Posted March 1, 2016 Share Posted March 1, 2016 (edited) 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 March 1, 2016 by tf_hh 3 Quote Link to comment Share on other sites More sharing options...
jum Posted March 1, 2016 Author Share Posted March 1, 2016 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... 1 Quote Link to comment Share on other sites More sharing options...
rockdoc2010 Posted March 2, 2016 Share Posted March 2, 2016 an oscilloscope on an eight bit?!? YOU ROCK! Quote Link to comment Share on other sites More sharing options...
jum Posted June 18, 2017 Author Share Posted June 18, 2017 FINALLY - SOME CLOSURE! Well today I finally managed to fix the 800XL 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... 3 Quote Link to comment Share on other sites More sharing options...
jum Posted June 23, 2017 Author Share Posted June 23, 2017 Correction: the 6520 PIA was holding the REN line LOW, not allowing it to default HIGH thru its pull-up resistor. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.