3 cycle delay without use of an Illegal Opcode

[Wickeycolumbus]

This is a trick I found in one of Miss Piggy's Wedding's horizontal positioning routines. I'm not sure if it has been used/discovered before so I thought I would share it.

 

	bit VSYNC

 

I normally use the nop 0 trick, but If you don't want to use illegal opcodes in your game, you should try out this trick.

Edited February 12, 2009 by Wickeycolumbus

[Nukey Shay]

This is a trick I found in one of Miss Piggy's Wedding's horizontal positioning routines. I'm not sure if it has been used/discovered before so I thought I would share it.

 

	bit VSYNC

 

I normally use the nop 0 trick, but If you don't want to use illegal opcodes in your game, you should try out this trick.

 

You can also use the BIT opcode itself if you want to skip the next byte or 2 bytes (tho this changes status register flags in all cases of it's use...which is why many use illegal NOP's instead).

 

.byte $24 ; BIT.zp, waste 3 cycles in 1 byte and skip next byte

 

.byte $2C ; BIT.abs, waste 4 cycles in 1 byte and skip next word

 

These can be used for very short JMP's or unconditional branches. If a program contains 2-byte data tables and needs to waste 4 cycles someplace, you can use BIT.abs to skip over one of them...

 

   STA WSYNC
  .byte $2C;waste 4 cycles by skipping the next 2 bytes
DataTable: .byte $44,$22;any 2-byte data table goes here
; ~ program continues...

 

Skipping over a single byte while wasting only 2 cycles can be done with any of the compare #imm opcodes (this too changes status, tho).

 

3 cycles without burning the status register can be done in 2 bytes by storing a value to any unused or unimplemented ram location. The hardware itself doesn't use $2D, $2E, and $2F...so you can use one of those. I'm not sure about using DEC and INC to them if you want to waste 5 cycles (does this change the flags?)...but if X is known to be 2 or less, you can burn 6 cycles without changing status by STA $2D,x.

[SeaGtGruff]

This is a trick I found in one of Miss Piggy's Wedding's horizontal positioning routines. I'm not sure if it has been used/discovered before so I thought I would share it.

 

	bit VSYNC

 

I normally use the nop 0 trick, but If you don't want to use illegal opcodes in your game, you should try out this trick.

In many cases you can also do some 2-byte zero-page instruction twice, such as LDA $80 followed by another LDA $80, or STA GRP0 followed by another STA GRP0. Of course, this requires that your code just happen to conveniently contain such an instruction in some area where you need to waste 3 cycles-- which is actually more likely than you might think. Anyway, the BIT VSYNC instruction is more generally useful, unless you can't afford to affect the state of the negative and overflow flags. But it doesn't need to be VSYNC; they probably just used BIT 0 (similar to way it seems that people are always using NOP 0 instead of, say, NOP 123), and a disassembler interpreted it as BIT VSYNC, or even as BIT CXM0P.

 

Michael

[supercat]

But it doesn't need to be VSYNC; they probably just used BIT 0 (similar to way it seems that people are always using NOP 0 instead of, say, NOP 123), and a disassembler interpreted it as BIT VSYNC, or even as BIT CXM0P.

 

Incidentally, in some banking schemes like 3F or X07, "NOP 0" or "BIT 0" may cause an undesired bankswitch. "NOP 128" is probably safer.

[SeaGtGruff]

But it doesn't need to be VSYNC; they probably just used BIT 0 (similar to way it seems that people are always using NOP 0 instead of, say, NOP 123), and a disassembler interpreted it as BIT VSYNC, or even as BIT CXM0P.

 

Incidentally, in some banking schemes like 3F or X07, "NOP 0" or "BIT 0" may cause an undesired bankswitch. "NOP 128" is probably safer.

Good point. Although if you use VSYNC or CXM0P instead of 0, and set the TIA_BASE_ADDRESS in your code to $40, DASM should handle it for you automatically, right?

 

Michael

[supercat]

Good point. Although if you use VSYNC or CXM0P instead of 0, and set the TIA_BASE_ADDRESS in your code to $40, DASM should handle it for you automatically, right?

 

It would, though in X07 banking, if bank E is selected, hitting $40-$7F will switch to bank F; if bank F is selected, hitting $00-$3F will switch to bank E. This is part of what makes the Stella's Stocking menu possible (the display needs direct access to ten pages of data, and the wave generator needs direct access to nine). The simple DASM remedy is to change the SLEEP macro to use "NOP $80" instead of "NOP $00", since that never triggers a bank switch in any scheme I know of.

[SeaGtGruff]

Good point. Although if you use VSYNC or CXM0P instead of 0, and set the TIA_BASE_ADDRESS in your code to $40, DASM should handle it for you automatically, right?

 

It would, though in X07 banking, if bank E is selected, hitting $40-$7F will switch to bank F; if bank F is selected, hitting $00-$3F will switch to bank E. This is part of what makes the Stella's Stocking menu possible (the display needs direct access to ten pages of data, and the wave generator needs direct access to nine). The simple DASM remedy is to change the SLEEP macro to use "NOP $80" instead of "NOP $00", since that never triggers a bank switch in any scheme I know of.

Okay. I wasn't sure about how X07 would react, because I haven't ever read any specifications for it. From what you've said about hitting $00 to $3F versus $40 to $7F, I'm now wondering how *any* TIA access is handled? It sounds like all the code in bank E must access the TIA via $00 to $3F, whereas all the code in bank F must access the TIA via $40 to $7F. Or maybe it's even more complicated than that?

 

Michael

[supercat]

It sounds like all the code in bank E must access the TIA via $00 to $3F, whereas all the code in bank F must access the TIA via $40 to $7F.

 

That's precisely what it does.