[cc65] CC65 and Stack Pointer

From: Hiroji Kimura <us3h-kmr1asahi-net.or.jp>
Date: 2006-11-28 19:16:41

Let me first mention that I don't use mailing lists usually. So please
let me know if this is not the right place to ask the questions that I
am asking.

I'm developing teaching materials based on a 6502 CPU for a national
university in Japan.  We will be teaching the students how to build a
calculator out of a 6502 with sound. This 6502 is created using a FPGA
based board with a 4x4 matrix keyboard, a video output, and a sound output.

Since we didn't know about the sp (stack pointer) used by the code
generated by the cc65 compiler,  we had the system crashing every time
the stack was used when the stack pointer pointed at the interrupt
vector addresses ($FFFA-$FFFF) and an interrupt occurred.  The system
that we are using initializes the zero page with 0's.  The sp pointed at
the address of $0000. Since the sp grows downwards the next address
would be $FFFF when pushax subroutine is called.

Now we finally tacked down the problem of not initializing the sp. So
we've decided to initialize it to point to somewhere like $FFF0 in
start.s which is our startup routine.

Now I have three questions.


1. Is it correct to say there are two stacks in the system? The true
hardware stack provided by the 6502 and the stack used by the code
generated by cc65.

2. Does our way of initializing the sp have any flaws?

3. Upon entering the interrupt handler do we need to push registers and
pop them before RTI?

Here is the related portion of our startup routine.

Start.s :

; zero clear of uninitialized data segment
        LDX #00
LOOP:   LDA #$00
        STA __BSS_RUN__
        CPX __BSS_SIZE__
        BNE LOOP


; call main routine
    LDA #$F0    ; <<<<------------- HERE WE ARE INITIALIZING THE SP
    STA $0000
    LDA #$FF
    STA $0001
    JMP _main

; IRQ Program
    .SEGMENT    "CODE"
   JSR _sound


Hiroji Kimura
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Tue Nov 28 19:16:54 2006

This archive was generated by hypermail 2.1.8 : 2006-11-28 19:16:57 CET