Jump to content

Photo

Need help compiling and updating DPC+ information


119 replies to this topic

#51 SpiceWare ONLINE  

SpiceWare

    Quadrunner

  • 11,493 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Thu Aug 22, 2013 7:47 PM

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.
  • DPC - used to run Pitfall II
  • 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, Thu Aug 22, 2013 8:02 PM.


#52 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,362 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Thu Aug 22, 2013 8:24 PM

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.

#53 SpiceWare ONLINE  

SpiceWare

    Quadrunner

  • 11,493 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Thu Aug 22, 2013 9:07 PM

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, Thu Aug 22, 2013 9:08 PM.


#54 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Aug 22, 2013 9:15 PM

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.

#55 SpiceWare ONLINE  

SpiceWare

    Quadrunner

  • 11,493 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Fri Aug 23, 2013 5:19 PM

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, Fri Aug 23, 2013 5:40 PM.


#56 CPUWIZ OFFLINE  

CPUWIZ

    Commander

  • 32,452 posts
  • Cartridge Recycler
  • Location:SoCal

Posted Fri Aug 23, 2013 5:23 PM

DPC = David Patrick Crane and not Display Processor Chip. :P

#57 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,362 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Fri Aug 23, 2013 5:51 PM

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.

#58 SpiceWare ONLINE  

SpiceWare

    Quadrunner

  • 11,493 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Fri Aug 23, 2013 5:51 PM

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, Fri Aug 23, 2013 5:57 PM.


#59 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Aug 23, 2013 6:15 PM

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.

#60 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Aug 24, 2013 10:24 AM

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



#61 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sat Aug 24, 2013 1:19 PM

Did you set COLUM0=<x> ?

#62 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Aug 24, 2013 1:22 PM

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.



#63 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sat Aug 24, 2013 1:44 PM

Can you PM me the test?

#64 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Aug 24, 2013 2:07 PM

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.

 

Attached File  ex_dpc_test_2013y_08m_24d_1603t.bin   32KB   136 downloads

 

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.



#65 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sat Aug 24, 2013 2:31 PM

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.

#66 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,362 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sat Aug 24, 2013 3:12 PM

 
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!

#67 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Aug 24, 2013 7:35 PM

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

 

Attached File  ex_dpc_test_2013y_08m_24d_2120t.bas.bin   32KB   138 downloads

 

Here's a video that shows the problem:

 

youtube.com/watch?v=HhK03uEwgwk



#68 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sat Aug 24, 2013 7:55 PM

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.

#69 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,362 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sat Aug 24, 2013 8:14 PM

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.

#70 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Aug 24, 2013 8:51 PM

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.



#71 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sat Aug 24, 2013 9:24 PM

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.

#72 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Mon Aug 26, 2013 6:49 PM

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!

#73 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,362 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Mon Aug 26, 2013 7:08 PM

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.

#74 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Aug 26, 2013 7:27 PM

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.



#75 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Aug 28, 2013 1:08 AM

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?






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users