Code structure (real basic)

[tsu]

I'm separating my logig code from drawing code, taking it out of NMI. I'm using the document, " The Frame" by Disch.

I don't see why there is a rts in his "WaitFrame:"

WaitFrame:
inc sleeping
Loop:
lda sleeping
bne Loop
rts


I can omit that rts if my program runs into WaitFrame from the getgo, right?
Is it there for someone who would have jumped to waitframe from somewhere?

What happens if there is nowhere to return to?
It carries on down the code? Or jumps to a random ram value?

And do programs end when they reach the end of code?

[blargg]

Normally an RTS must have a matching JSR that occurred before it, and you can only RTS once for each JSR executed. RTS just pops two bytes off the stack, forms an address, and sets PC based on this.

And no, your program won't just end at the last instruction you code, since there are more in memory after it. Always end execution with an infinite loop or similar, otherwise you might find the program counter going back to some unexpected part and re-running earlier code the wrong way, causing confusing results.

forever: jmp forever

[tsu]

What happens if I run into that rts if I had no jsr prior?
Also, what if a had previously done a pair jsr rtso?

I see his WaitFrame uses the rts because of its next function, DoFrame, which has a jsr back to WaitFrame.
Guess I'll just try it.

[tokumaru]

What happens if I run into that rts if I had no jsr prior?

The CPU will pull whatever 2 bytes are at the top of the stack from it and jump to the address formed by those two bytes. In most cases that will crash the program.

You know, instructions have these fancy names with words like "call", "return" and so on, but deep down their operation is really basic. Each instruction performs certain steps, and despite the name of the instruction, the CPU doesn't give a damn if you're using RTS to return from a subroutine or not. This instruction will ALWAYS get two bytes from the stack, form an address and jump to it. The CPU can't know whether you used JSR before, and it doesn't have to, and that's what allows people to use instructions in unconventional ways (for example, there's a jump table technique that involves manually planting addresses at the top of the stack before RTSing).

Also, what if a had previously done a pair jsr rtso?

Not really sure I got the question, but you should be sure to have as many RTSs as you have JSRs (unless you're intentionally pulling off some tricks). If the JSRs and RTSs are uneven, the stack will most likely overflow or underflow at some point, crashing the program. The same goes for PHA and PLA, and all kinds of stack operations really. Never forget things on the stack or try to get things you didn't put there.

I see his WaitFrame uses the rts because of its next function, DoFrame, which has a jsr back to WaitFrame.

Yeah, the person who wrote this code intended to use this as a subroutine, so that different loops in the program could call it. Most games have more than 1 game loop: there's one for the title screen, one for menus, one for gameplay, etc. For example, a gameplay loop might look like this:

Code: Select all

GameLoop:

	;[READ THE CONTROLLERS]

	;[PROCESS OBJECTS, PHYSICS, COLLISIONS]

	jsr WaitFrame

	;[PERFORM PPU UPDATES]

	;[RUN MUSIC/SOUND ENGINE]

	jmp GameLoop

NOTE: This code doesn't handle lag frames (when the game logic takes longer than a frame to finish), so if you use this structure you should either make sure there are no lag frames or that you don't have important events timed from the vertical blank that could possibly break the program if not executed at the correct time (a sprite 0 hit for a status bar, for example).

[tsu]

I made a typo up there. It was What if "I" had jsr/rts, then ran into a lonely rts. But you've answered that already.

So I did remember that stuff about the jump tables and jsr and the stack, pha. From the sound engine tutorials after nerdy nights.

I read that stuff last year.
I think Ihit a bump then too, trying to buffer.

Anyways. My game's coming along farther than my last few attempts. I hope they accept late entries in the 2014 competition. I don't know if I can do the hard parts yet.