Talk:RTS Trick: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
m (Reverted edits by 213.159.38.219 (talk) to last revision by Lidnariq)
No edit summary
Line 30: Line 30:
--[[Special:Contributions/212.8.208.194|212.8.208.194]] ([[User talk:212.8.208.194|talk]])
--[[Special:Contributions/212.8.208.194|212.8.208.194]] ([[User talk:212.8.208.194|talk]])
:Assuming that by <code>sta smc+2</code> you meant <code>sta smc+1</code> because 6502 is little-endian. But if you're doing any sort of nontrivial work in the NMI or IRQ handler, you would need separate 7-byte self-modifying trampolines in RAM for the main, NMI, and possibly IRQ handlers. And with the NES's 2048 byte RAM, 21 bytes might be a lot, though it's still not as bad as it would be on the Atari 2600. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 11:18, 21 May 2013 (MDT)
:Assuming that by <code>sta smc+2</code> you meant <code>sta smc+1</code> because 6502 is little-endian. But if you're doing any sort of nontrivial work in the NMI or IRQ handler, you would need separate 7-byte self-modifying trampolines in RAM for the main, NMI, and possibly IRQ handlers. And with the NES's 2048 byte RAM, 21 bytes might be a lot, though it's still not as bad as it would be on the Atari 2600. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 11:18, 21 May 2013 (MDT)
::If you have extra PRG RAM in the cartridge, you could use that, too. Also, self-modifying code seems to be especially suitable for disk-based programs (although in many ways other than just this!). --[[User:Zzo38|Zzo38]] ([[User talk:Zzo38|talk]]) 16:45, 8 December 2013 (MST)
== Fast RTS Trick ==
You can make a bit faster RTS trick also if all of the jump targets are in one 256-byte page. Alternatively, you can align each jump target to a separate page and then not even use a lookup table. In addition, even when using the full addresses, I prefer to store the high bytes in one table and the low bytes in another table, instead of doing it together. This results in a smaller and faster code. --[[User:Zzo38|Zzo38]] ([[User talk:Zzo38|talk]]) 16:45, 8 December 2013 (MST)

Revision as of 23:45, 8 December 2013

Indirect vs. RTS

Is there an advantage over using JMP ($0200), where $0200 has been loaded from the same kind of jump-table? that's what I wonder, but I'm not gonna count up the cpu cycles needed for either method right now. --Memblers 20:21, 25 Jun 2009 (PDT)

Not sure. Seems like a pick'em to me. Here are some things that come to mind:
  • RTS Trick doesn't require any RAM.
  • I personally think the RTS Trick is more readable. If I see a table of pointers in my (or somebody else's) code and they all have a "-1" after them, I immediately know their purpose and how they are used.
  • PHA, PHA, RTS requires less bytes than STA, STA, JMP (3 vs. 9).
--MetalSlime 00:08, 26 Jun 2009 (PDT)

Self-modifying

If you use self modifying code and assure that the table has to start at a page border (and store pointers to the routines, without the -1) then you can use a smaller and faster code:

tb_opcode_launcher_smc:
	; bytes, cycles
	asl ; 1, 2
	sta smc+2 ; 3, 4
smc:
	jmp (tb_opcode_rts_table) ; 3, 5
	; total 7 bytes and 11 cycles
tb_opcode_launcher:
	; bytes, cycles
	asl ; 1, 2
	tax ; 1, 2
	lda tb_opcode_rts_table+1, x ; 3, 4
	pha ; 1, 3
	lda tb_opcode_rts_table, x ; 3, 4
	pha ; 1, 3
	rts ; 1, 6
	; total 11 bytes and 24 cycles

--212.8.208.194 (talk)

Assuming that by sta smc+2 you meant sta smc+1 because 6502 is little-endian. But if you're doing any sort of nontrivial work in the NMI or IRQ handler, you would need separate 7-byte self-modifying trampolines in RAM for the main, NMI, and possibly IRQ handlers. And with the NES's 2048 byte RAM, 21 bytes might be a lot, though it's still not as bad as it would be on the Atari 2600. --Tepples (talk) 11:18, 21 May 2013 (MDT)
If you have extra PRG RAM in the cartridge, you could use that, too. Also, self-modifying code seems to be especially suitable for disk-based programs (although in many ways other than just this!). --Zzo38 (talk) 16:45, 8 December 2013 (MST)

Fast RTS Trick

You can make a bit faster RTS trick also if all of the jump targets are in one 256-byte page. Alternatively, you can align each jump target to a separate page and then not even use a lookup table. In addition, even when using the full addresses, I prefer to store the high bytes in one table and the low bytes in another table, instead of doing it together. This results in a smaller and faster code. --Zzo38 (talk) 16:45, 8 December 2013 (MST)