SpiceWare's Blog

If batari Basic ever gets a version of this with more variables somehow, I will smack myself in the face with a rubber walrus!

Is any bB programmer even taking advantage of the hundreds of variables made available via SetValue and GetValue?

Is Bus Stuffing still under development? Or is it going to be replaced by CDF?

I have a personal deadline for finishing Draconian, and we've past my cutoff^* for resolving the issues with BUS, so I've opted to use CDF for the reboot.

Chris is looking into getting a problem system^* so he can work on finding a solution. ZackAttack may still be looking into a solution as well, I don't know. And I'm still working on adding BUS support to Stella - all I have left are the audio routines, which will be identical to those in CDF so I'll be able to copy/paste the routines after I finish Stella's support for CDF.

^* I even extended it a week, my original cutoff was the 1st.

^* looks like Nathan's going to send him one

Thx. As always this is neat stuff. Back in the 70's and 80's I never guessed the VCS would have such development taking place. Let alone any..

You mentioned multiple datastreams. Are these streams confined into a 4K bank or do you have more freedom?

Streams are still restricted to the 4K Display Data, but you do get more freedom with CDF.

The Harmony/Melody contains 8K of RAM. In DPC+ that's used like this:

• 3K DPC+ driver (in RAM for performance reasons)
• 4K Display Data
• 1K Frequency Data (in RAM for performance reasons)
  - OR -
  512 bytes Frequency Data
  512 bytes C Variables and Stack

For DPC+ the use of C is not required, thus the - OR -. 512 bytes isn't a lot when using C, so you end up using large amounts of the 4K Display Data to hold data that's never going to be displayed.

In CDF that 8K is used like this:

• 2K CDF driver
• 4K Display Data
• 2K C Variables & Stack

For CDF the use of C is required. Frequency values are now generated on the fly as needed, the results are stored within the CDF driver, so no need to waste large amounts of RAM to hold them. Also with 2K of RAM dedicated to C you get to use most of Display Data for data to be displayed. "most of" because you'll still need to use a small amount of Display Data to communicate between the 6507 and CDF that's how the 6507 passes the state of the console switches, joysticks, etc to the C code as the ARM does not have access to the internal hardware of the 2600.

See these blog entries for more info about the performance reasons:

• DPC+ARM - Part 6, DPC+ Cartridge Layout
• Harmony Memory

NOTE: anywhere that says "C" could also be replaced with ARM Assembly.

Looking forward to it's eventual release

Thanks! We made some drastic changes to CDF and I'm just about finished updating Stella to support the revisions. I plan to reboot Draconian again this weekend to take advantage of the new FastJump feature.

On 3/10/2017 at 1:48 PM, Keatah said:

Thx. As always this is neat stuff. Back in the 70's and 80's I never guessed the VCS would have such development taking place. Let alone any..

Yeah the "let alone any", is what I what I could have maybe predicted but there's no way in hell I'd imagine carts with tiny supercomputers inside.

I did correctly predict the high density memory in Silicon crystals. May not have got the capacity and date synergies right, but it up there. Flash and RAM, but mostly Flash.