65c02 SBC woes

[Dr Jefyll]

Mercury1964 wrote:

I don't have an oscilloscope or a logic analyzer, so the only checks I can make are from a multimeter probing individual pins.

All the more reason to adopt BDD's suggestion of connecting a NOP generator. One key advantage is that it'll cause the address bus to continually increment once per cycle. That means the least-significant address line, A0, will take 2 cycles to go high then low again.

A1 will take 4 clocks to to go high then low again, A2 will take 8 clocks, A3 will take 32 and so on. The upshot is, the most-significant address lines will toggle at frequency low enough to be easily discernible with a multimeter. (Even so, a logic probe would be a useful addition to your shop. )

cheers,
Jeff

[Mercury1964]

I'm using ACME version 0.91.

[GARTHWILSON]

Dr Jefyll wrote:

Mercury1964 wrote:

I don't have an oscilloscope or a logic analyzer, so the only checks I can make are from a multimeter probing individual pins.

All the more reason to adopt BDD's suggestion of connecting a NOP generator. One key advantage is that it'll cause the address bus to continually increment once per cycle. That means the least-significant address line, A0, will take 2 cycles to go high then low again.

NOP is two cycles per byte, not one, so four for A0 to go high and then low again. I think A9 (the op code of LDA#) is slightly better as it truly is one cycle per byte.

[Mercury1964]

Alright, I just built the NOP generator and tried it out. Everything seemed to be working. I used a buzzer to measure the frequencies of certain pins as suggested on Lee Davidson's NOP generator page and I heard what he described - the frequency of the sound got higher as I went down from A15, and PHI0, PHI2, and SYNC are all ticking at what sounds like similar frequencies. I couldn't find any shorts on the board. I'm gonna try running it with only the CPU and LOADROM next, and see if that does anything.

[Dr Jefyll]

GARTHWILSON wrote:

NOP is two cycles per byte, not one, so four for A0 to go high and then low again.

Oops, thanks -- my bad; a momentary mental lapse.

GARTHWILSON wrote:

I think A9 (the op code of LDA#) is slightly better as it truly is one cycle per byte.

Yes, any of the immediate opcodes will fetch from memory at a rate of one byte per cycle. So 09, 29, 49, 69, 89, A9, C9, E9, C0, E0, A0 and A2 are all equally good candidates.

[Mercury1964]

So I just tried reinstalling each chip one at a time. Everything worked (chip select lines, address bus, etc. matches what was expected) until I installed the VIA. Running it with just the glue logic, CPU, RAM, and both ROMs works. When the VIA is installed, everything stops working. Since the test program relies on the VIA being installed, I can't confirm that it is working 100%, but it seems to be executing from the LOADROM and not jumping around randomly like it was before.

Might this be the sign of a defective VIA, or some sort of problem with the glue logic?

[GARTHWILSON]

Is pin 4 of the '138 just left floating?

It is almost an impossibility that an IC was bad when you bought it new. I have been responsible for millions of ICs in our products over the years, and I can count the bad ones on the fingers of one hand-- almost on the fingers of one knee.

[Mercury1964]

GARTHWILSON wrote:

Is pin 4 of the '138 just left floating?

I left pin 4 of the '138 floating. Is that bad?

[GARTHWILSON]

Yeah, don't leave inputs floating, especially CMOS ones. Unconnected 74LS inputs naturally go high, but I don't really recommend LS for this stuff. Since CMOS takes no input current to speak of (maybe femtoamps or attoamps of leakage), their voltage may go up and down wildly from minor capacitive coupling to nearby circuits, and much of the movement may be in no-man's land between valid logic states.

[BigDumbDinosaur]

Mercury1964 wrote:

I don't have an oscilloscope or a logic analyzer, so the only checks I can make are from a multimeter probing individual pins.

I didn't see this earlier for some reason.

You don't need a logic analyzer, only a logic probe, which is a relatively inexpensive device. Having a 'scope is nice as well, but not essential. I did the hardware debugging on my POC unit using only a logic probe. The particular probe I have is a BK Precision DP-21, which is reliable up to 20 MHz and can differentiate between TTL and CMOS logic levels.

A multimeter isn't really fast enough to see the rapid state changes that occur in a computer circuit. However, as Jeff noted, you usually can get some indication as to whether the voltage being sampled is steady or fluctuating if the rate isn't too high.

[BigDumbDinosaur]

Mercury1964 wrote:

So I just tried reinstalling each chip one at a time. Everything worked (chip select lines, address bus, etc. matches what was expected) until I installed the VIA. Running it with just the glue logic, CPU, RAM, and both ROMs works. When the VIA is installed, everything stops working. Since the test program relies on the VIA being installed, I can't confirm that it is working 100%, but it seems to be executing from the LOADROM and not jumping around randomly like it was before.

Might this be the sign of a defective VIA, or some sort of problem with the glue logic?

Chip defects these days are extremely rare. I haven't encountered a defect in a new chip in the last 25 years and like Garth, I've handled a lot of them. That doesn't rule out accidental damage while you were handling them, but I presume you are taking the usual precautions to avoid ESD.

At this point, it sounds to me as though you have a logic defect in your design. You need to:

1. Verify your glue logic equations to make sure that device selection is occurring as expected.
2. Verify that at no time two or more devices are simultaneously selected.
3. Verify that the VIA's chip selects are valid before the rise of Ø2. Also, the VIA's R/W input must exactly follow the MPU's RWB output.
4. Verify that the control inputs to your SRAM are behaving as expected.

[floobydust]

Agreed that defective chips are rare, albeit I've had an Alliance 32KBx8 static RAM develop a flaky page $03 (address space) some time ago. Got bit by it (pun intended) when I did my C02Bios which stores interrupt and monitor vectors along with I/O soft config data there. One of the boards wouldn't boot up... turned out to be the RAM, swapped it out and all was fine.

Looking back at the OP's schematic, he's using the 74HC138 chip select output to drive negative chip selects for both the 65C22 and the RAM chip, which is normal. He's also using the same 74HC138 chip select outputs via a 74HC10 gate section with all inputs tied together to form an inverter to drive the positive chip selects on the 6522 and RAM chips. Basically, it's a wasted pair of gates and adds some unnecessary delay in the memory and I/O selects. It would be advisable to simply tie those selects to +5V and free up a couple gates.

Also, it appears that he's not selecting the 74HC138 properly. Looking at the datasheets for the 138 and 688 chips, the $FE page select from the 688 chip goes low when active. He has that to an active high input on the 138, so the I/O selects are active for everything but what he wants. Suggest tying the 688 output select (pin 19) to the 138 input select at pin 4 and then tying pin 6 (of the 138) to +5V.

[banedon]

The guys here are much more experienced than me, but what I would recommend on top of what they recommend is to create a single cycle stepper. This is small PCB with some components and a button. Every time you press the button, a 1uS pulse is outputted. You remove your oscillator/crystal and plug in the steppers' output. This has the effect of producing a 1Hz signal per button press and so you can measure the address/data buses and also the address decoding lines to ensure that the have the correct value on them in between butoon presses.
Garth's circuit can be found here:
http://wilsonminesco.com/6502primer/ClkGen.html
My version (a copy of Garth's) : <link removed as as site is down>

And of course you could replicate this using an AVR or PIC - or simply use an Arduino; Button on one pin, another pin as output and just program the switch debounce and the pulse when the button is pressed.

[BigEd]

BigDumbDinosaur wrote:

Mercury1964 wrote:

I don't have an oscilloscope or a logic analyzer, so the only checks I can make are from a multimeter probing individual pins.

I didn't see this earlier for some reason.

You don't need a logic analyzer, only a logic probe, which is a relatively inexpensive device.
[snip]
A multimeter isn't really fast enough to see the rapid state changes that occur in a computer circuit. However, as Jeff noted, you usually can get some indication as to whether the voltage being sampled is steady or fluctuating if the rate isn't too high.

But do note that some multimeters have a frequency counting mode - all else being equal, get one of those, and you can see the frequency of signals such as Sync, RnW, chip selects, interrupts and so on. That can tell you a lot.

[Dr Jefyll]

floobydust wrote:

Also, it appears that he's not selecting the 74HC138 properly. Looking at the datasheets for the 138 and 688 chips, the $FE page select from the 688 chip goes low when active. He has that to an active high input on the 138, so the I/O selects are active for everything but what he wants.

Good spot, floobydust! I haven't looked at the schematic, but what you're saying is consistent with Mercury1964's comment that everything worked until he installed the VIA. I think you've identified the problem!

BigEd wrote:

some multimeters have a frequency counting mode - all else being equal, get one of those, and you can see the frequency of signals such as Sync, RnW, chip selects, interrupts and so on. That can tell you a lot.

I'm not sure I agree about the value of frequency counting mode, as I suspect there's a threat of its results being misinterpreted. Its intended function is to determine the frequency of a periodic signal. But I suppose it could be used to determine the mere presence or absence of any sort of pulse train (periodic or otherwise) -- is that what you meant?

FWIW, my preference in multimeters is to AVOID the digital types. I'd much rather use an old-style analog meter with an actual needle.
(I wish I knew where a person can buy an analog multimeter nowadays! I mean something good or at least mediocre; all the analog meters I've seen for sale recently are rock-bottom price/quality.)

-- Jeff