Testing the (Rockwell) 6502 with an XGecu TL866 II

[AndrewP]

One of the Andre's on this forum thoughtfully gave me an Apple II Rev 0 replica board. The down side being that I have to populate it

It's mostly 74LSxxx ICs which I bought from UTSource and can be tested using XGPro. Easy peasy and every single chip tested has been legit.

The problem is that - despite this being the 6502 forum - I don't actually 6502*.

I ordered a couple of Rockwell 6502s from UTSource too and they looked as suspicious as a very suspicious thing looks; two different DIP packages with identical etchings. Long story short I've been trying to work out how to test them with minimal effort, like, not even putting them in a breadboard effort.

And as I've been testing all the other ICs I bought with the TL866 II I figured I could probably use it for the 6502 too. And it turns out I can. I've attached the R6502.lgc file to this post and it can be imported into XGPro Logic Tester.

What it does:
Bring GND to ground, bring VCC to 3.3V. 5V works also but (I assume to due to ringing) the 6502 does not always reset properly.

• Line 1..14: Hold the RESET pin low for 13 clock ticks
  Test that PHI2 out matches PHI0 in
  Test that PHI1 out matches PHI0 in inverted
• Line 15: Bring RESET high and bring PHI0 low
• Line 16: Bring PHI0 high
  Test SYNC is high
  Test RWB is high
• Line 17: Bring PHI0 low
• Line 18: Bring PHI0 high
  Test SYNC is low
  Test RWB is high
• Line 19: Bring PHI0 low
• Line 20: Bring PHI0 high
  Test SYNC is low
  Test RWB is low (which I found very interesting as the W65C02 does not bring RWB low during reset.)
• Line 21 to 25: Tick the clock twice to step through the remaining stack pushes.
• Line 26: Bring PHI0 high, put $00 on the data bus
  Test the address bus contains $FFFC
• Line 27: Bring PHI0 low, put $00 on the data bus
• Line 28: Bring PHI0 high, put $00 on the data bus
  Test the address bus contains $FFFD
• Line 29: Bring PHI0 low, put $00 on the data bus
• Line 30: Bring PHI0 high
  Test the address bus contains $0000, put $EA (NOP) on the data bus
• Line 31: Bring PHI0 low, put $EA on the data bus
• Line 32: Bring PHI0 high
  Test the address bus contains $0001, put $EA on the data bus
• Line 33: Bring PHI0 low, put $EA on the data bus
• Line 34: Bring PHI0 high
  Test the address bus contains $0001, put $EA on the data bus
• Line 35: Bring PHI0 low, put $EA on the data bus
• Line 36: Bring PHI0 high
  Test the address bus contains $0002, put $EA on the data bus

If all of the above pass then we can be pretty certain that the IC is actually a genuine 6502.

In my case both my dodgy looking chips turned out to be real 6502s. Nice

And, just for pictures sake:

The fully soldered but only partially populated Apple II rev0 board I'm making.

*W65C02, W65C816 etc... But I've never used a 6502 unless you want to count the 6510.

[AndrewP]

I couldn't attach the R6502.lgc file so I've zipped it up and attached it to this post.

R6502.zip

(1.07 KiB) Downloaded 106 times

[drogon]

AndrewP wrote:

I couldn't attach the R6502.lgc file so I've zipped it up and attached it to this post.

R6502.zip

Wow. thanks.

I want to test a few 6507's - and while I can simply plug them into a known working board I have, it might be easier to do a quick test in my old TL866 II. Will it work on the Linux "minipro" command? If-so, then adapting this might not be hard...

Thanks,

-Gordon

[AndrewP]

drogon wrote:

I want to test a few 6507's - and while I can simply plug them into a known working board I have, it might be easier to do a quick test in my old TL866 II. Will it work on the Linux "minipro" command? If-so, then adapting this might not be hard...

I've never used the Linux open source minipro before (I didn't even know it was a thing until you mentioned it).

