So I've been tweaking and cleaning up some code, and now I come to a question about stack operations.

The code in question originally had several places like so:

(subroutine code)
(check for error condition)
(error condition detected)
INS
INS
JMP (error trap routine)
(no error, continue with subroutine)
RTS

I didn't like the idea of the "emergency exit" from the subroutine (especially as it wouldn't translate well to higher level languages), so I adjusted the code like so:

(subroutine code)
(check for error condition)
(error condition detected)
LDA #error
STA error_num
RTS
(no error, continue with subroutine)
RTS
.
.
.
(main routine immediately following JSR instruction)
TST errornum
BEQ no_error
JMP (error trap routine)
no_error (continue with main program)

So far, so good. Just wanted to give some background.

Now then, the second instruction the code executes after a power-up or reset is an instruction to reset the stack pointer: (LDS #$00FF)

I could see the need for this instruction in the original code, given that the code actively messes with the stack pointer, but now that I have eliminated all the INS instructions, do I even need to bother with manually resetting the stack pointer at the start anymore?

 

The iron clad rule of embedded systems programming is that you should never depend on the hardware to initialize things for you. If you ever come that way assuming the hardware has done it for you may end up regretting that decision. The explicit initialization of the stack pointer costs one instruction and gives piece of mind.

 

One more thing. It couldn't hurt to disable interrupts either before reinitializing the stack pointer.

 

One more thing. It couldn't hurt to disable interrupts either before reinitializing the stack pointer.

That's the very first instruction.
The next thing is setting up the PIA and PTM chips.
Then the variables are initialized before turning on the interrupts and moving on to the settings checks etc.

I'll leave the stack initialization instruction in place then. Thinking on it, I can see why it might be a good thing when doing a warm reset instead of a hardware reset. Thank you!

 

I just realized something else when looking something up in the 6801 data book, and I see what a ninny I was for asking this question, so am putting this up in case anyone else is looking at working with 'vintage' 68xx-class MPUs.

First, I'm far more familiar with the 65xx 8-bit MPU than the 68xx this project is built around.

On the 65xx, (in particular the 6510, the MPU in the trusty C=64 computer), the processor stack is hard-coded in silicon to reside at $0100 - $01FF.

On the 68xx, the stack can be located anywhere in RAM, but you actually have to tell the MPU where it is!

When working to document what each RAM location (in the code I'm working with) does, there happens to be a stretch of seemingly unallocated RAM at $E3 to $FF.

Well, the statement in question, LDS #$00FF, not only resets the stack pointer to the top, it also tells the MPU that the stack starts at $00FF.

Ergo, the space in my code that is reserved for the stack is.... $E3 to $FF.

D'oh (facepalm)!

So, that stack statement is staying, but I may actually re-point it to make use of a larger section of free ram (64 bytes).