ktelep Posted June 11, 2021 Share Posted June 11, 2021 I recently was given an 800XL for free, was told it worked. Power it up, just get a black screen and two pops on the audio. Ran through all the black screen tests I could find online. Reseated all the chips Built a DRAM tester and confirmed all the RAM is good Tried on both RF and Monitor connections Confirmed clock is running at ~1.6Mhz and Reset is good across the board So I'm at where the service guide says "Isolate and replace" the ICs, but I don't have a working 800XL to swap them in and out with... I hooked up my logic analyzer to the address and data lines at the processor, triggering on FFFC, hoping to get the reset vector and see if maybe it wasn't getting data from the ROM. It almost looks like it's just cycling through addresses like it's running NOPs. Example: Addr Data Halt RW FFFB 86 1 1 86BF FF 1 1 0085 21 1 1 FFFF C0 0 1 FFFC EC 1 1 C0FE 86 1 1 86BF 86 1 1 0085 21 0 1 FFFD FF 1 1 FFFF C0 1 1 C0FE 86 1 1 86BF 86 1 1 0085 21 1 1 I then pulled out the 6502C and put it in my homebrew 6502, tying the HALT pin High (pinout appears to be the same minus the halt line) it looks like it starts to run my monitor code, but then just all goes to garbage and I only see 00FF on the address lines (swapping my NMOS 6502 back into my homebrew system makes it work fine again) Not sure if putting it into my HBC and tying Halt high was a valid test, but it seems to me like the proc is not functioning as expected. Is there any other differences with the 6502C that might also be impacting how I'm testing it? Quote Link to comment Share on other sites More sharing options...
ivop Posted June 11, 2021 Share Posted June 11, 2021 Tying /HALT to high seems like a valid test. No ANTIC there to /HALT the CPU. This looks like a b0rked Sally. The address line capture makes no sense at all. There's almost a C0vFEFE in there 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 11, 2021 Share Posted June 11, 2021 Differences vs normal legacy 6502 should just be in the pinout and as you've mentioned the /Halt pin is active low so should be held high if the CPU is used outside it's normal home. 2 audio pops though - normally you get audio pop on powerup and if you press Reset - this is a good diagnostic sign that the CPU and OS are at least partially good. Also a black screen or screen that starts reddish brown then goes black is usually a sign of that too. But if your tests are working properly that does look like a sick or dead CPU. Quote Link to comment Share on other sites More sharing options...
guus.assmann Posted June 12, 2021 Share Posted June 12, 2021 If memory serves right, there's one more difference between Sally and a 6502. The R/W pin is on another location. Just jumper the NC pin and the RW and it should work. Of cource holding the Halt pin high is also needed. BR/ Guus Quote Link to comment Share on other sites More sharing options...
+warerat Posted June 12, 2021 Share Posted June 12, 2021 It may be interesting to capture the states right after reset goes high for further insight. The 6502 takes 7 cycles to reset as it follows the same sequence as an interrupt, but slightly modified in that it has dummy read accesses to the stack. If the CPU is sane, right out of reset you should see a sequence stack read accesses at 00FF, 0100, 01FF, and 01FE right before the reset vector pull at FFFC. Then you'll know if you're really coming out of reset and pulling the right address from ROM at the reset vector. Quote Link to comment Share on other sites More sharing options...
ktelep Posted June 14, 2021 Author Share Posted June 14, 2021 Should have taken a look one last time before I ordered a new CPU from eBay, hopefully the seller will be willing to cancel the sale, but we'll see. I pulled HALT high, and also jumped 34 to 36 for R/W and sure enough it runs code in my HBC just fine (thanks guus.assmann) I'll have to hook up the analyzer again and see if I can figure out what is putting this garbage onto the address bus, I will start my capture on the change in reset line and see what we get from there, maybe some more/different clues. For someone coming along later- 1. Moved the CPU into my Homebuilt 6502 computer. 2. Jumper pin 8 to pin 35 (VCC to Halt) - This is due to a standard 6502 no having a halt line, we need to keep it high so the CPU runs. 3. Jumper pin 34 to 36 (R/W to NC) due to R/W being on a different pin than a standard 6502 4. Run Code, and see what happens. 1 Quote Link to comment Share on other sites More sharing options...
Gunstar Posted June 15, 2021 Share Posted June 15, 2021 Don't cancel, you never know when you'll need a replacement CPU anyway. It's better to have back-ups. I have several back-ups of all the main and support IC's for my Atari's and over the last few years have had to use some already. 1 Quote Link to comment Share on other sites More sharing options...
ktelep Posted June 19, 2021 Author Share Posted June 19, 2021 (edited) Determined to figure out what's not working without just buying a lot of parts. Swapped the CPU with the new one just for giggles and I have the same results. Hooked the analyzer back up, but this time added the reset signal to the trigger, and we get a good 6502 reset. Now that I'm triggering at Reset, I seem to be getting a better view of what the system is doing. Definitely am getting data from the ROM on startup. The reset vector comes back with C2AA, which matches what the memory map I found. So we know we can read from ROM and at least the memory address it returns is good, and we seem to go right into a delay loop based on instructions I see on the bus (8C in X, DEC Y from 00 to FF) Here's where things get interesting though, Eventually we start to see the Antic halting the CPU every fourth clock and (I'm assuming it's the Antic) start scanning through addresses, starting with $FF81 through $FF89, then for about 100 clock cycles nothing, then another nine address $FF8A through $FF92. This repeats until it gets to $FFFF, then resets back to $FF81. Based on the memory map, this seems to be in the middle of the ROM checksum subroutines and into the reset vector, so doesn't make ANY sense. I'm assuming this is NOT expected behavior and probably should be replaced? I should also note that when it's probing these, the MMU isn't enabling the OS ROM, but I haven't probed all the inputs on the MMU yet to see what they're doing. I've also noticed that A7 seems to just get held high, no matter what else is going on with the system, this might be a real symptom, or just the fact that due to what the Antic is doing the system just isn't addressing anything that would involve A7 being 0 by the time the CPU crashes and just starts spitting out 00FF. It looks like A7 has connections to: Sally (known good) Antic (bent pin out for A7, see the same results) U27 - 74LS158 (this has potential since it's part of the RAM decoding) OS ROM (Reset vector is C2AA and it doesn't seem like we ever get below that address before the system crashes) Basic ROM Edited June 19, 2021 by ktelep Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 19, 2021 Share Posted June 19, 2021 Those Antic addresses I should think are probably refresh cycles and would be row numbers - the high byte irrelevant. There's a /REF signal from Antic so if you have the means you could probe that and see if it corresponds there. "Every 4th cycle" though is the default refresh pattern once refresh starts on a scanline. U26 and U27 are just used for Ras/Cas Ram accesses by the CPU. Aside from refresh cycles the accesses Antic makes are controlled by DMACTL, and on a freshly powered on system there should be no Ram reads by Antic until the blue text screen is opened. Antic refreshes are generally 9 per scanline (114 cycles) though the pattern and number can be altered when it is generating graphics. 1 Quote Link to comment Share on other sites More sharing options...
ktelep Posted June 19, 2021 Author Share Posted June 19, 2021 (edited) Bingo, I added the /REF signal to my trace and that aligns with when the $FFxx are being accessed, so now THAT makes sense. I started working backwards state-to-state, trying to find the point where things stop working, and I think I found it. It appears that might have to do with something performing an interrupt, as it looks like once the system gets into the interrupt handler space (lots of addresses working around C0A0 and C0CF) it accesses the following addresses: ADDR - Data C0CE - 40 C0CF - 80 01FC - F0 01FD - E0 01FE - F1 01FF - 21 C001 - 92 C002 - 19 FFFF - C0 FFFE - 2C FFFE - 2C FFFF - 2C FFFF - 2C FFFF - 2C <etc> So I'm wondering if what I actually have here is a corrupt OS ROM? Is there a dump of it somewhere that I can compare to mine? This failure happens 100% of the time and is repeatable. I just swapped out the RAM with known good just to be sure and get the same results. Edited June 19, 2021 by ktelep Quote Link to comment Share on other sites More sharing options...
+warerat Posted June 19, 2021 Share Posted June 19, 2021 I'm not convinced that the memory has been ruled out. This is easily confirmed with some selective triggers in the ROM address space. Your first write to the stack at power up occurs at $C2D1 (JSR $C471) and next at $C484 (JSR $C4DA), which is the I/O chip initialization. C2CC:78 SEI C2CD:D8 CLD C2CE:A2 FF LDX #$FF C2D0:9A TXS C2D1:20 71 C4 JSR $C471 C2D4:A9 01 LDA #$01 C47C:AD FD BF LDA $BFFD C47F:10 03 BPL $C484 C481:6C FE BF JMP ($BFFE) C484:20 DA C4 JSR $C4DA C487:AD 01 D3 LDA $D301 ;PORTB It is in this code block where you will encounter the first RTS which will pull the return address back from the stack in RAM. So if you get the wrong return address here, you know there is definitely a problem with the memory. So trigger and capture at $C534 which is the first RTS. Right after the $60, you should see the two stack pulls for address $C486, which is one less than the return address of $C487. Now whether it's the support circuitry or the chips themselves will require further techniques. C4DA:A9 00 LDA #$00 C4DC:AA TAX C4DD:8D 03 D3 STA $D303 ;PBCTL C4E0:9D 00 D0 STA $D000,X ;HPOSP0 C4E3:9D 00 D4 STA $D400,X ;DMACTL C4E6:9D 00 D2 STA $D200,X ;AUDF1 C4E9:E0 01 CPX #$01 C4EB:F0 03 BEQ $C4F0 C4ED:9D 00 D3 STA $D300,X ;PORTA C4F0:E8 INX C4F1:D0 ED BNE $C4E0 C4F3:A9 3C LDA #$3C C4F5:8D 03 D3 STA $D303 ;PBCTL C4F8:A9 FF LDA #$FF C4FA:8D 01 D3 STA $D301 ;PORTB C4FD:A9 38 LDA #$38 C4FF:8D 02 D3 STA $D302 ;PACTL C502:8D 03 D3 STA $D303 ;PBCTL C505:A9 00 LDA #$00 C507:8D 00 D3 STA $D300 ;PORTA C50A:A9 FF LDA #$FF C50C:8D 01 D3 STA $D301 ;PORTB C50F:A9 3C LDA #$3C C511:8D 02 D3 STA $D302 ;PACTL C514:8D 03 D3 STA $D303 ;PBCTL C517:AD 01 D3 LDA $D301 ;PORTB C51A:AD 00 D3 LDA $D300 ;PORTA C51D:A9 22 LDA #$22 C51F:8D 0F D2 STA $D20F ;SKCTL C522:A9 A0 LDA #$A0 C524:8D 05 D2 STA $D205 ;AUDC3 C527:8D 07 D2 STA $D207 ;AUDC4 C52A:A9 28 LDA #$28 C52C:8D 08 D2 STA $D208 ;AUDCTL C52F:A9 FF LDA #$FF C531:8D 0D D2 STA $D20D ;SEROUT C534:60 RTS Quote Link to comment Share on other sites More sharing options...
ktelep Posted June 19, 2021 Author Share Posted June 19, 2021 (edited) Wow, thanks for the source here, was going to go hunt it down later and see if I could line up what was happening. I think memory is good, I set my trigger up at $C534 as suggested, here's what shows up on the analyzer, although I'm starting to question if I have the triggering and clock setup properly, as it doesn't seem like the halt is occurring during the correct state, but I've got VERY little experience working with systems using DMA. Currently triggering on the falling clock, since I expect that address and datalines should be come stable while the clock is high. ADDR DATA HALT C532 0D 1 C533 D2 1 D20D FF 1 C534 60 0 <--- RTS FFA4 FF 1 C535 C6 1 01FB FF 1 01FC 86 0 <--- LSB of return FFA4 FF 1 01FD C4 1 <--- MSB of return C486 C4 1 C487 AD 0 FFA6 FF 1 C488 01 1 C489 D3 1 D301 FF 0 I'm tempted to write an EEPROM with some test code to just read and write to all the memory addresses to do a full test, but not sure if I'll have time tonight to desolder the OS rom, add a socket, then put it all back together and test. Edited June 19, 2021 by ktelep Quote Link to comment Share on other sites More sharing options...
ktelep Posted June 20, 2021 Author Share Posted June 20, 2021 Looking at the end of my results from previous runs, it looks like it's calling an RTI (40), then popping the status flags, then the program counter, but it doesn't make sense that it's trying to go to C001 following that, as the PC should be $21F1. Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 20, 2021 Share Posted June 20, 2021 The immediate C000 area has ID and checksum info so should only be read during system initialization and never executed. Quote Link to comment Share on other sites More sharing options...
ktelep Posted June 20, 2021 Author Share Posted June 20, 2021 This morning I had some time, so did some more testing/work. I confirmed continuity for all the memory address lines back to the 74LS158s and the data read/write lines back to the data bus, everything is good, so *theoretically* I don't have any socket issues. I also pulled the 74LS158s and tested them with my programmer (which conveniently has a logic IC test function) and they were good. I did the same for the 74138 that's part of the memory management and it also tested good. The big unknown in the memory path is the MMU and the delay line IC. I have some GALs, so might have thought about seeing if I can just replace the MMU, I found the code for it already online, but that might be a longshot. I think now that the ROM is socketed I'm going to write a little bit of code to walk through the user accessible portion of memory and do some write and read patterns and make sure that IN PLACE the memory is working as expected vs. outside of the system. Quote Link to comment Share on other sites More sharing options...
+warerat Posted June 20, 2021 Share Posted June 20, 2021 You could also use this tool that was written by a member here that tests the memory. It takes the place of the OS ROM. 1 Quote Link to comment Share on other sites More sharing options...
ktelep Posted July 18, 2021 Author Share Posted July 18, 2021 Finally circling back onto this project today. I grabbed Shoestring's 8bit RAM tester, tossed it on a EEPROM and fired it up. We at least have life now and it shows something on the screen! Unfortunately it fails immediately with a red arrow next to U13. I swapped U13 with a known good RAM from another 800XL, and still fails the same way. Swapped all the RAM with known good RAM from the other 800XL and same failure. Start walking through and swapping chips from the broken 800XL to the working one and I've found that the PIA also causes the other 800XL to fail startup, however putting the known good 800XL in the failing system still doesn't resolve the issue. SO I've gone brute force and have one by one been swapping the ICs from the failed system into the working system, assuming a secondary failure of two ICs maybe? All the logic chips test fine and the working system boots when them in. I'm at the point when I'm ready to start testing/replacing individual discrete components, but hoping the fact that the 6520 is toast might be a hint as to where else to look? I did notice that on my failed system there is a resistor "bodged" in at the factory to pin 2 of each DRAM chip whereas on my donor working system that resistor is not there. Quote Link to comment Share on other sites More sharing options...
guus.assmann Posted July 19, 2021 Share Posted July 19, 2021 If those resistors are 33Ohm or so, then it's a patch to reduce "signal ringing" from the DRAM´s during access and refresh. Of course they should be ok, but that´s an easy test. Replacing the MMU with a Gal16V8 is no problem. (in most machines, not so if the Freddy-chip is present, like in a 65XE or 130XE) The 6520 may be replaced by a 68B21. The 6821 can stand a bit more "abuse" and is less likely to fail. BR/ Guus Quote Link to comment Share on other sites More sharing options...
ktelep Posted July 25, 2021 Author Share Posted July 25, 2021 (edited) I have solved my issues! I finally said screw it, and started replacing all of the sockets with dual wipe. When I got to the RAM sockets, I found that the trace between pin 9 on U13 and pin 9 on U14 was damaged (lord knows how or why) but I put a small jumper on the bottom of the board between the two pins and now I can run all the memory tests successfully from the RAM test ROM listed above. Once that ran successfully I popped in the original OS rom and she fired right up into BASIC. Now I'm running the internal memory test just to be sure that it's really all good, then I FINALLY have a working system! So the final resolution was a bad trace between U13 and U14 combined with a bad 6520. Replaced the 6520 and put a jumper in between U13 and U14. There was a lot of shouting and excitement when that blue screen popped up, I think I scared the dog too. Edited July 25, 2021 by ktelep 6 2 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 26, 2021 Share Posted July 26, 2021 On 6/11/2021 at 12:36 PM, ivop said: Tying /HALT to high seems like a valid test. No ANTIC there to /HALT the CPU. This looks like a b0rked Sally. The address line capture makes no sense at all. There's almost a C0vFEFE in there Real meaning of covfefe: https://janverhoeff.com/covfefe-end-win/ Nothing can stop what is coming. :) 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.