not extra overscan cycles in DPC+, right?

[kisrael]

Before I burn time setting up experiments, DPC+ doesn't give you any extra processing time in the overscan + vblank, right? Like it's JUST during the kernel? 

What do like Champ Games do? Do they get more processing power by offloading to the cart's chips? is any thing like that available through bB, or is it a much deeper journey than that?

[+splendidnut]

For Champ Games, the game logic programmed in C code running on the ARM chip.  That runs during VBlank/Overscan while the 6507 runs NOPs (or some form of idle loop).  During the display kernel, the 6507 is then used to run the display code which is fed to it via the ARM chip.  That allows LDA #immediate instructions to be used in place of the longer load instructions, thus allowing more TIA registers to be changed per scanline than usual.

 

Currently, I believe there is no way to harness that power via bBasic.  You'd have to program in 6507 assembly (for the display kernel) and C and use the ARM compiler/toolset.  Ask Spiceware about it, or check out:

 

 

OR, you can just program in 6507 assembly and use the DPC+ as an advance bankswitching scheme like I did for ChaoticGrill.

[+splendidnut]

That's not to say that you can't do great things in bBasic using it's DPC+ scheme, as can be seen in some of the great DPC+ BBasic games like Tyre Trax, Unholy, etc.

[RevEng]

2 hours ago, kisrael said:

Before I burn time setting up experiments, DPC+ doesn't give you any extra processing time in the overscan + vblank, right? Like it's JUST during the kernel? 

Some of the bB commands are using the ARM to do things that would either be too expensive or plain impossible for the 6507, so from that perspective it is giving you some "extra" processing time in overscan. But the game logic is still driven by the 6507, instead of driven by the ARM like with John and Darrell's stuff. (I think this may not be true of some of Darrell's earlier stuff... IIRC the switch to ARM-driven code was driven by the limitations he experienced with 6507-driven attempts)

 

Splendidnut is quite correct that you can't follow the ARM-driven paradigm with bB, and likely this won't change, as generating ARM-driven code from bB would require an overhaul of pretty much everything. If driving the ARM from a higher level language is desired, it would be better to investigate SpiceC. (though I'm not sure where @SpiceWare is at with that project)

 

vblank cycles are pretty much used up by prep for the bB DPC+ kernel, so you actually have fewer cycles there than compared with using the standard kernel. I believe the overscan cycles are a bit reduced too, as is the available RAM. In that light, it makes what bB coders do with DPC+ all the more impressive.

 

 

[+SpiceWare]

2 hours ago, splendidnut said:

That runs during VBlank/Overscan while the 6507 runs NOPs (or some form of idle loop).

 

Correct, the 6507 is idled by putting a NOP on the databus.

 

48 minutes ago, RevEng said:

(I think this may not be true of some of Darrell's earlier stuff... IIRC the switch to ARM-driven code was driven by the limitations he experienced with 6507-driven attempts)

Medieval Mayhem and Stay Frosty 1 are entirely 6507 code.

 

For DPC+ the only thing I did without using ARM code was the DPC+ demo. Only other thing I'm aware of that uses DPC+ without ARM code is @splendidnut's Chaotic Grill.

 

We're now using CDFJ instead of DPC+. CDFJ requires the use of ARM code, which allowed us to shrink resources needed by the Harmony/Melody Driver and free up 2K of ROM and 2K of RAM for your projects.

 

1 hour ago, RevEng said:

If driving the ARM from a higher level language is desired, it would be better to investigate SpiceC.

 

Sadly all my 2600 projects had been on the back burner for a while due to issues in RL. I'm starting back on them today, and plan to do so in this order.

• finish updating the 128 pixel BUS Stuffing demo and post it with source code in the Harmony/Melody Club's currently empty Bus forum. I started working on this for Stella issue 707.
• finish the CDFJ tutorial.
  NOTE: The tutorial's already far enough along that a number of people have projects underway using CDFJ, such as @Silvio Mogno's Qbert remake.
• finish Frantic.
• resume work on SpiceC. When I do I'll create a new forum in the Harmony/Melody Club.