It doesn't seem like minipro supports the .lgc format (but remember this is the first day I've ever seen it so I stand open to correction). However minipro does support a user XML format that seems a lot nicer than the binary .lgc format that XGPro uses. And also someone got annoyed with XGPro's awful editor and wrote a .lgc to .toml exporter; Toml being a markup language similar to Yaml. On top of being able to convert from .toml files back to .lgc files it can also convert from .lgc files to the XML format that minipro uses.

So far I've managed to build the xgpro-logic command line tool in Ubuntu. I mean it wasn't difficult. I installed go and it just worked:

Code: Select all

git clone git@github.com:evolutional/xgpro-logic.git
sudo apt-install golang-go
cd xgpro-logic
go build  -o xgpro-logic cmd/xgpro-logic.app/main.go
./xgpro-logic -h

Now using the example file test_1j.xml given on the xgpro-logic website with content:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<infoic>
  <database device="TL866II">
    <manufacturer name="Logic Ic">
      <ic name="OLI's IC" pins="8" voltage="5.0V" type="5">
        <vector id="00"> 1 0 0 G 0 0 0 V </vector>
        <vector id="01"> 0 1 0 G 0 0 0 V </vector>
      </ic>
      <ic name="Another IC" pins="10" voltage="3.3V" type="5">
        <vector id="00"> 1 0 0 0 G 0 0 0 0 V </vector>
        <vector id="01"> 0 1 0 0 G 0 0 0 0 V </vector>
      </ic>
    </manufacturer>
  </database>
</infoic>

It can be read and tested as as user IC using minipro

Code: Select all

minipro -logicic examples/test_1j.xml -p "OLI's IC" -T

What I'm going to try tomorrow is to convert my R6502.lgc file into an XML file and attach it to my next post. If the xgpro-logic program works like it says on the tin (and I can't imagine that it doesn't) then that will make editing custom IC tests for the XGecu TL866 II so much easier. Easy enough that I might see if I can add user tests for the W65C02 and W65C816 too.

[AndrewP]

I've attached two files to this post:
xgpro-logic-dacaaf7.zip contains the binary for xgpro-logic. The dacaaf7 is the most recent git commit in the repository. If you no longer see that as the most recent commit then this is an older version.
R6502.zip contains the (probably minipro) compatible xml file.

Actually really tomorrow I'll draw up picture of exactly what is in it but for now each set of characters in the vector is the 40 pins of the 6502 and each vector line is the sequentially run process

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<infoic>
  <database device="TL866II">
    <manufacturer name="Logic Ic">
      <ic name="R6502" pins="40" voltage="3.3V" type="5">
        <!--         pin 1 2 3 4 5 6 7 8 9 101 2 3 4 5 6 7 8 9 201 2 3 4 5 6 7 8 9 301 2 3 4 5 6 7 8 9 40 -->
        <vector id="00"> G 1 X 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X X 0 </vector>
        <vector id="01"> G 1 X 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X X 0 </vector>
        <vector id="02"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="03"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="04"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="05"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="06"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="07"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="08"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="09"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="10"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="11"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="12"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="13"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="14"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 0 X L 1 </vector>
        <vector id="15"> G 1 L 1 X 1 H V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 1 X H 1 </vector>
        <vector id="16"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 0 X L 1 </vector>
        <vector id="17"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 1 X H 1 </vector>
        <vector id="18"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 0 X L 1 </vector>
        <vector id="19"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 1 X H 1 </vector>
        <vector id="20"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 0 X L 1 </vector>
        <vector id="21"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 1 X H 1 </vector>
        <vector id="22"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 0 X L 1 </vector>
        <vector id="23"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 1 X H 1 </vector>
        <vector id="24"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 0 X L 1 </vector>
        <vector id="25"> G 1 L 1 X 1 L V L L H H H H H H H H H H G H H H H 0 0 0 0 0 0 0 0 H X X 1 X H 1 </vector>
        <vector id="26"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 0 0 0 0 0 0 0 0 H X X 0 X L 1 </vector>
        <vector id="27"> G 1 L 1 X 1 L V H L H H H H H H H H H H G H H H H 0 0 0 0 0 0 0 0 H X X 1 X H 1 </vector>
        <vector id="28"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 0 0 0 0 0 0 0 0 H X X 0 X L 1 </vector>
        <vector id="29"> G 1 L 1 X 1 H V L L L L L L L L L L L L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
        <vector id="30"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 1 1 1 0 1 0 1 0 H X X 0 X L 1 </vector>
        <vector id="31"> G 1 L 1 X 1 L V H L L L L L L L L L 0 L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
        <vector id="32"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 1 1 1 0 1 0 1 0 H X X 0 X L 1 </vector>
        <vector id="33"> G 1 L 1 X 1 H V H L L L L L L L L L L L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
        <vector id="34"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 1 1 1 0 1 0 1 0 H X X 0 X L 1 </vector>
        <vector id="35"> G 1 L 1 X 1 L V L H L L L L L L L L L L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
      </ic>
    </manufacturer>
  </database>
