OK, I'm about to show my lack of assembler knowledge, but I think I know what's going on here. ; --------------------------------------------------------------- ; void __near__ __fastcall__ WriteVDC (unsigned char, unsigned char) ; --------------------------------------------------------------- > .segment "CODE" > .proc _WriteVDC: near > .segment "CODE" > ; ; { ; .dbg line, "WriteVDC.c", 8 jsr pusha Preserve the accumulator > ; ; r = reg; ; .dbg line, "WriteVDC.c", 9 ldy #$01 Set the Y index offset to one byte. > ldx #$00 I don't know what this is for. > lda (sp),y Read into the Accumulator one byte from the stack pointer > sta _r Store the accumulator in our external variable. Not pertinent to my library function. > ; ; v = val; ; .dbg line, "WriteVDC.c", 10 ldy #$00 Load Y with the index offset for the next read. > ldx #$00 I still don't know why we're doing this > lda (sp),y Load the Accumulator from 0 bytes from the stack pointer > sta _v Store our result in external variable _v. > ; ; } ; .dbg line, "WriteVDC.c", 11 jsr incsp2 Increase the stack pointer?? > rts Return from the function > .dbg line > .endproc OK, a couple of questions: 1) It appears that the parameters are placed in reverse order starting at the stack pointer such that if the function is located at $C000 then the memory would look like this: C000 - Val parameter C001 - Reg parameter C002 - First byte of code Am I reading the tea leaves correctly here? 2) Even though we preserved the original state of the Accumulator on the stack, it does not *appear* that we have recovered it. Is that something that happens in the incsp2 function? ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun Apr 25 10:29:45 2010
This archive was generated by hypermail 2.1.8 : 2010-04-25 10:29:48 CEST