Hello!

Background/info:

I designed a little 65c02 single board computer as a summer project. I finally got it built over the past weekend, and it doesn't seem to be working at all.

Schematics
Code


The test program is fairly straightforward (I think, at least): it reads the state of PA0 and sets ORA to either $AA or $55 is PA0 is a logic level 0 or 1, respectively. The computer, however, isn't doing this, and seems to be acting completely randomly. On most resets, it's not even executing from ROM; the ROM's chip select line goes high seconds after reset, although this too varies from anywhere to seconds to minutes. I don't have an oscilloscope or a logic analyzer, so the only checks I can make are from a multimeter probing individual pins.

What I've tried:

The voltage input is 5.1v 1A, and I've run it so far from two different power supplies, so I doubt it's a power supply issue.

The reset IC is behaving as expected; pressing SW1 causes a momentary 0v pulse on the reset line.

My ROM burner verified that the ROM's contents match my assembler's output, so I don't think the ROM is the issue.

I've tried running the computer off a *much* slower clock source generated by a microcontroller for debugging purposes, but when I do nothing seems to happen. No read to $FFFC/FFFD, no write to the stack, nothing.

What I've noticed:

I did notice something that struck me as odd with PHI0. When the 1mHz crystal oscillator is removed, I get a voltage reading of ~1.2v on pin 37 of the 65c02. When it is inserted, I get a voltage reading of ~2.5v on the same pin. I thought this was my multimeter attempting to average the high and low voltages of the square wave (since 5v / 2 = 2.5v), but I get the same thing with slower clock sources, going as slow as .25Hz (generated from a microcontroller) which should easily allow my multimeter to catch up. Is this normal?

Am I missing anything obvious? I'm at my wit's end trying to debug this and I have no clue where to go from here.

Thanks in advance,
John

I'd like to help but have a rough time reading your schematics. Can you post them in black and white? I was able to make out one thing: you are using all CMOS devices but with 74LS logic. That may be a factor.

A diagnostic step to take is to replace the ROM with a NOP generator and then probe the MPU's outputs for signs of activity.

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

I converted the schematics to black and white. Apologies for the confusing layout - I hope they're a bit easier to follow now.

I'm using all 74HC logic, actually. I must have forgotten to change the labels from Kicad's defaults... :facepalm:

That NOP generator looks interesting. I'll give it a shot tomorrow and report back what I find.

I can read them now. There's a CMOS version of the 74LS688? I wasn't aware of that.


I can't see anything immediately obvious, although publishing a detailed memory map may shed some light. Could it be that reset code is not appearing at boot time due to an error in ROM selection? The reset vector at $FFFC-$FFFD has to point to valid code somewhere. It's not at all clear from your schematic if that is happening.

One thing that could be a "gotcha" is the use of the clock outputs of the 65C02. They lag the clock input and I suppose there could be a subtle timing issue. WDC does not recommend their use in new designs.

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

Might be worth going round slowly with a magnifying glass looking for shorts and opens. Make sure power is actually reaching every chip, and that every pin is not shorted to its neighbour. If your design is socketed then take the chips out of the sockets.

I've been using the PH2O output clock on the WDC 65C02 (pin 39) for driving a 65C51 and 65C22 along with memory read and write qualifications without issue, but with your decode circuit, it might present a problem. I did notice there is no apparent pull-up resistor on the processor NMI line, nor is there a dedicated one for Reset. Is your circuit on a PCB, wirewrap board or breadboard? Are you using adequate decoupling caps at each of the chips? Agreed that a detailed memory map would be a plus.

_________________
Regards, KM
https://github.com/floobydust

Hi Mercury1964,

Do you have a way to monitor the data and address lines as well as manually control the reset line and clock the CPU a half cycle or single cycle at a time? Quinn Dunki did something like this and documented it in her Veronica computer project. Anyway, this might help you verify all of your control signals and watch the access to the FFFC-FFFD locations in ROM during the first six or seven cycles after you take the reset line high.

I used a 40-pin PIC to control and monitor an R65C02 when I was starting out and it really helped me get around the lack of test equipment. I used the serial port in the PIC and a terminal program to step through the reset sequence a single cycle at a time. Here's the output from an early experiment;



Later, I connected the SYNC line to the PIC and then I could monitor and display 'S' (Sync/Read) cycles as well as 'R' (Read) and 'W' (write) cycles.

Good luck with your project.

Cheerful regards, Mike

Good point, which I didn't bring up because I figured that would have been done as a first step. However, if one is new to this sort of thing it might not be an obvious procedure.

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

The thought occurred to me that one of the chips could be inserted the wrong way around. Been there, done that, and have felt stupid for doing it.

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

It could be worse: I read about someone who'd got the chip on the wrong side of the board. So they carefully bent every pin 180 degrees and put the chip in upside down.

I built it on a PCB, because I don't have any wire-wrapping equipment and felt that getting a PCB made would be easier. Kinda regretting that decision now, but I suppose there are worse ways to learn a lesson about rushing into things.

I have 0.1uF caps across each IC on the board. I didn't think to add pullup resistors to the RST and NMI lines - I'll add them later today when I'm building the NOP generator.

Here's a more detailed memory map.


That's actually the first thing I checked. I did solder the DS1813 on backwards originally, but luckily I caught it before I tried giving the board power...

OUCH!

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

The NOP generator should be able to prove (or not) that the MPU is functional, as it doesn't depend on address decoding to write the $EA bit pattern to the data bus. After you install it (and remove all other chips from the board), put your logic probe or 'scope on the MPU's SYNC output and power the unit. If the MPU is alive SYNC will rapidly pulse, as it will go low during the opcode fetch cycle of the instruction sequence. If SYNC does not pulse then you most likely have an electrical or assembly issue on your board, a faulty Ø2 clock generator or a bad MPU (rare but not unheard of).

A diligent examination of the board, as Ed suggested above, will uncover any assembly anomalies, such as inter-pin shorts, unsoldered connections, etc. Also, be sure to verify that Vcc and ground are properly distributed. The clock generator can be ruled out with the logic probe or 'scope—you should see a reasonably rectangular output varying from near zero volts to approximately Vcc. If you eliminate those items and the MPU still won't run with the NOP generator in place, verify that the reset line goes low and then high at power-on (watch it with the logic probe or 'scope). If that is working then you should try a different MPU.

Meanwhile, could you please list the assembly language code in LOADROM that appears at reset? Perhaps there's an issue within we might see.

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

This is the test code:



And this is the hex output:


The only change I made before burning the generated binary was adding two bytes of padding to ensure $FFFE and $FFFF were set to 0.

Which assembler are you using? I'm not familiar with a !raw pseudo-op.

I recommend you first rule out hardware issues with the NOP generator. The above code seems to be okay, although a proper reset sequence would put the MPU into a defined state and initialize the stack pointer.

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