So loop is basically an infinite loop then? Same as:qbradq wrote:Also, there is no end clause for loop.
Code: Select all
while 1==1 ... end while
That makes sense based on the limitation that recursion isn't allowed as the second call will override the variables of the first. So basically every subroutine's variables will ALWAYS occupy a location in ram. A subroutines variables aren't temporary. So if one is trying to conserve ram use try to limit the number of variables used. Using globals for a subroutine to modify themselves, vice using temporary storage variables within a subroutine would be best. Or perhaps a handful of global temp variables which all routines can use as scratch. These things make sense when you understand the underlying assembly going on. One can take the easy route and create those temporary variables without trouble, but then when it comes to optimizing it helps to have a good grasp of assembly.Subroutine parameters are copy-on-call. If you want them in zero-page, use the fast modifier for the subroutine. If you want the subroutine's variables in zero page, use the fast modifier on the variables. uc65 only uses the stack to store register values during interrupt handlers.
rom and ram apply to everything that emits code or variables following those statements until the next such statement.
Again when I am feeling better I will try to make the documentation more clear.
Regarding my discussion of having banked ram, it would sound prudent to put all globals in system ram so they truely are global (regardless of banking). To allow subroutines to use banked ram for variable use would require some specific rules. Let me know if this sounds right:
subroutine parameters: when are variables copied over? I assume it's just before the parent routine jumps to the child subroutine. So by ensuring the child's ram bank is active prior to calling the subroutine, you ensure the subroutine will get the copy over of input parameters.
variables within the subroutine: The subroutine needs to ensure it's ram bank is active before using the variables.
There is no harm in the parent setting up ram banking for the child's variables. But as a design choice you could make the child responsible for setting up banking for it's own variables. Parents MUST initialize child's ram banking when parameters are passed in though to ensure proper copy over. Since ram/rom segments can't be used within subroutines, that means the parameters and variables of a subroutine need to be in the same bank/segment. Starts to get tricky the more I think about this... Having banked SRAM would require a lot of delicate care especially if the parent and child's ram wasn't visible at the same time.
Really my only desire is to put game/graphics data swappable with RAM in FME-7 style. So operating with the assumption that the WRAM was always there except for the routines which swapped in ROM for game/graphics data, then you'd be okay.
The best way to handle funky situations like that were you had to handshake between parent and child ram banking would be to make use of the stack and/or A/X/Y registers for passing/returning variables. Using the stack for passing in parameters could be done with the language as-is by creating a helper 'handshake' function to utilize the stack so you'd pass the parameters into the helper vice the subroutine itself.
So I'm having some confusion on how to best utilize return variables. I was writing a subroutine to read controllers:
Code: Select all
;; Read controller ports ;; ;; @param padnum The controller pad desired to be read ;; return button output A,B,sel,srt,U,D,L,R export sub nesReadPad byte padnum as byte ;strobe latch signal controller1 = $10 controller1 = $00 if padnum == 1 asm LDX #$08 joy1_loop: LDA $4016 LSR A ; bit0 -> Carry ROL nesReadPad_return ; bit0 <- Carry DEX BNE joy1_loop end asm else ;if padnum == 2 asm LDX #$08 joy2_loop: LDA $4017 LSR A ; bit0 -> Carry ROL nesReadPad_return ; bit0 <- Carry DEX BNE joy2_loop end asm end if return nesReadPad_return end sub
Is there any way to utilize macros with uc65?