How do you know if your code is structured well enough?

[Drew Sebastino]

PLA means pull value from stack into accumulator

I know, it's that those values would have needed to be pushed on the stack to begin with, which at the end of it all, is needlessly more complicated and slower than just "LDA buffer".

[dougeff]

You would (outside of vblank) store the stack pointer, change it to maybe #$80, PHA all your updates, change the the stack pointer back to original. Wait for vblank. Store the stack pointer. Change it to #$80 - # of updates, the do the PLA, STA bit. When done, change it back.

Well, that sounds like a pain in the ass, doesn't it? I originally thought it would be more efficient cycle-wise, but it's not.

[Drew Sebastino]

Isn't that just a tradeoff between VBlank time and non VBlank time? I think that example would do more harm than good.

I originally thought it would be more efficient cycle-wise, but it's not.

Yeah.

[lidnariq]

You don't need to use PHA to assemble the loop. You could use absolute,X addressing, for example.

The nice thing about a stack-sourced blitter is that it's general purpose, and could be reused for multiple different buffers. The entry point and value of S when you start exactly determine which and how many bytes.

PLA / STA $2007 is 4 bytes, so calculating the entry point is even pretty easy.

[darryl.revok]

You don't need to use PHA to assemble the loop. You could use absolute,X addressing, for example.

The nice thing about a stack-sourced blitter is that it's general purpose, and could be reused for multiple different buffers. The entry point and value of S when you start exactly determine which and how many bytes.

PLA / STA $2007 is 4 bytes, so calculating the entry point is even pretty easy.

This went over my head a bit, but I'm pretty curious as to what you mean so I hope you don't mind if I ask a couple questions.

First, the term blitter is a new one for me. I see from Wikipedia:

In a computer system, a blitter is a circuit, sometimes as a coprocessor or a logic block on a microprocessor, that is dedicated to the rapid movement and modification of data within that computer's memory.

So in this instance, you just mean kind of like a buffer or place to store data that will be written and loaded often?

I used the stack to store collisions that have taken place in a frame, the owners and angle, and then I pull those and assign the data to it's owner after the collision routine. The stack concept is new to me but it seemed like an elegant way to address that issue because the number of collisions will vary and I didn't want to assign specific memory addresses to the max number of collisions possible, or deal with assigning the collision data to object behavior during my collision detection routine.

So, I thought about using the stack to preload tiles as well, but then I ran into the issue I mentioned about the return address. I actually just modified the way I stored map data which made the way tiles were located much simpler, but I'm still curious. I figured I could pull two bytes from the stack, store them somewhere, then push them back onto the stack before leaving.

I'm confused though when you say to calculate the entry point. Are you saying to count the number of bytes your code takes from when you first pulled from the stack? Why would you want to do this? The address it's going to pull at RTI is the address you need, right?

Sorry, I'm totally n00bing out, but I'm intrigued by the concept.

[lidnariq]

(Using ca65 syntax) Say you had something like

Code: Select all

.proc do_xfer
 .repeat 16
  pla
  sta $2007
 .endrep
  txs
  rts
.endproc

To transfer the 14 bytes starting at $158, you'd TSX / STX save / LDX #$58 / TXS / LDX save / JMP do_xfer+(16-14)*4

[tepples]

Which takes about the same number of cycles as

Code: Select all

  .repeat 16, I
    lda $0100+I,x
    sta $2007
  .endrepeat

Both a pull and an indexed load that doesn't cross page boundaries take 4 cycles.

[Drew Sebastino]

Have we finally decided that it's much easier to just load and store than to pull and push and do a bunch of other nonsense?

[darryl.revok]

Have we finally decided that it's much easier to just load and store than to pull and push and do a bunch of other nonsense?

To my n00bish understanding I believe it's situational. There are benefits to using the stack and downsides. There are times when the stack is the best option for doing something, like when you need first in, last out order.

Which takes about the same number of cycles as

Code: Select all

Code:
  .repeat 16, I
    lda $0100+I,x
    sta $2007
  .endrepeat

That assembles as an unrolled loop, right?

[tepples]

Yes, as I explained elsewhere.

[tomaitheous]

Am I the only one with a weird habit of intentionally avoiding macros? I just don't like them, because when first starting out with assembly people got onto me for being too macro-heavy (since it made my code have no subroutines and therefore be redundant).

Um..huh? I think you're referring to in-line function/subroutines? I just talking about general macros.

Like this:

Code: Select all

;##########################################################################
;..........................................................................
;
; Note: Needs to be called after LoadScreen or LoadSideScreen 
;
;
LoadNextScreenAttribs:

			MOVE.w		screen_attrib_pointer,<A0
			MAPBANK.2	screen_attrib_bank,$6000

			;load player position
			MOVE.b		[A0],YXstart
			INC.w			<A0
			
			;check for NPCs
			MOVE.b		[A0],ScreenNPC.next
			INC.w			<A0
			clx
			cly
.load_Exitqueue
			MOVE.b		[A0], Exitqueue,x
			INC.w			<A0
			inx
			MOVE.b		[A0], Exitqueue,x
			INC.w			<A0
			MOVE.b		[A0], ExitArea,y
			ADD.w			#$02, <A0
			iny
			inx
			cpx #$10
		bcc .load_Exitqueue