Clever or interesting uses of the BRK instruction?

[AkashicRecord]

Since the Atari VCS and it's facilities are not interrupt-driven, are there any novel uses for the BRK instruction?

[azure]

It can be used for calling a subroutine with an argument. The BRK instruction takes an extra padding byte after the instruction. References frequently list BRK as being a 1 byte instruction, but it actually uses 2 bytes. I'm using it in my game for a generalized way to call subroutines in other banks with 1 byte argument.

 

It can be used to quickly strobe two bytes on RESx. That's also mentioned in the link above.

 

It can also be used to implement cooperative multi-tasking by placing task switching code in the interrupt handler.

[AkashicRecord]

It can be used to quickly strobe two bytes on RESx.

That's exactly along the lines of how I thought it could be utilized. The sound driver code example in the link is certainly interesting as well.

[NostAlgae37]

That's exactly along the lines of how I thought it could be utilized. The sound driver code example in the link is certainly interesting as well.

 

Nice to see you back on here, Akashic. Have you had any time to work on your Tetris game lately? I used to enjoy reading your postings on that thread even though I'm not that technically-minded (it always made me feel smarter when I understood a little of it. )

[AkashicRecord]

Nice to see you back on here, Akashic. Have you had any time to work on your Tetris game lately? I used to enjoy reading your postings on that thread even though I'm not that technically-minded (it always made me feel smarter when I understood a little of it. )

Thanks!

 

Yep, I'm back to developing it (as of just a few days ago.)

 

I'll be updating it's main thread in the near future.

[ChildOfCv]

Interestingly, I ran across a YT talk about the reverse engineering the 6502 chip. One of the things he mentioned is that if a real interrupt happens at the same time as a BRK instruction, the BRK is lost. So I guess it's a good thing they leave the INT pin unconnected.

 

Geek link:

https://www.youtube.com/watch?v=fWqBmmPQP40

[JeffJetton]

It can be used for calling a subroutine with an argument.

 

 

Wow! I'm new-ish at this stuff, and that's the first time I've seen the "cookbook" at that link. There's some seriously great stuff there.

 

It looks like there were more ideas planned that were yet-to-be collected in it. Did it ever get finished or more fleshed-out?

[Joe Musashi]

One more: Using BRK to perform quick horizontal color changes.

[AkashicRecord]

One more: Using BRK to perform quick horizontal color changes.

Thanks for this one, Joe!

[NostAlgae37]

One more: Using BRK to perform quick horizontal color changes.

 

Hi Joe, I went here:

 

http://atariage.com/forums/topic/195210-very-early-wip-of-something-ive-been-working-on-for-ages/?p=2482601

 

And it says something about this being used to have more than one color per line on a sprite. Would that eat up a lot of memory resources and/or increase flicker? I ask because there is a homebrew game currently in development that this might possibly be useful for. Thanks!

[AkashicRecord]

It can be used for calling a subroutine with an argument. The BRK instruction takes an extra padding byte after the instruction. References frequently list BRK as being a 1 byte instruction, but it actually uses 2 bytes. I'm using it in my game for a generalized way to call subroutines in other banks with 1 byte argument.

I was just listening to the "Stella at 20" interviews yesterday, and I believe I heard Joe Decuir mentioning using the BRK vector to replace JSR calls in order to save like 3 or 4 bytes in order to get under 2K at some point...

[AkashicRecord]

I was experimenting with BRK this evening by pointing the IRQ vector to RIOT RAM and setting the stack pointer over COLUPF and then fixing up a 16-bit pointer in RAM (following a JMP instruction) to function as a sort of faux RTS for the BRK. I see some possible use for this, even though it is somewhat limiting. Changing 3 colors in 7 cycles is kind of sweet. Adding 3 cycles for the RAM JMP is still 5-8 cycles less than "standard" color changes.

Edited February 20, 2019 by AkashicRecord

[AkashicRecord]

I thought of an implementation where the stack would be set to point to HMOVE preceding a BRK.

 

In this case, both RESMP0 and RESMP1 would also be written to during the 7 cycles. Setting the SP to point to ENABL afterward would allow a following BRK to reenable the ball and missiles. (This same trick could also be used to disable the ball and missiles by BRKing over ENABL...)

 

Of course, certain bits / flags have to be set or cleared for these things to be possible.

 

I also wonder how the timing of HMOVE is affected here, because the timing of the strobed write should be at least 2/3rds of a cycle faster(?) via BRK rather than via STA.