</infoic>

Pin 1 is GND so it's always G whereas pin 40 is /RES so it is held 0 for 13 ticks before being held 1 for the remainder.

L means test that the expected output from the IC is a low voltage. H tests that the expected output is high. 0 supplies a low voltage of ~0V. 1 supplies a high voltage. ~3.3V in this example. X means don't care. G is a ground pin and V is a VCC pin (again 3.3V in this example).

...and a 6502 pin-out for easier reference.

[Alnitak]

This is very cool!

I shall have to try this out tomorrow under macOS, which is where I usually run the minipro open source programmer, built using MacPorts.

MacPorts is currently on 0.7.2, but the recently released 0.7.4 has much improved support for the later T56 programmer so I'll build that manually and submit a patch to get the MacPorts build up to date.

I'll also attempt to build the XML convertor under macOS too!

Ray

[Alnitak]

I've been playing with minipro 0.7.4 under macOS, and here are my findings so far:

- the .xml file above needs to use a <logicic> rather than <infoic> outer block
- minipro refuses to parse the file if the chip's voltage isn't listed as 5V
- Pin 21 is not supported for GND on TL866A/CS

With a W65C02S in my T56 programmer, and the xml file below, the test runs, but fails at step 14 after ~RESET is deasserted. I presume the cycle steps need some adjustment, and maybe BE needs to be held high.

Code: Select all

<logicic>
  <database type="LOGIC">
    <manufacturer name="Logic Ic">
      <ic name="R6502" pins="40" voltage="5V" type="5">
        <vector id="00"> G 1 X 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X X 0 </vector>
        <vector id="01"> G 1 X 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X X 0 </vector>
        <vector id="02"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="03"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="04"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="05"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="06"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="07"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="08"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="09"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="10"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="11"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="12"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 0 X L 0 </vector>
        <vector id="13"> G 1 L 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X X X X 1 X H 0 </vector>
        <vector id="14"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 0 X L 1 </vector>
        <vector id="15"> G 1 L 1 X 1 H V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 1 X H 1 </vector>
        <vector id="16"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 0 X L 1 </vector>
        <vector id="17"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 1 X H 1 </vector>
        <vector id="18"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 0 X L 1 </vector>
        <vector id="19"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 1 X H 1 </vector>
        <vector id="20"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 0 X L 1 </vector>
        <vector id="21"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 1 X H 1 </vector>
        <vector id="22"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 0 X L 1 </vector>
        <vector id="23"> G 1 L 1 X 1 L V X X X X X X X X X X X X G X X X X X X X X X X X X L X X 1 X H 1 </vector>
        <vector id="24"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X X X X X X X X X H X X 0 X L 1 </vector>
        <vector id="25"> G 1 L 1 X 1 L V L L H H H H H H H H H H G H H H H 0 0 0 0 0 0 0 0 H X X 1 X H 1 </vector>
        <vector id="26"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 0 0 0 0 0 0 0 0 H X X 0 X L 1 </vector>
        <vector id="27"> G 1 L 1 X 1 L V H L H H H H H H H H H H G H H H H 0 0 0 0 0 0 0 0 H X X 1 X H 1 </vector>
        <vector id="28"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 0 0 0 0 0 0 0 0 H X X 0 X L 1 </vector>
        <vector id="29"> G 1 L 1 X 1 H V L L L L L L L L L L L L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
        <vector id="30"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 1 1 1 0 1 0 1 0 H X X 0 X L 1 </vector>
        <vector id="31"> G 1 L 1 X 1 L V H L L L L L L L L L 0 L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
        <vector id="32"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 1 1 1 0 1 0 1 0 H X X 0 X L 1 </vector>
        <vector id="33"> G 1 L 1 X 1 H V H L L L L L L L L L L L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
        <vector id="34"> G 1 H 1 X 1 X V X X X X X X X X X X X X G X X X X 1 1 1 0 1 0 1 0 H X X 0 X L 1 </vector>
        <vector id="35"> G 1 L 1 X 1 L V L H L L L L L L L L L L G L L L L 1 1 1 0 1 0 1 0 H X X 1 X H 1 </vector>
      </ic>
    </manufacturer>
  </database>
