Having problem getting W65C02S to work Paired with ATMEGA644

[MatCat]

So I paired a W65C02S with an ATMEGA644A to do some testing, below I have the output from serial as well as the source code running to interact with the 6502, howver as you can see from the output its not quite working right. It properly follows the FFFC vector, and appears to read the first opcode A9, but seems to fail after that, the next OPCODE it tries to fetch should be 0x85, but its not, it seems to be getting the PC off by 1. Also sometimes RWB doesn't go high, it will just get stuck in a low value.

Quote:

OUTPUT
-------------
Initializing...

OPCODE: 0 RW: 1 Address: 0x4a2 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x4a2 DATA: 0x00
OPCODE: 1 RW: 1 Address: 0x4a2 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x4a2 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x100 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x1ff DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x1fe DATA: 0x00
OPCODE: 0 RW: 1 Address: 0xfffc DATA: 0x00
OPCODE: 0 RW: 1 Address: 0xfffd DATA: 0x04
OPCODE: 1 RW: 1 Address: 0x400 DATA: 0xa9
OPCODE: 0 RW: 1 Address: 0x401 DATA: 0x55
OPCODE: 0 RW: 1 Address: 0x402 DATA: 0x85
OPCODE: 0 RW: 1 Address: 0x7df8 DATA: 0x7d
OPCODE: 1 RW: 1 Address: 0x403 DATA: 0x01
OPCODE: 0 RW: 1 Address: 0x404 DATA: 0xa6
OPCODE: 0 RW: 1 Address: 0xa7 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0xa7 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0xa8 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0xa7a7 DATA: 0xa7
OPCODE: 1 RW: 1 Address: 0x405 DATA: 0x01
OPCODE: 0 RW: 1 Address: 0x406 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x01 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x01 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x02 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x101 DATA: 0x00
OPCODE: 1 RW: 1 Address: 0x407 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x408 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x01 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x01 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x02 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x101 DATA: 0x00
OPCODE: 1 RW: 1 Address: 0x409 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x40a DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x01 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x01 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x02 DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x101 DATA: 0x00
OPCODE: 1 RW: 1 Address: 0x40b DATA: 0x00
OPCODE: 0 RW: 1 Address: 0x40c DATA: 0x00
-------------------------------------------------------
CODE
-------------------------------------------------------
#include <Arduino.h>
uint8_t RAMARRAY[2048];
unsigned char reverse(unsigned char b) {
b = (b & 0xF0) >> 4 | (b & 0x0F) << 4;
b = (b & 0xCC) >> 2 | (b & 0x33) << 2;
b = (b & 0xAA) >> 1 | (b & 0x55) << 1;
return b;
}

void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
Serial.println("Initializing...\n");
pinMode(12,OUTPUT);
pinMode(11,INPUT);
pinMode(10,OUTPUT);
pinMode(15,INPUT);
digitalWrite(10,LOW);
digitalWrite(12,LOW);
DDRA = 0x00;
DDRB = 0x00;
DDRC = 0x00;
delay(10);
digitalWrite(12,LOW);
delay(10);
digitalWrite(12,HIGH);
delay(10);
digitalWrite(12,LOW);
delay(10);
digitalWrite(12,HIGH);
delay(10);
digitalWrite(12,LOW);
delay(10);
digitalWrite(10,HIGH);
delay(10);
RAMARRAY[0x400]=0xA9;
RAMARRAY[0x401]=0x55;
RAMARRAY[0x402]=0x85;
RAMARRAY[0x403]=0x01;
RAMARRAY[0x404]=0xA6;
RAMARRAY[0x405]=0x01;
RAMARRAY[0x406]=0x00;
}

void loop() {
// put your main code here, to run repeatedly:
//Serial.println("Clock HIGH\n");
digitalWrite(12,HIGH);
delayMicroseconds(30);
uint16_t addr = 0;
uint8_t data = 0;
bool rw=false;
bool SYNC=false;
SYNC = digitalRead(15);
rw = digitalRead(11);
addr = reverse(PINC);
addr |= reverse(PINB)<<8;
data = PINA;

if (rw==true) {
// CPU is reading
DDRA = 0xFF;
if (addr < 2048) {
data=RAMARRAY[addr];
}
if (addr == 0xFFFC) data=0x00;
if (addr == 0xFFFD) data=0x04;
PINA = data;
//Serial.printf("Sending: 0x%02x\n",data);
} else {
// CPU is writing
if (addr < 2048) RAMARRAY[addr] = data;
}


Serial.printf("OPCODE: %d\tRW: %d\tAddress: 0x%02x\tDATA: 0x%02x\n",SYNC,rw,addr,data);
//Serial.println("Clock LOW\n");
delay(1);
digitalWrite(12,LOW);
delayMicroseconds(30);
DDRA = 0x00;
delay(1);
}
-------------------------------------------------------------
HARDWARE
-------------------------------------------------------------
PORTB is HIGH byte of ADDRESS, connected in reverse bit order
PORTC is LOW byte of ADDRESS, connected in reverse bit order
PORTA is DATA, connected in proper bit order

PIN 12 is clock
PIN 10 is RESET
PIN 11 is RWB
PIN 15 SYNC

RDY, BE, IRQ, NMI, and RESET are all pulled up with 3.3k resistors

