Injecting instructions durring drawscreen

[Trip2018]

I'm finally getting back into programming on the vcs again after 4 years and I was curious if it was possible to change variables on the fly while the screen is being drawn or if we're stuck with just drawscreen. Apologies if this is a duplicate of any kind, I did do some digging and couldn't find much besides an implied feature for graphics.

  

On 3/15/2008 at 2:38 AM, batari said:

I had to go back and look at my code to remember what I did.

 

If you use a vector, you lose the ball, and it appears that you can only use player1 or missile1. Also, using a vector seems to prevent you from using a multicolored P1. However, if shifting the missile per line, you can turn the missile on and off per line as well.

 

You can use the above to make the missile into a "fake player" (for example, a 4-wide missile shifted per line might resemble a lightning bolt, similar to that in Tossing Cookies.)

 

You should be able to vary the missile width per scanline, either 1, 2, 4 or 8 wide per scanline instead of shifting, but it appears that you will lack the ability to turn the missile on and off if you do this. I need to do a little more work to get this part working, but in theory it should work.

 

If you wish to use player1 shifted per-line, use of missile1 is limited in sort of a weird way. I'll get into that later.

 

I probably should attempt to integrate this into a beta release of bB so people can play with them and report bugs.

 

Lastly, I am now thinking that "vectors" are not a good name for these, because the term has another distinct meaning in programming. Any suggestions for another name?

 

Also I am aware that it's not possible to change anything while a scan line is being drawn after my previous post.

 

If it's not possible, are there any resources for writing a kernel so I can do that?

 

I wanna try and see if I can feed numbers into the tia volume for better audio control à la pitfall 2

Edited December 8, 2021 by Trip2018

[+Gemintronic]

Maybe the vblank command can help?

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#vblank

 

There has been digital sample playback and better music playback efforts.. but, nothing that seems (to me) appropriate to run during gameplay.  Probably due to CPU cycle limits.  Interested in what you come up with!

[Trip2018]

I'm thinking a sort of accumulator method than can be used for simple 16 byte looped samples. Simple enough for a saw/square/triangle etc.

Edited December 9, 2021 by Trip2018

[+Gemintronic]

Haven't played around with it yet but TIATracker *might* do more or less what you need?

 

[Trip2018]

I've messed around with it for a while actually. It seems to only update on a per frame basis as is with the stock tia sounds. Works for fades and nice bloops but still has the base restrictions for pitch and such, something I (hopefully) want to tune out if it's possible.

[Trip2018]

I think I found something here

 

[+Karl G]

You can't execute custom code during the visible screen using bB. If you want to experiment with modifying the kernel code, you can put a copy of std_kernel.asm in the same directory as your bB source file, and your project will use the version in that directory instead of the standard one if you end up modifying it. As far as I know, there aren't any guides to the code for the built-in bB display kernels.

[orange808]

Getting audio register updates into the kernel is the easy part. You're already counting cycles and the instructions are predictable. Your real problem is hitting the audio registers regularly during the blanking periods when you need to handle your game logic. That's when things get tricky.

 

Need to use proper assembler on DPC+ with C++ driver code (not the same as batari Basic DPC+).  I think Spiceware mentioned a Harmony Club with tutorials for that.  The people that need and use DPC audio don't use bB and it works fine in the current workflow, so the feature probably isn't coming down the pipeline.

 

 

 

[Trip2018]

Do you think it would be more sustainable while still sounding ok if audio updates were on a once-per-scanline basis using the standard kernel?

Edited December 13, 2021 by Trip2018

[Trip2018]

Yeah a quick google search says 16 kHz. I'll probably be fine as long as I make it a priority to update at the start of each Hblank.

Edited December 14, 2021 by Trip2018