Debugging my first SBC

[BigDumbDinosaur]

Dr Jefyll wrote:

• issue a half-dozen clocks
• press and hold the Reset button (which should force low the CPU /RESET on pin 40)
• issue a few more clocks -- at least two
• release the Reset button
• issue two more clocks
• stepping onward, and monitoring the RAM /CS input, you should see a dummy stack access lasting three cycles
• stepping onward, and monitoring the ROM /CS input, you should see the vector fetch lasting two cycles (for the low byte then high byte)

The cycle following the fetch of the vector high-byte should be the start of your program. On the data bus you should see the opcode of the first instruction of the program. If this isn't present then you need to find out why -- there's no use going any further.

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.

[Dr Jefyll]

Dr Jefyll wrote:

• release the Reset button

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.

BigDumbDinosaur wrote:

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.

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.

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

if your 65C02 is a WDC part you can monitor the vector pull output...return high during Ø2 low...

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...

[Dr Jefyll]

BigDumbDinosaur wrote:

That should have said "...briefly return high during Ø2 low..."

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.

[sepseel]

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 ?

[BigDumbDinosaur]

sepseel wrote:

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.

At what frequency are you clocking your system?

Quote:

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

It may be. Which single-stepping method are you using: stepping the clock itself or using RDY?

Quote:

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

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.

[sepseel]

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 ?

Quote:

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.

Haha, that might be easier.. but i had those components lying around, so..

[GARTHWILSON]

sepseel wrote:

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.

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.)

[Dr Jefyll]

sepseel wrote:

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 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... )

[BigDumbDinosaur]

sepseel wrote:

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.

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!

Quote:

As for the single-stepping method, I just step the clock. Would using RDY be better or easier ?

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.

[BigEd]

sepseel wrote:

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

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.

[Dr Jefyll]

sepseel wrote:

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 ?

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.

[sepseel]

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 ?

[Dr Jefyll]

Dr Jefyll wrote:

Restart the 6502 and quickly step through until the UART chip-select goes active (which, depending on the software, will probably take a few dozen cycles). Now, with the 6502 still paused, you can verify that the address and data buses contain the expected data. I haven't looked at the program you're using, but I assume the first access to the UART will be a write cycle.

Even this simple first test reveals a lot! And it'll suggest what direction further tests should take.

[sepseel]

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