I've been working on a little project running a W65C816 with a microcontroller for a few weeks with no problems. I am using some IO expander chips to drive the address and data buses and I suspect they may have driven the data bus for a few seconds while the 6502 was also driving it. Now when I reset it, it always makes the highest bit at FFFC a 1. For example, if FFFC is 0x00 and FFFD is 0x40 then it will jump to 0x4080 instead of 0x4000. It does this for all values I have tried. I hooked up a logic analyzer to be totally sure that 0x00 really was on the data bus and that 0x80 really was coming out of the address bus. Does any of this sound familiar or have I just fried the chip somehow?

Looks to me like A7 is tied high. If you can disconnect A7 at the 6502 you should be able to tell wether it is the 6502 itself or if it is outside of the chip. You shoud be able to force the external part of the A7 signal path low with a 3.3k pull down resistor.

edit: Jeff was a bit faster suggesting a NOP generator like this: http://6502.org/mini-projects/nop-gen/nop-gen.htm

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I agree that A7 seems to be stuck high -- IOW it's not a data bus problem. The "stuckness" could be inside the CPU where A7 originates or it could be in the devices connected to A7 externally (including memory and the IO expander for the microcontroller). Separating them (as Klaus suggested) is a good test. Another useful test is to connect a NOP generator -- something that unconditionally forces $EA (NOP) or some other simple instruction on the data bus. In that case you should see all the address lines toggling.

cheers
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Using NOPs is a good idea. I think I will have to do some soldering to get that working.

I don't think A7 is tied high. Only the high bit of the byte at FFFC becomes one. The byte at FFFD is unaffected. Like in my example, 0x00, 0x40 at FFFC tries to fetch 0x4080, not 0xC080.

Have you checked the memory chip (EPROM, presumably), or the chip select logic?

Maybe you could remove the processor and drive the address and control lines directly, and see if the data lines show the information you expect?

Easy mistake - I made it too - but I think it is a mistake. It's A7, the address pin or track, which may be stuck high. Not D7, the data pin or track, which as you say is transporting bytes like 0x00 successfully.

Cheers
Ed

Ok, you were right. It was A7 that was stuck high. All the joints on the board looked fine and it worked for a week without problems. I cleaned the flux between A7 on the IO chip which was next to Vcc and the problem disappeared. Maybe as the flux slowly dries out it becomes more conductive?

What kind of flux? The rosin flux that comes in the rosin-core solder is not conductive at all-- ever. Water-soluble fluxes are terrible though. There might have been a tiny whisker of solder shorting things, and you cleared it out.

_________________
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?

As Garth said, rosin flux is completely non-conductive. I've seen dried flux in between high voltage connections in electron tube equipment and never once has any problem arisen because of it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

http://www.mouser.com/Search/ProductDet ... y738-13541

Maybe it was a tiny whisker of solder. I'm still stumped as to how it worked fine for so many hours of use and then did this all of a sudden. Oh well.

It only takes a fraction of a millimeter of solder splash to cause trouble.

BTW, I notice that the link to the data sheet for the solder you reference is dead. I wanted to read about what AIM calls a "mildly activated" flux.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Maybe the problem was very temporary. Try again, because I had no trouble viewing it yesterday or just now.

_________________
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?

It's a bad link at Mouser's site. I was able to read up on the product at AIM's site through a roundabout path. Nothing in the description suggests that the dried flux will pose a problem with inadvertent conductivity.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!