Jump to content
Random Terrain

Need help compiling and updating DPC+ information

Recommended Posts

It is not exactly the same as what is in the Pitfall II cartridge, [unused functions were dropped, and other functions were added] so they renamed it DPC+.

 

I think you're misunderstanding something, there's 2 bankswitch drivers.

  1. DPC - used to run Pitfall II
     
  2. DPC+ - not used to run Pitfall II

We didn't rename DPC, we created a new bankswitch format that took its inspiration from DPC.

 

DPC+ is not backwards compatible with DPC. The way the datastreams are prepped is different, the way the music works is different. Even if you could make Pitfall II use DPC+ (doubtful due to different bank switching hotspots) you'd just end up with scrambled graphics and corrupt music.

 

DPC prep for sprite

;       set the DataStream Pointer 0 for the graphic data
       lda #<(2047 - GraphicDataPosition + HowFarDownScreen)
       sta DF0LOW
       lda #>(2047 - GraphicDataPosition + HowFarDownScreen)
       sta DF0HIGH

;       set the DataStream Pointer 1 for the color data
       lda #<(2047 - ColorDataPosition + HowFarDownScreen)
       sta DF1LOW
       lda #>(2047 - ColorDataPosition + HowFarDownScreen)
       sta DF1HIGH 

;       set the MASK for DataStream 0
       lda #<(2047 - GraphicDataPosition)
       sta DF0TOP
       lda #<(2047 - GraphicDataPosition - ImageHeight)
       sta DF0BOT

 

 

DPC+ prep for sprite

;       set the DataStream Pointer 0 for the graphic data
       lda #<(GraphicDataPosition - HowFarDownScreen)
       sta DF0LOW
       lda #>(GraphicDataPosition - HowFarDownScreen)
       sta DF0HIGH

;       set the DataStream Pointer 1 for the color data
       lda #<(ColorDataPosition - HowFarDownScreen)
       sta DF1LOW
       lda #>(ColorDataPosition - HowFarDownScreen)
       sta DF1HIGH 

;       set the MASK for DataStream 0
       lda #<(GraphicDataPosition- 1)
       sta DF0TOP
       lda #<(GraphicDataPosition + ImageHeight)
       sta DF0BOT

Edited by SpiceWare
  • Like 1

Share this post


Link to post
Share on other sites

I thought I was saying that.. I guess I am just not saying it clearly enough.

I was trying to answer RT's question, "what the ARM code is in relation to the DPC+ version of batari Basic."

I wanted to convey that the 4K ARM code of batari Basic consists of the DPC+ (and what DPC+ is), and how DPC+ allows batari Basic to have a kernel that can do more at the same time (and list some of the things it can do) than original batari Basic.

Is DPC+ batari Basic's ARM code doing more things? I don't know.

  • Like 1

Share this post


Link to post
Share on other sites
Display Processor Chip in Pitfall II is emulated in code by the ARM processor in Harmony and Melody boards. It is not exactly the same as what is in the Pitfall II cartridge, [unused functions were dropped, and other functions were added] so they renamed it DPC+.

 

the way that reads is the DPC emulation, used to run Pitfall II on the Harmony, was renamed DPC+

 

Something renamed is still the same thing (a rose by any other name...)

Edited by SpiceWare

Share this post


Link to post
Share on other sites

the way that reads is the DPC emulation, used to run Pitfall II on the Harmony, was renamed DPC+

 

Something renamed is still the same thing (a rose by any other name...)

 

Do you have the time and feel like copying his post and making the changes that you'd like to see? Then I could copy and paste your edited version onto the bB page with the confidence that nothing got lost in translation.

Share this post


Link to post
Share on other sites

The way I see it, the things being said that are getting somewhat merged are:

 

The Display Processor Chip (DPC) is a coprocessor/bankswitch format for the Atari 2600 developed by David Crane. While it was planned to be used for a number of games, it was only used in Pitfall II due to the Video Game Crash of 1983. Due to the coprocessor, DPC allows for more advanced graphics and sound than prior 2600 bankswitch formats.

 

Harmony, Melody and Stella emulate just enough of DPC so they can accurately run Pitfall II. DPC provides features not utilized by Pitfall II, those features are not emulated.

 

DPC+ is a new coprocessor/bankswitch format that is inspired by, but not compatible with, DPC. DPC+ allows for even more advanced graphics and sound than DPC. DPC+ is supported by Harmony, Melody and Stella.

 

DPC+ Kernel is a selectable kernel for batari Basic. It utilizes DPC+ to provide advanced features to batari Basic programs.

 

