Basically by making 3 of the datastreams hold 2 TIA updates each (HMxx value in upper nybble, ENAxx in lower nybble) then we could do lda/sta/sta and squeeze in enough time to also update audio to support digitized samples for the Voice Alerts.

So as of Thursday around lunchtime I was planning to reboot Draconian yet again.

Then, later that night, this happened in the Bus Stuffing Demos topic:

Could always enhance the driver to include a "fast jump" feature.

JMP FastJump would be detected and the 2 byte address is pulled from ARM memory instead of the ROM. Similar to how fast fetch works.

For a 10 cycle savings. If we could update the other 2 HMxx registers (so HMM0 and HMM1 during a ball reposition kernel) then the STA HMCLR is no longer needed, which yields up another 3 cycles. With that in mind, I worked up another test rewrite which resulted in this:

So we'd have digitized audio, diagonal shots, fancy station cores, etc that I was hoping to do using BUS Stuffing.

This is a significant improvement, so cd-w's going to look into updating the CDF driver to see if it's possible for him to squeeze in Fast Jump. Due to timing constraints in the driver he's not sure if can be done, and he won't be able to work on it for a few week due to prior obligations, so I'm going to hold off on the reboot until we know which of the two reboot options I'll be using.

In the meantime I'll be working on the audio support in Stella for BUS and CDF.

Then we should collaborate on Astro Blaster 2600 -- it's a "talkie" where speech in-game is more important than Bosconian -- because I have permission to take Bob's 7800 movement routines (which equal the Arcade but need tweaked for 2600 screen compensation, as was done for the 7800 amounting to only one divide by 2), and the TIA audio is already there (like Scramble 7800 to 2600).

I myself could do a decent batari Basic DPC+ kernel Astro Blaster using AtariVox+, but CDF with samples and less canned kernel constraints would be so much better.

Also, like DK Arcade 2600, I can do the Graphics, Sound, Speech Samples, Layout, but game logic and C programming are out of my wheelhouse.

If only we could all be as productive and fast as Bob DeCrescenzo was!

Yeah, can't wait to see what I'll be able to pull off in Frantic. While I'd love to use BUS, I have a feeling it's not going to pan out when room temperature is one of the factors of the current solution

Astro Blaster sounds good to me.

If only we could all be as productive and fast as Bob DeCrescenzo was!

Yeah, Bob really knocks them out! I have a feeling once we get a few different kernels written for CDF that it'll be possible to make new games much faster as development in C code is much faster than 6507 assembly. The Draconian kernel alone could be used for numerous games.

cd-w had me make a minor change to the CDF driver to add a check for a Fast Jump. The Fast Jump itself is not implemented, so it'll return the jump address as normal. This test was a success, so it looks like we have enough time to implement Fast Jump.

However, there's only room left in the 2K driver for 6 additional instructions after the check, which are not enough. Fast Jump is such a significant improvement that we're willing to give up some space for it. The driver will most likely end up 256 bytes larger, so 2.25 KB. That'll reduce both C Code & Data by 256 bytes, as well as C Variables & Stack by 256 bytes. This is still way better than the overheard for using DPC+.

That's so cool!!! I kind of wish that I had played Bosconian 'back in the day' now so I could appreciate this more...

Bosconian was one of my favorites back-in-the-day. It was at most of the arcades that I frequented, but I don't think it ever really caught on like the more popular games of the day. Maybe the name was too weird.

cd-w thinks we're good to go for the Fast Jump, so my plan of action is this:

Implemented Fast Jump in Stella - this is already done, size of the driver is irrelevant for implementing this within Stella.

Implement 3 voice audio in CDF

Implement audio sample support in CDF

copy audio & sample support to BUS (they work the same, data's even in the exact same memory locations)

Configure Stella so CDF driver is now 2.25 K (this will shift the locations of various things by 256 bytes which is why I'll do audio then audio->BUS first). NO LONGER NEEDED

Reboot Draconian using Fast Jump

Do note I won't be able to get to any of this until Sunday evening at the earliest as I have a house full of company arriving Friday for the Houston Art Car Parade, and I need to finish getting the house ready!

cd-w burned the midnight oil last night and managed to revise CDF to such an extent that he freed up 304 bytes in the driver! He still needs to implement FastJump, but it looks like we'll be able to keep the driver at 2K

It did change how the driver works - the CDF registers used to be this at the start of the 4K cartridge space (so AMPLITUDE is at $1020, $3020, ... $F020):

DSWRITE and DSPTR are hardcoded to use stream 0 (FastJump is likewise hardcoded to stream 31). The DS0DATA-DS31DATA and AMPLITUDE registers are now only accessible when FastFetch mode is on, so LDA #0-LDA #31 and LDA #32 respectively.

@PacManPlus. I don't ever recall seeing Bosconian. And I pretty much have seen and remember everything from 1972 on (1972 I was 5). I remember Pong, saw B&W video games switch to color (Galaxian, Pac-Man were the 1st color I remember). Saw electro-mechanical pinball go digital, but I'm too young to remember electro-mechanical coin-op games.

@Spiceware. When you say that now 3-voice music is generated on the fly, I assume we still have waveforms? I just was hoping it would scale all the way up to using samples. As in a simple 32-byte waveform to larger-byte samples as waveforms. Maybe not huge like a 3-voice dog bark piano, but more waveform size to closer match Organ, Banjo, HonkeyTonk Pi-an-oh, or even different instruments at once. Bass guitar, square wave, piano?

Thanks! We definitely have a great group of people here working together to figure out ways to push the 2600 further than even I thought would be possible!

I'm still recuperating from a full weekend - family was visiting for the Houston Art Car Parade. I plan to resume working on Stella's support for CDF and BUS tomorrow(basically I need to finish the audio routines), and start the Draconian reboot utilizing CDF's new FastJump feature this weekend.

I see some short ranges jumps in your code there. It's worth a check to see if you can set/clear the overflow flag ahead of time to do some unconditional branches with BVC/BVS. You could save some bytes there.

I can help just a little bit with optimizing as I don't have too much time.

I am curious if you can run these kernels in ram. I know you did that for the graphics in Space Rocks, but this would be the kernels instead. If the datastreams can fetch while running in ram then concievably you could load the kernels into ram at startup and change a few registers (i.e. RESPx, COLUPx). It could save a lot of rom.