There is no trick - pull BE low and the 6502 address and data buses are tristated. Do make sure it's either in Reset mode (Reset pulled low) or !Rdy (ie. Rdy pulled Low) or it will free-run with unpredictable results. If that didn't work in my board then it just wouldn't work at all.

Do you have a real W65C02S in there?

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Still unable to get address bus to tri-state even by driving RESET, BE and RDY all low right after power is applied.

It is a good question whether I have a real/working W65C02S8P-10 or not. I bought a lot of 5pcs off eBay from some random seller in China. I have been lucky for the last couple years, but it is possible my luck have run out. Power it up with whatever random data in RAM it seems to execute something: SYNC is toggling, some addresses are changing, and RWB line toggling. I suppose I can jam NOP instruction into the data bus and see whether the address will count up to FFFF and roll over and over.

For now, I'm current limiting the address lines with 240 ohm series resistors and see if I can continue testing.
Bill

You can (and should) buy them brand-new from Mouser. They are in-production, so no need to go to China for them whatsoever.

See close-up of: https://unicorn.drogon.net/IMG_20181115_164041.jpg for the chip markings on one I got from them.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Yep, there's quite a large counterfeiting industry going on there with pulling ICs out of boards, cleaning them up, and re-labeling them before sale. I've seen quite a few short videos documenting that, like this one: https://www.youtube.com/watch?v=5vN_7NJ4qYA

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Let see if I can load decent photos to the forum:

This is the baseline G8PP board I started from yesterday.

This is the G8PP+6502 as of a couple hours ago. The series resistors on address lines are not yet added in the photo. Clock is 7.37MHz. Signals look reasonably clean on the scope. I think I'm loading serial data into RAM and observing it bootstrapping after 255 bytes, but it is not executing correctly. There are many moving pieces to this puzzle, one of them is that I don't know much about 6502 assembly instructions. Climbing a steep hill but having fun!
Bill

The logo on the chip doesn't look right - starting to think you may have a dud...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Where are you based plasmo? I have some 65C02 spares (bought from WDC and official WDC resellers)

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I live in Albuquerque, New Mexico, USA. Are you in UK? I'm probably better off with Mouser as drogon had suggested. Thank you for your kind offer.

I did hook up a logic analyzer and verify the serial bootstrap stage when 6502 is tri-stated and 255 serial data are written into RAM. Afterward 6502 did not behaved as I expected. I never worked with 6502 so I'm not sure what I should see. Can someone describes the first dozen transactions after reset? I expect 6502 to put out address 0xFFFC and 0xFFFD, wait a few clocks and then start fetch instruction from 0xFF00 (the reset vector supplied). What should I see on VPB, MLB, SYNC, and RWB?

I did replaced the first 6502, but the 2nd one appears to be the same. I think this morning I'll set up a free-running experiment on a solderless breadboard--just tie data bus to 0xEA and let it run--and see what happens.
Bill

I wonder if you've actually got an old NMOS 6502 rather than the 65C02, or even a non WDC 65C02 which didn't have the BE signal.... The NOP test should let you know if it's a generic 6502 at least. the BE line (pin 36) is NoConnect on the older ones.

It's also probably too late to get one delivered in any small time-scale now though, but plenty of time to try a few things out in an emulator, or something to get a feel for 6502 assembler.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Hmmm, that's a possibility, which means 7.37MHz is probably too fast. I can use a 1.8432MHz clock instead. I did do a free-running experiment on the existing board by reprogramming the CPLD. I do see addresses counting up, but for every address counting up there are burst of 4 accesses with dead time between them I don't expect and SYNC toggle twice per burst--feel like it is walking up an exception handling of some sort.

I'll do the solderless breadboard with slow clock where I can isolate everything from the CPU...
Bill

Internally, the 6502 treats coming out of Reset the same as an interrupt, except that the writes of the return address and status register to the stack are suppressed (converted into dummy reads). You can therefore read the cycle timing from that of BRK, the software-triggered interrupt.

Reading the vector occupies the *last* two cycles before instruction fetching begins. The total number of complete cycles between /RST going high and the first opcode fetch should be 7. Effectively there are 5 "dead cycles" immediately after Reset, followed by the vector pull (2 read cycles), and the first instruction fetch follows immediately.

/IRQ and /NMI should both be held high, and you should ensure you are providing NOP opcodes ($EA) instead of BRK ($00). That should ensure you have no "exceptions" occurring. The 6502 has no internally triggered exception conditions.

Free running at 1.84MHz works, but not at 7.37MHz. It also free-runs at 3.84MHz, so I return to my prototype board and replace the 7.37MHz oscillator with 3.68MHz and it works! The BE still does not tri-state the address bus, so it is likely a NMOS 6502 (4MHz?) repackaged as W65C02S8P-10. If so, OK, I can live with that. It will let me continue with code development on the prototype hardware.
Bill

They cycle-by-cycle activity is detailed in table 5-7 starting on p.38 of the 65816 data sheet (which covers this info for the '02 as well), at http://6502.org/documents/datasheets/wd ... 1_2018.pdf .


It could also be a CMOS one from another manufacturer like GTE (later CMD), Rockwell, or Synertek, which never put the extra signals on. Test the CMOS instructions and see what you get. The CMOS has a lot of other improvements too, like much, much stronger pin drivers. See http://wilsonminesco.com/NMOS-CMOSdif/ .

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Not sure the NMOS ones went over 1Mhz, but some of the early CMOS ones could do 4Mhz - I have one marked R65C02P4 (It's a Rockwell one)

However, good to know you have a 6502 at least - just not a genuine WDC 65C02S.

How to solve the bus contention though - If it is a Rockwell 65C02, then it may always be driving the address bus. Link to the Rockwell data sheet from here: http://archive.6502.org/datasheets/rock ... essors.pdf

Good luck!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/