6502.org

Further to Jeff's instructions, if your 65C02 is a WDC part you can monitor the vector pull output (VPB, pin 1 on the PDIP package or pin 2 on the PLCC44 package) for when the 'C02 fetches the reset vector. VPB will go low when the least significant byte is fetched, which occurs during Ø2 high, return high during Ø2 low and then go low when fetching the most significant byte, again during Ø2 high.

A minor note: the reset sequence begins when the Reset button is released. Prior to the circuit modification it would begin an instant after the button was pressed.
Well worth noting, yes -- VPB is another useful point of reference. Another minor note, though (and this doesn't impede our troubleshooting): the part about "return high during Ø2 low" is incorrect, as VPB isn't affected by Ø2. In all cases VPB becomes valid during the first half of the cycle -- the Ø2-low period -- and remains unchanged when Ø2 subsequently rises.

That should have said "...briefly return high during Ø2 low...", which VPB does do. I observed this behavior on POC V2 while single-stepping the clock when I thought I had glue logic problems and the '816 didn't seem to be fetching a valid reset vector. The logic probe pulsed as I stepped from reading the vector LSB while Ø2 was high (VPB being low at the time) to the next Ø2 low state, which would precede the fetching of the MSB. The 65C816 timing diagram also indicates VPB is temporarily in a state of flux at that time, starting at tAH and ending at tADS.

As you noted, the very brief change of VPB would be of no consequence for troubleshooting purposes.

Unfortunately, my vision problems occasionally cause me to not notice E&O in my writings. More unfortunately, it's getting worse...

OK, I can go along with that. The datasheet allows that, for a brief period (the period tAH) immediately after Ø2 goes low, VPB may be invalid. Which includes two possible cases: low when the valid state is high, or, as you say, high when the valid state is low.

Ok, so I ran the test you suggested.
When I first did the test, it did not look like I was getting the right data, or even adresses.
Instead of fetching the high and low byte from FFFC and FFFD, the processor was looking at FFFE and FFFF.

But then I removed the ACIA (I am using the R6551AP) and everything worked just fine.
The processor was accesing the right adresses, and I was seeing the correct data on these adresses.

Could this be because my single stepping method is causing trouble for the ACIA ?

Oh, and I'm using a different reset circuit, the one I'm using is found here:
http://www.grappendorf.net/projects/650 ... rcuit.html


PS, I was thinking I should maybe make a new post, because the title does'nt really reflect the contents that well anymore
What do you guys think ?

At what frequency are you clocking your system?
It may be. Which single-stepping method are you using: stepping the clock itself or using RDY?
That's essentially the reset circuit found in the Commodore eight bit computers. It should be okay, although it's using a lot of hardware to do what a Maxim DS1813 does in a TO92 package with no other components. Sometimes going retro can be overdone.

So normally my clock runs at 1 MHz, and I have a 1,8432 MHz crystal for the acia.
I suspect however that the acia crystal is not operating as it should, this may also be the cause for my problems I think.

As for the single-stepping method, I just step the clock. Would using RDY be better or easier ?
Haha, that might be easier.. but i had those components lying around, so..

If you're just hanging the crystal on the ACIA, be sure to use a capacitor on the input pin as shown a little below the middle of the I/O ICs page of the 6502 primer, at http://wilsonminesco.com/6502primer/IO_ICs.html . (I know, I know, I need to improve that whole page.)

The likely explanation is that address line A1 is somehow connecting to Vcc, forcing A1 to a logic high. That could be the result of a shorted A1 input on the ACIA chip. (Inputs can short high or short low. It's uncommon for a chip to fail, but when it does these are among the symptoms you might expect. Outputs, too, can get stuck high or low.)

As I hope you know, address line A1 is what differentiates FFFC from FFFE --- and FFFD from FFFF. If A1 is stuck high then the CPU is incapable of expressing any addresses where A1 is supposed to be low. There are thousands of such addresses, and FFFC and FFFD are among them.

One thing you could try is reinstalling the ACIA then rebooting, halting during the vector fetch. Then verify the voltage on the CPU's A1 pin. Also see if there's a change on that pin if you connect and disconnect the wire that brings A1 to the ACIA. (There shouldn't be, but... )

Given the ubiquity and low cost of present-day can oscillators, you may ultimately prefer to use one for your X1 clock instead of the crystal and associated components. Can oscillators are very trustworthy, produce plenty of drive, and take up little space. Also, all the issues associated with getting a crystal to resonate in the right way under all reasonable operating conditions have been worked out for you. The last time I used a crystal with a UART was in 1989, when I hacked together my version of CMD's SwiftLink for one of my Commodore 128D machines, using a 6551. Around that time, can oscillators started to come down in price and power consumption, and I never looked back. My POC units have two such devices, one for generating the Ø2 clock and the other for generating the UART clock (3.6864 MHz with NXP UARTs). Plug 'em in and they work!
I'm not an expert on the 6551 hardware, but if the one you are using is an NMOS part I suspect it doesn't react well to have Ø2 stopped. The 65C02, on the other hand, can tolerate having Ø2 stopped when high, and the WDC 65C02 is fine with stopping Ø2 on either phase. Garth or a few others (Dr. Jefyll?) might be able to opine on this.

You can retitle the whole thread by editing the subject line of the first post - that's probably the right thing to do. Pick a title which describes the whole adventure - "Debugging my first SBC build" might do it.

The RDY method is more complicated, so I wouldn't recommend it unless you insist on using the NMOS 6502 -- which there's no reason to do, since you have the much superior 65C02 available.

I hope you won't mind if I remind you your first goal should be ensuring the Reset vector gets fetched properly. Problems, if any, with the ACIA's 1,8432 MHz crystal won't affect vector fetching, so the crystal isn't something you should allow to distract you. Better to look into what the A1 signal is doing, as explained in my last post.

After the vector is getting fetched properly then you'll be able single-step (or go full speed!) into the actual program. But right now the race is stalled at the starting line.

Update:
I have replaced the 1,8432 crystal with an oscillator module, so that works now...

I also managed to find an error in the adress decoding logic going to the 6551, which I have now fixed, so it is'nt being accesed at the same time as the rom anymore.

Fixing this mistake made it so now every time after a reset the vector is getting fetched correctly, and as far as I can tell, the code executes as expected.

However, when I run the clock att full speed I would expect to get some kind of output out of the serial port right ?
well I dont get any..
I have an adafruit FTDI friend to communicate with my computer, this has lights connected to tx and rx, but these dont light up when connected to the 6551.
Also for a serial monitor I use the one included with the arduino IDE, this should work, right ?

Is it possible I broke my 6551 ?
what tests can I do to debug this issue ?

Oops, sorry for missing that.

So the first time the acia is selected, is on adress $8801, the data lines then read: $00
A couple cycles later it is accesed again, this time on $8802, and on the data lines: $0B
Then a few cycles later it is accesed again, this time on $8803, giving me $1E on the data lines.

According to my memory map the starting adress of the acia is $8800