[Chromatix]

It looks like you're driving the data bus with the appropriate data only just before driving the clock low, but after a delay since driving the clock high. Depending on how fast your ATmega is, that might not be soon enough for the 6502 to reliably receive the data before it registers what happens to be on the bus at the falling clock transition.

In short:

Code: Select all

write(Phi2, 1);
delay();
ReadAddr();
if(RWB)
  WriteData();
else
  ReadData();
write(Phi2, 0);
delay();

…is wrong, from a timing perspective. Better would be:

Code: Select all

write(Phi2, 0);  // Phi1 phase; CPU works out address signals
delay();
write(Phi2, 1);  // Phi2 phase; address signals are stable, data bus becomes active
ReadAddr();
if(RWB)
  WriteData();  // Give CPU data ASAP so that it's stable by end of Phi2
delay();
if(!RWB)
  ReadData();  // CPU written data is now stable and can be read

[MatCat]

arranged my loop as specified above but no dice, same output, also I am starting to really wonder why RWB isn't working, sometimes goes high and stays high, often times it just stays low, I have measured with scope and multimeter the 6502 is just not driving RWB high and I have no idea why.

[Chromatix]

I would try inserting more cycles with the Reset line held low. As many as a dozen should make sure.

[MatCat]

Yes, I have it doing 100 cycles now during reset, doesn't make a difference.

[Chromatix]

I would double-check that you're actually treating the correct pin as RWB. Failing that, you may have a faulty part, which you can check by wiring up a basic NOP generator and manually toggling the clock.

[Dr Jefyll]

Quote:

OPCODE: 1 RW: 1 Address: 0x400 DATA: 0xa9
OPCODE: 0 RW: 1 Address: 0x401 DATA: 0x55
OPCODE: 0 RW: 1 Address: 0x402 DATA: 0x85
OPCODE: 0 RW: 1 Address: 0x7df8 DATA: 0x7d
OPCODE: 1 RW: 1 Address: 0x403 DATA: 0x01

Quote:

It [...] appears to read the first opcode A9, but seems to fail after that, the next OPCODE it tries to fetch should be 0x85, but its not

A9 is an instruction that should take 2 cycles. But, looking at SYNC (listed here as OPCODE) it seems to take 4 cycles. (Ie, 4 cycles elapse before SYNC goes high again.) During this time it steps over the 85. Perhaps a wiring error has distorted the A9 so it's no longer A9 by the time it reaches the 65C02.

-- Jeff

[MatCat]

I have already done EA nop gen test, it will cycle all the way around the full address space, so the address is certainly communicating properly, which also makes me think data is as well if it can read EA's. I am at this point thinking all 3 of these are either fake or bad from the seller I got them from (all 3 chips I got act exactly the same).

I am 100% confident everything is wired 100% correctly.

[GARTHWILSON]

MatCat wrote:

I am at this point thinking all 3 of these are either fake or bad from the seller I got them from (all 3 chips I got act exactly the same).

Where did you get them? I have bought many hundreds of ICs for my personal use and for prototyping for work, and have been responsible for the purchase of possibly millions of ICs for work, and I don't think we've ever gotten a bad one. Manufacturers are quite good about testing. However, hobbyists, who don't get the benefit of large-quantity discounts, are constantly looking for a deal on eBay, and unwittingly often buy counterfeits from China. Our sticky topic "65xx parts sources" should help find the real McCoys. I try to keep the head post updated. Several legitimate WDC suppliers are listed there.

Another thing of course is handling precautions for preventing ESD (electrostatic discharge) damage, and I think most of us on this forum have very little idea how careful any of the others are about this. You don't need special equipment to keep parts safe if you are constantly careful about making sure contact is always made first to the ground or power and not sensitive inputs where a static discharge could blow something. Most CMOS ICs do have input protection diodes to protect against mild discharges, but they're super tiny, to hold the input capacitance down, and they have their limits.

[BigEd]

MatCat wrote:

I am 100% confident everything is wired 100% correctly.

And you might be right! But I recommend trying to keep a list of all your observations, and all your hypothesis, and proceed by testing hypotheses.

When you say the wiring is right, have you checked that all address lines and all data lines go everywhere they should, and nowhere they shouldn't? In general, a permutation or short on your data bus or your address bus might allow you to pass a NOP test but still have some debugging to do.

It might be interesting to try a few different values to the two bytes after the A9 - it might illuminate what opcode is executing, by modifying the address used to read data in the fourth cycle.

[Dr Jefyll]

BigEd wrote:

a permutation or short on your data bus or your address bus might allow you to pass a NOP test but still have some debugging to do.

Right. $EA is not the only value that will perform successfully in the NOP test; there are about two dozen others. IOW, this test doesn't prove that EA is what the CPU was seeing.

Despite the wiring appearing to be correct, I think you need to drill down further and verify the wiring actually works. For example, recently someone here had a project which was failing because their solderless breadboard was defective -- and that's just one of several possible scenarios.

We have a red-hot clue, and it's that, following an A9 opcode, SYNC take too long to return high. A defective CPU is one possibility, but not the only possibility.

Are you able to run only the first portion of your test, and halt while the A9 opcode is presented? Then you could measure right at the pins of the CPU and verify that the right voltages appear on the right pins. I suspect A9 is not what the CPU is seeing.