Jump to content
ktelep

Testing 6502C Sally in another 6502 SBC?

Recommended Posts

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.

  1. Reseated all the chips
  2. Built a DRAM tester and confirmed all the RAM is good
  3. Tried on both RF and Monitor connections
  4. 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?

Share this post


Link to post
Share on other sites

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 ;) 

  • Haha 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (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 by ktelep

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (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 by ktelep

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
Posted (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 by ktelep

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

The immediate C000 area has ID and checksum info so should only be read during system initialization and never executed.

Share this post


Link to post
Share on other sites

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.   

Share this post


Link to post
Share on other sites

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.

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

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.  

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

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...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...