Simply, what happens to the stack pointer at the limits? Does it wrap around on underflow/overflow, or does it stop?

Also, can RTI be used to return from a BRK? Should it? I read that it sets the stack up wrong, or something. I think if you had:


and RTId from BRK, it would end up at L3 and not L2, something like that?

Do folks compensate for that, is BRK not used per se for software breakpoints that way?

The hardware stack pointer loops around. If the entire page 1 is left for the stack, it wouldn't usually matter whether you initialize it or not, as it would just act as a circle with no beginning or end. If you do stack-relative addressing though with for example TSX, LDA 105,X, then if it were at 1FD, you would index into page 2 which is not what you wanted. It's best to have your reset routine include LDX #FF, TXS. I do this, and then put variables at the other end of page 1.

For normal usage however, you will not need to worry about running out of stack space. A common criticism of the 6502 is that the stack space is so limiting. A few higher-level languages (notoriously Pascal) do put very large pieces of data and even entire functions and procedures on the stack instead of just their addresses. For most programming though, the 6502's stack is much roomier than you'll ever need. When you know you're accessing the stacks constantly but don't know what the maximum depth is you're using, the tendency is to go overboard and keep upping your estimation, "just to be sure." I did this for years myself, and finally decided to do some tests to find out. I filled the 6502 stack area with a constant value (maybe it was 00-- I don't remember), ran a heavy-ish application with all the interrupts going too, did compiling, assembling, and interpreting while running other things in the background on interrupts, and after awhile looked to see how much of the stack area had been written on. It wasn't really much-- less than 20% of each of page 1 (return stack) and page 0 (data stack). This was in Forth, which makes heavy use of the stacks. The IRQ interrupt handlers were in Forth too, although the software RTC (run off a timer on NMI) was in assembly language.

There's a good forum topic on BRK at viewtopic.php?f=2&t=1649 , with links to a couple more. BRK is officially a 2-byte instruction, so you can have a signature byte following the 00. That doesn't mean you have to use the signature byte, but the RTI (which is the normal way to return from BRK) will skip over the next byte after the 00.

Edit: Corrected "RTI is officially a 2-byte instruction" to "BRK" is officially a 2-byte instruction." Getting ahead of myself again.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Indeed, RTI will come back to L3. But note that the saved value of PC on the stack is different when you're about to RTI compared to when you're about to RTS. You'll also need to emulate correctly the B flag and the unused flag in the status word: they are common stumbling blocks!
Cheers
Ed

Same for the 65C816 in native mode, except when the stack pointer hits $0000 it wraps to $FFFF.

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

A quick way to test the behaviour of the NMOS 6502 is to run a short test program on the visual6502 - it's simulating the transistors, so you're not merely checking someone else's emulator. For example, the difference between RTS and RTI can be seen by comparing these two traces:
http://visual6502.org/JSSim/expert.html ... 48484860ea
http://visual6502.org/JSSim/expert.html ... 48484840ea
and that gives a clue about the different stack-pushing behaviour of JSR compared to BRK and interrupts.

The documentation for these URLs is found here:
http://visual6502.org/wiki/index.php?ti ... _interface

Cheers
Ed