Jump to content
  • entries
  • comments
  • views

reboot is underway



The development of Bus Stuffing took far longer than I expected. While the results are awesome:



(yes, these are actual images generated by my 2600!) regrettably some 2600 Junior and some 7800 consoles just don't work correctly with it, resulting in vertical lines, incorrect colors, and even system crashes:

It appears to be a hardware issue with those systems, and I don't wish to offer up games for sale that won't work on some 2600s (I'd be OK if the problem was restricted to some 7800s).

So Chris Walton (creator of some awesome homebrews, such as Juno First and Chetiry!) and I decided to take what we learned creating the Bus Stuffing driver and come up with an improved version of DPC+ called CDF. CDF features:

  • Fast fetch mode
    5 cycle TIA updates like DPC+
  • 32 datastreams
    double that of DPC+ and BUS. In DPC+ and BUS after drawing the gameplay area I had to reassign the datafetchers to display the score/lives/level/etc, which took a bit of overhead. With 32 datastreams there should be enough to go around without having to reassign them midscreen.
  • identical datastreams
    All datastreams work exactly the same and have an X.Y increment. Harmony/Melody driver code is simpler (smaller) when all datastreams work the same, plus they're more flexible supporting increments such as 2.0, 1.5, 1.0, 0.5, etc. 2.0 is very useful for flicker blind displays like the 128x200 bitmap or the Draconian logo.
  • datastreams configured by C(or ARM) code
    In DPC+ datastreams could only be configured by 6507 code, taking scanlines worth of processing time to do so. In BUS and CDF this is done in C, which is much faster.
  • 3 voice music
    Just like DPC+ and BUS
  • digital sample support
    like BUS - no need to set aside a 2K of Display Data, which was a major headache in Frantic
  • more efficient driver
    the driver's smaller, like BUS, so more ROM (2K) and RAM (2K) is available for the game
  • designed for C (or ARM) code
    most features will require the use of C or ARM code.

Chris has been writing the driver for the Harmony/Melody while I've been adding support to Stella. We're far enough along that I've started in on the Draconian reboot as a test case. So far I have the 2-color 96 pixel kernel going using 14 of the datastreams.

Stella (changes not yet committed, I'm still working on the audio):


You can use RESET and SELECT to go between the menu and a "game" screen:

ROM - Harmony only at this time:

  • Like 6


Recommended Comments

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

  • Like 1
Link to comment

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..

Link to comment

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:

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

Link to comment

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.

Link to comment
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.

Link to comment

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.

Link to comment
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...