If you add the DPC and DPC+ specs (bank counts, etc) I would list them separately from the above text, maybe as bullet point lists similar to the DPC and DPC+ slides in my homebrew presentation.

 

I am not familiar with the specifics of the DPC+ Kernel. While I don't know for sure, I suspect it's utilizing the ARM processor to help with the sprite processing - especially because of the sprite masking1. You can confirm the use of the ARM processor by looking for instances of STA CALLFUNCTION (could also be STX or STY) in the 6507 code for the DPC+ Kernel.

 

 

1 I developed sprite masking routines for Chun-Li in November of 2010. I don't know if batari used them, or was inspired by them, for the DPC+ Kernel.

Edited by SpiceWare

Share this post


Link to post
Share on other sites

R.T.,

I re-rewrote post 48.

What is written in post 55 looks correct, but I would add that the ARM code part of DPC+ batari Basic is the emulating of the DPC+ to get more in your program without having to make so many compromises.

Share this post


Link to post
Share on other sites

If you add the DPC and DPC+ specs (bank counts, etc) I would list them separately from the above text, maybe as bullet point lists similar to the DPC and DPC+ slides in my homebrew presentation.

 

In thinking more about it, since your site is about bB the specs for DPC and DPC+ are irrelevant. The only specs that matter are those pertaining to the DPC+ Kernel.

 

Including the specs for DPC and DPC+ could be seen as information overload, making it difficult for newbies that are getting started in Atari programming. They don't really need that info until they advance beyond bB.

Edited by SpiceWare

Share this post


Link to post
Share on other sites

In thinking more about it, since your site is about bB the specs for DPC and DPC+ are irrelevant. The only specs that matter are those pertaining to the DPC+ Kernel.

 

Including the specs for DPC and DPC+ could be seen as information overload, making it difficult for newbies that are getting started in Atari programming. They don't really need that info until they advance beyond bB.

 

That's why I originally made this post:

 

When somebody gets a chance, can you make a new thread that explains what the ARM code is in relation to the DPC+ version of batari Basic (so I can link to it from the bB page)? It could just be a small paragraph if you want. I just need a good batari Basic-related explanation that I can link to.

 

Thanks.

 

The bB page mentions ARM code and I was going to make ARM a link to the new thread here in the batari Basic forum for those who are curious. I figured if nobody who knows what they are talking about wants to make a new thread, I could just add a Did You Know? box to the bB page.

Share this post


Link to post
Share on other sites

