65c02 SBC woes

[Mercury1964]

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

Code: Select all

; Register definitions

VIA_PORTB       = $FE10
VIA_PORTA       = $FE11
VIA_DDRB        = $FE12
VIA_DDRA        = $FE13
VIA_T1C_L       = $FE14
VIA_T1C_H       = $FE15
VIA_T1L_L       = $FE16
VIA_T1L_H       = $FE17
VIA_T2C_L       = $FE18
VIA_T2C_H       = $FE19
VIA_SR          = $FE1A
VIA_ACR         = $FE1B
VIA_PCR         = $FE1C
VIA_IFR         = $FE1D
VIA_IER         = $FE1E
VIA_PORTA_NH    = $FE1F

READIN          = $06

; Start of loader - ROM begins at $FF00
* = $FF00

; Setup VIA outputs
begin   lda #$FE
        sta VIA_DDRA
loop    lda VIA_PORTA
        and #$01
        sta READIN
        cmp #$01
        beq pin_on
pin_off lda #$AA
        sta VIA_PORTA
        jmp loop
pin_on  lda #$55
        sta VIA_PORTA
        jmp loop
        
*=$FFFC
!raw $00,$FF

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

[BigDumbDinosaur]

Mercury1964 wrote:

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.

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.

[Mercury1964]

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.

[BigDumbDinosaur]

Mercury1964 wrote:

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:

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

Quote:

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

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.

[BigEd]

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.

[floobydust]

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.

[Michael]

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

[BigDumbDinosaur]

BigEd wrote:

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.

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.

[BigDumbDinosaur]

BigEd wrote:

...If your design is socketed then take the chips out of the sockets.

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.

[BigEd]

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.

[Mercury1964]

floobydust wrote:

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.

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.

Code: Select all

** Memory Map **
              
$0000
|
|
|
|
|
|
|
|
| RAM (65024 bytes)
|
|
|
|
|
|
|
|
$FDFF

$FE00
|            
| I/O Devices (256 bytes)        
|
$FEFF
                             
$FF00
|
| ROM (LOADROM on schematic) (256 bytes) 
|
$FFFF
                
                
** Detail of I/O Devices, $FE00 - $FEFF **

$FE00 - $FE0F   I/O Device 0  (mapped to PROGROM)
$FE10 - $FE1F   I/O Device 1  (mapped to the VIA)
$FE20 - $FE2F   I/O Device 2  (unused)
$FE30 - $FE3F   I/O Device 3  (unused)
$FE40 - $FE4F   I/O Device 4  (unused)
$FE50 - $FE5F   I/O Device 5  (unused)
$FE60 - $FE6F   I/O Device 6  (unused)
$FE70 - $FE7F   I/O Device 7  (unused)
$FE80 - $FE8F   I/O Device 8  (unused)
$FE90 - $FE9F   I/O Device 9  (unused)
$FEA0 - $FEAF   I/O Device 10 (unused)
$FEB0 - $FEBF   I/O Device 11 (unused)
$FEC0 - $FECF   I/O Device 12 (unused)
$FED0 - $FEDF   I/O Device 13 (unused)
$FEE0 - $FEEF   I/O Device 14 (unused)
$FEF0 - $FEFF   I/O Device 15 (unused)

BigDumbDinosaur wrote:

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.

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

[BigDumbDinosaur]

BigEd wrote:

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.

OUCH!

[BigDumbDinosaur]

Mercury1964 wrote:

Here's a more detailed memory map.

Code: Select all

** Memory Map **
              
$0000
|
|
| RAM (65024 bytes)
|
|
$FDFF

$FE00
|            
| I/O Devices (256 bytes)        
|
$FEFF
                             
$FF00
|
| ROM (LOADROM on schematic) (256 bytes) 
|
$FFFF[/quote]
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.

[Mercury1964]

This is the test code:

Code: Select all

; Register definitions

VIA_PORTB       = $FE10
VIA_PORTA       = $FE11
VIA_DDRB        = $FE12
VIA_DDRA        = $FE13
VIA_T1C_L       = $FE14
VIA_T1C_H       = $FE15
VIA_T1L_L       = $FE16
VIA_T1L_H       = $FE17
VIA_T2C_L       = $FE18
VIA_T2C_H       = $FE19
VIA_SR          = $FE1A
VIA_ACR         = $FE1B
VIA_PCR         = $FE1C
VIA_IFR         = $FE1D
VIA_IER         = $FE1E
VIA_PORTA_NH    = $FE1F

READIN          = $06

; Start of loader - ROM begins at $FF00
* = $FF00

; Setup VIA outputs
begin   lda #$FE
        sta VIA_DDRA
loop    lda VIA_PORTA
        and #$01
        sta READIN
        cmp #$01
        beq pin_on
pin_off lda #$AA
        sta VIA_PORTA
        jmp loop
pin_on  lda #$55
        sta VIA_PORTA
        jmp loop
        
*=$FFFC
!raw $00,$FF

And this is the hex output:

Code: Select all

A9 FE 8D 13 FE AD 11 FE 29 01 85 06 C9 01 F0 08 A9 AA 8D 11 FE 4C 05 FF A9 55 8D 11 FE 4C 05 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF 00 00

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.

[BigDumbDinosaur]

Mercury1964 wrote:

This is the test code:

Code: Select all

; Register definitions

VIA_PORTB       = $FE10
VIA_PORTA       = $FE11
VIA_DDRB        = $FE12
VIA_DDRA        = $FE13
VIA_T1C_L       = $FE14
VIA_T1C_H       = $FE15
VIA_T1L_L       = $FE16
VIA_T1L_H       = $FE17
VIA_T2C_L       = $FE18
VIA_T2C_H       = $FE19
VIA_SR          = $FE1A
VIA_ACR         = $FE1B
VIA_PCR         = $FE1C
VIA_IFR         = $FE1D
VIA_IER         = $FE1E
VIA_PORTA_NH    = $FE1F

READIN          = $06

; Start of loader - ROM begins at $FF00
* = $FF00

; Setup VIA outputs
begin   lda #$FE
        sta VIA_DDRA
loop    lda VIA_PORTA
        and #$01
        sta READIN
        cmp #$01
        beq pin_on
pin_off lda #$AA
        sta VIA_PORTA
        jmp loop
pin_on  lda #$55
        sta VIA_PORTA
        jmp loop
        
*=$FFFC
!raw $00,$FF

And this is the hex output:

Code: Select all

A9 FE 8D 13 FE AD 11 FE 29 01 85 06 C9 01 F0 08 A9 AA 8D 11 FE 4C 05 FF A9 55 8D 11 FE 4C 05 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF 00 00

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.