</logicic>

[Alnitak]

This set of vectors is now working for my W65C02S. It seems to take a few more cycles than the R6502 before it reads the reset vector, and it never asserts write-enable.

EDIT: removed, because of the VPB held low issue - will repost once fixed.

[gfoot]

Nice work figuring out how to set this up in minipro, that's super useful.

The observations sound normal (e.g. the extra cycle, and the WDC 65C02 not executing the stack writes during the reset sequence).

One thing to be careful of is pin 1 - on the WDC 65C02 it is an output pin, not ground, so you should not drive it low. The processor will drive it low during the vector fetches of the reset and IRQ sequences, and high at other times. Perhaps this is why you're observing odd behaviour after the sequence ends.

Note also that pin 2 is sometimes an output - ideally you want to pull it high but not force it high. Alternatively if certain instructions (STP and WAI) are executed you need to dynamically switch it to being an input rather than an output.

Edit: You also shouldn't really expect any specific address outputs during the reset cycle - it's relatively random what they are in general. e.g. three of them will be stack reads or writes, but it depends on the internal state of the stack pointer.

[Alnitak]

gfoot wrote:

Nice work figuring out how to set this up in minipro, that's super useful.

The observations sound normal (e.g. the extra cycle, and the WDC 65C02 not executing the stack writes during the reset sequence).

One thing to be careful of is pin 1 - on the WDC 65C02 it is an output pin, not ground, so you should not drive it low. The processor will drive it low during the vector fetches of the reset and IRQ sequences, and high at other times. Perhaps this is why you're observing odd behaviour after the sequence ends.

Ah, yes, good point!

gfoot wrote:

Note also that pin 2 is sometimes an output - ideally you want to pull it high but not force it high. Alternatively if certain instructions (STP and WAI) are executed you need to dynamically switch it to being an input rather than an output.

Noted, but shouldn't be an issue without STP or WAI in the test sequence, I think?

gfoot wrote:

Edit: You also shouldn't really expect any specific address outputs during the reset cycle - it's relatively random what they are in general. e.g. three of them will be stack reads or writes, but it depends on the internal state of the stack pointer.

I had wondered about whether to hard code those address outputs, but since it seems the chip gets powered down each time, I think it's likely they'll remain consistent, at least for my chip. I do wonder if other W65C02S chips will always output those same reads.

cheers,

Ray

p.s. I've loved watching your videos over the last few years. I'm currently working on a clock stretch circuit that defaults to 8 MHz but maintains a pair of in-phase 1MHz and 2MHz clocks, for emulating BBC peripherals.

[gfoot]

Alnitak wrote:

Noted, but shouldn't be an issue without STP or WAI in the test sequence, I think?

Yes true, you can just not put those instructions in the test sequence.

Quote:

I had wondered about whether to hard code those address outputs, but since it seems the chip gets powered down each time, I think it's likely they'll remain consistent, at least for my chip. I do wonder if other W65C02S chips will always output those same reads.