I'm getting close to finishing my test program and I noticed that missile0 is black if it is above player0. Is that a bug, a limitation, a feature, or something that I'm doing wrong? (if you can't reply to my post, clear your cache.)

Share this post


Link to post
Share on other sites

Did you set COLUM0=<x> ?

 

Yep, I have COLUM0 = $FE. It's that color below player0 and the same colors that are in player0 when horizontal with it, but once above player0, it's black.

Share this post


Link to post
Share on other sites

Can you PM me the test?

 

The code is a horrible mess at the moment, but the .bin file version seems to be just about ready.

 

There are 10 sprites (player0 at the top, down to player9 at the bottom), 2 missiles (missile0 above missile1) and 1 ball on the screen. Hold down the fire button and press the joystick up or down to select an object. Hold down the fire button and move the joystick left or right to change the size of the currently selected object. To move the currently selected object, release the fire button and press the joystick in any direction.

 

ex_dpc_test_2013y_08m_24d_1603t.bin

 

To see the problem really good, make missile0 the largest size, then move player0 below it. Try moving various other sprites all around the screen and you might notice a few other odd things, like pieces of other sprites moving out of position once in a while.

  • Like 1

Share this post


Link to post
Share on other sites

OK, I think I accidentally reverted my COLUM0 fix before I started the 64k thing. A new version that should fix it will be posted shortly.

  • Like 3

Share this post


Link to post
Share on other sites

 

The code is a horrible mess at the moment, but the .bin file version seems to be just about ready.

 

There are 10 sprites (player0 at the top, down to player9 at the bottom), 2 missiles (missile0 above missile1) and 1 ball on the screen. Hold down the fire button and press the joystick up or down to select an object. Hold down the fire button and move the joystick left or right to change the size of the currently selected object. To move the currently selected object, release the fire button and press the joystick in any direction.

 

attachicon.gif

 

To see the problem really good, make missile0 the largest size, then move player0 below it. Try moving various other sprites all around the screen and you might notice a few other odd things, like pieces of other sprites moving out of position once in a while.

That was the first time I got to see 9 sprites horizontally for the worst-case flicker! Wild!

Share this post


Link to post
Share on other sites

Missile0 no longer turns black when player0 moves below it, but there is a weird thing that still happens with some sprites:

 

ex_dpc_test_2013y_08m_24d_2120t.bas.bin

 

Here's a video that shows the problem:

 

youtube.com/watch?v=HhK03uEwgwk

http://www.youtube.com/watch?v=HhK03uEwgwk

Share this post


Link to post
Share on other sites

Can you send me the .bas? It would save me time trying to recreate the problem, which doesn't seem to happen with msdpc.bas.bin.

Share this post


Link to post
Share on other sites

Missile0 no longer turns black when player0 moves below it, but there is a weird thing that still happens with some sprites:

 

attachicon.gifex_dpc_test_2013y_08m_24d_2120t.bas.bin

 

Here's a video that shows the problem:

 

I've never seen that before, but WOW Stella is awesome because I tried it on real hardware and it shows the exact same glitch!

 

Also I never liked as player1-9 move partway off the top, all the others line up under it after a certain value.

 

Note: since sprites 1-9 are the same, you can code:

Player1-9:

XXXXXXXX

..XXX..X

........

end

 

But you still have to keep individual colors, that hasn't made it in yet. As in:

Player1color:

$42

$42

$08

end

 

Player2color:

etc.

Share this post


Link to post
Share on other sites

Can you send me the .bas? It would save me time trying to recreate the problem, which doesn't seem to happen with msdpc.bas.bin.

 

PM sent.

 

 

 

 

I've never seen that before, but WOW Stella is awesome because I tried it on real hardware and it shows the exact same glitch!

 

Also I never liked as player1-9 move partway off the top, all the others line up under it after a certain value.

 

Note: since sprites 1-9 are the same, you can code:

Player1-9:

XXXXXXXX

..XXX..X

........

end

 

But you still have to keep individual colors, that hasn't made it in yet. As in:

Player1color:

$42

$42

$08

end

 

Player2color:

etc.

 

Thanks. I'll try that in my program, then add it to the bB page. I also have more to add to the bB page that you guys have already posted.

Share this post


Link to post
Share on other sites

PM sent.

Thanks. It's been quite helpful.

 

I've confirmed the the bug affects all bB DPC+ releases, and requires a bunch of virtual sprites to be stacked so close that they're 1 or 2 pixels away from flickering. That condition probably makes it a bit rare to see, unless a game purposefully lines them up as your demo does.

 

The bB DPC+ kernel is a bit of a rabbit hole, so it might be a while before I get to squashing this.

  • Like 1

Share this post


Link to post
Share on other sites

Note: since sprites 1-9 are the same, you can code:

Player1-9:

XXXXXXXX

..XXX..X

........

end

 

But you still have to keep individual colors, that hasn't made it in yet. As in:

Player1color:

$42

$42

$08

end

 

Player2color:

etc.

It appears that batari had the player#-#color: feature already coded and working, but just hadn't made a necessary tweak in the preprocessor to allow it. I've done this in my private source, and its working great!

  • Like 2

Share this post


Link to post
Share on other sites

It appears that batari had the player#-#color: feature already coded and working, but just hadn't made a necessary tweak in the preprocessor to allow it. I've done this in my private source, and its working great!

That is awesome!

I was just looking at some of my Donkey Kong code, and thought I could save a lot if I could define Kong's 2 sprite colors one time instead of two.

I am going to post the Rivet Level, (Level 4), in the batari Basic forum.

R.T. and others may be able to learn some DPC+ code, and I need to ask for help getting my player to move around.

  • Like 2

Share this post


Link to post
Share on other sites

I've gone through the code for the program I posted above and it looks like all REMs have been updated and the code is as cleaned up as I can get it. I'll put it on the bB page after I get a little sleep. I'll also add more text to the page that you guys have posted here within the past week or so.

  • Like 1

Share this post


Link to post
Share on other sites

Question #1:

 

Do any of the optimizations speed, size, noinlinedata, and inlinerand work with the DPC+ kernel? I mean, will any of them help or is it a waste of time to use any of them with this kernel?

 

 

 

Question #2:

 

I noticed that the DPC+ VbB code template includes code for bank 1:

   bank 1
   temp1 = temp1

Is that necessary for the Harmony cart or can we just ignore bank 1 code like we do in the standard kernel and have code for bank 2 through bank 6?

 

 

 

Question #3:

 

Is the DPC+ stack similar to the stack that has always been used behind the scenes when we create a program using the standard kernel? In other words, is batari Basic using any of the 256 stack locations in the DPC+ kernel or do we have it all to ourselves?

 

I'm still not sure about how I can push the value of a variable onto the stack and retrieve it by pulling it later. How can I be sure it will be the correct value and not a value from another variable?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

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

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...