It is possible that it is indeed well-defined for the WDC 65C02 - I think they did make some states be consistent after reset which were random in the NMOS design.

Quote:

p.s. I've loved watching your videos over the last few years. I'm currently working on a clock stretch circuit that defaults to 8 MHz but maintains a pair of in-phase 1MHz and 2MHz clocks, for emulating BBC peripherals.

I'm glad you liked them. I think you commented on one of my posts here regarding a clock-stretching circuit, while I was away - that one worked quite well. I had another approach in this design, where the CPU and I/O are just running on different clocks, and when the CPU wants to do I/O its clock gets stretched for as long as the I/O system needs it to be - I guess there are a lot of different ways to do this kind of thing!

[BigDumbDinosaur]

Alnitak wrote:

gfoot wrote:

Note also that pin 2 is sometimes an output - ideally you want to pull it high but not force it high. Alternatively if certain instructions (STP and WAI) are executed you need to dynamically switch it to being an input rather than an output.

Noted, but shouldn't be an issue without STP or WAI in the test sequence, I think?

True, but unless you are certain $CB won’t somehow be seen by the MPU as an opcode, the safe approach is to connect pin 2 (RDY) to VCC through a resistor—3.3K is a typical value.

[Alnitak]

BigDumbDinosaur wrote:

Alnitak wrote:

gfoot wrote:

Note also that pin 2 is sometimes an output - ideally you want to pull it high but not force it high. Alternatively if certain instructions (STP and WAI) are executed you need to dynamically switch it to being an input rather than an output.

Noted, but shouldn't be an issue without STP or WAI in the test sequence, I think?

True, but unless you are certain $CB won’t somehow be seen by the MPU as an opcode, the safe approach is to connect pin 2 (RDY) to VCC through a resistor—3.3K is a typical value.

I don't know that absence of $CB can be 100% guaranteed, but the voltage applied to each pin is part of the set of test vectors, and under controller of the programming test device.

Given that the test vectors use "V" to set a VCC pin, and use "1" to set a logic high, maybe those latter are just made to go high via pull-ups internally within the programmer?

If not, the only way to be sure would be to lift the RDY pin so that the programmer isn't controlling it.

Ray

[BigDumbDinosaur]

Alnitak wrote:

BigDumbDinosaur wrote:

Alnitak wrote:

gfoot wrote:

Note also that pin 2 is sometimes an output - ideally you want to pull it high but not force it high. Alternatively if certain instructions (STP and WAI) are executed you need to dynamically switch it to being an input rather than an output.

Noted, but shouldn't be an issue without STP or WAI in the test sequence, I think?

True, but unless you are certain $CB won’t somehow be seen by the MPU as an opcode, the safe approach is to connect pin 2 (RDY) to VCC through a resistor—3.3K is a typical value.

I don't know that absence of $CB can be 100% guaranteed, but the voltage applied to each pin is part of the set of test vectors, and under controller of the programming test device.

Given that the test vectors use "V" to set a VCC pin, and use "1" to set a logic high, maybe those latter are just made to go high via pull-ups internally within the programmer?

If not, the only way to be sure would be to lift the RDY pin so that the programmer isn't controlling it.

Given the small but critical pin differences between the “historical” 65C02 (which was intended as a drop-in replacement for the NMOS part) and the “modern” (WDC) incarnation (which cannot be considered a drop-in replacement), it would seem logical to devise a small adapter board into which the MPU is plugged, rather than directly connecting the MPU to the test rig.  The adapter board would have some jumpers that are to be set according to which MPU is being tested.

If it is a WDC 65C02, then pin 1 (VPB, which is ground on historical 65C02s and NMOS parts) needs to be isolated, pin 2 (RDY) needs to be isolated and pulled up to VCC through a resistor, pin 5 (MLB, which is a no-connect on some historical 65C02s and the NMOS part) must be isolated, and pin 36 (BE, which is a no-connect on the 6502 and some historical 65C02s), needs to be pulled up to VCC, also through a resistor.