Jump to content
IGNORED

Need help compiling and updating DPC+ information


Random Terrain

Recommended Posts

RT, batari incorporated most of my score_graphics file in the 1.1# releases, so you can probably do away with the "Custom Score Fonts" link at your page, and add a regular command entry.

 

To set a custom score font in any batari kernel, just use "const font=<fontname>". The available fonts are: 21stcentury, alarmclock, handwritten, interrupted, retroputer, whimsey, and (in my latest dist) tiny.

  • Like 1
Link to comment
Share on other sites

RT, batari incorporated most of my score_graphics file in the 1.1# releases, so you can probably do away with the "Custom Score Fonts" link at your page, and add a regular command entry.

 

To set a custom score font in any batari kernel, just use "const font=<fontname>". The available fonts are: 21stcentury, alarmclock, handwritten, interrupted, retroputer, whimsey, and (in my latest dist) tiny.

 

Thanks. Deleted that and added a new section, but you won't be able to see it until I am done adding the DPC+ stuff.

  • Like 1
Link to comment
Share on other sites

The original chart from batari (and in this thread) says 176.

I, personally, leave the last line unset or black, because of that half scan line appears in the upper right.

post-29575-0-56915700-1376363713_thumb.png

 

EDIT: Not that there is anything wrong with this behavior, just depends on how OCD you are!!! :)

Link to comment
Share on other sites

The original chart from batari (and in this thread) says 176.

I, personally, leave the last line unset or black, because of that half scan line appears in the upper right.

post-29575-0-56915700-1376363713_thumb.png

 

Thanks. So, in a way, Atarius Maximus is right. Only 175 are basically useable.

Link to comment
Share on other sites

Thanks. So, in a way, Atarius Maximus is right. Only 175 are basically useable.

Yeah, I noticed exactly the same thing iesposta just posted about during my initial testing with DPC+, which is why I noted that in one of my sample programs. It's best to use no more than 175.
  • Like 1
Link to comment
Share on other sites

Data Fetcher [0-8] Fractional Increment

 

I need to know more about that 0 through 8. We have these:

 

DF0 through DF3 = 4 column stuff

 

DF4 = playfield color stuff

 

DF6 = background color stuff

 

 

That's 6 out of 8. What are the other 2?

Link to comment
Share on other sites

The very, very, very imperfect first draft is done:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpcplus

 

At least the stuff is up on the page. We can move subsections around, rename them, add text, change text or whatever needs to be done. I didn't add any of it to the table of contents yet since the order might get rearranged.

 

Please let me know if I forgot something posted in this thread and any other changes that need to be made.

  • Like 3
Link to comment
Share on other sites

Hopefully someone can contribute a soft collision function. I've tried several times in the past without feedback. Maybe someone who knows what they be do can post one.

 

It seems soft collisions are important for DPC+ and multi-sprite kernel use.

 

Here is my function example that compares missile0 to the boundaries of another sprite. You supply the x/y ranges for the sprite.

 

_function softcol_missile0

_rem x1 as missile0x, y1 as missile0y, x2 as temp1, y2 as temp2, x3 as temp3, y3 as temp4, x4 as temp5, y4 as temp6

_if missile0x > temp5 then return 0

_if temp1 < temp3 then return 0

_if missile0y > temp6 then return 0

_if temp2 < temp4 then return 0

_return 1

end

Link to comment
Share on other sites

Random Terrain,

Just looked at the DPC+ kernel data in your website.

I use the site often when programming.

 

You could add that the DPC+ kernel is like the Multi Sprite kernel, but with 10 sprites, 2 missiles and the ball.

player0 is player0, player1 through player9 all use player1 with automatic sprite flicker if players 1 thru 9 are moved to the same horizontal position, plus AND minus 6 single scan lines above and below the defined player(x): [value 6 needs verification].

Example: The bottom of player1 is six scan lines above the top of player2, they start to flicker at 30Hz (every other frame), four players would flicker at 15Hz (every 1/4 frame - Pac Man ghosts), they stop flickering when separated by 7 or more vertical scan lines.

 

Also player1 NUSIZ must have the underscore in front like the multisprite kernel: _NUSIZ1 (that is why I had trouble with player1).

The reflections of the virtual sprites is controlled by setting a bit (? In NUSIZx) sorry, can't remember ATM.

 

RevEng version adds pfread.

I believe collisions between any 2 players can be checked, as well as collisions between missiles and players. I haven't tried this yet.

It is the location of the collision of players with the Playfield that has to be figured in software with coordinate checking.

 

Please fix typos and consistency ( is it Multi Sprite or Multisprite )

  • Like 1
Link to comment
Share on other sites

You could add that the DPC+ kernel is like the Multi Sprite kernel, but with 10 sprites, 2 missiles and the ball.

player0 is player0, player1 through player9 all use player1 with automatic sprite flicker if players 1 thru 9 are moved to the same horizontal position, plus AND minus 6 single scan lines above and below the defined player(x): [value 6 needs verification].

Example: The bottom of player1 is six scan lines above the top of player2, they start to flicker at 30Hz (every other frame), four players would flicker at 15Hz (every 1/4 frame - Pac Man ghosts), they stop flickering when separated by 7 or more vertical scan lines.

 

Thanks. I'll adapt that for the page.

 

 

 

Also player1 NUSIZ must have the underscore in front like the multisprite kernel: _NUSIZ1 (that is why I had trouble with player1).

The reflections of the virtual sprites is controlled by setting a bit (? In NUSIZx) sorry, can't remember ATM.

 

Then maybe I could adapt some of the text from the multisprite kernel section like this:

 

"The virtual sprites also are given their own virtual color and NUSIZ registers. COLUP2-COLUP9 and NUSIZ2-NUSIZ9 correspond to sprites 2-9. For sprite 1, use _COLUP1 and _NUSIZ1."

 

Unless some of that is not true.

 

 

 

 

I believe collisions between any 2 players can be checked, as well as collisions between missiles and players. I haven't tried this yet.

It is the location of the collision of players with the Playfield that has to be figured in software with coordinate checking.

 

I'll make a test program tonight or tomorrow and see what I can see, then add the info to the page (unless somebody else wants to make a test program before I do).

Link to comment
Share on other sites

Definitely just 2. Virtual players get 6507 ram assigned for their positions and height, but there are no such virtual missile memory assignments.

 

Thanks.

 

I'm still working on a test program based on this, but it's taking me longer than I hoped.

Link to comment
Share on other sites

Error:

It is false that you can't use bank 6.

Bank 6 is a normal empty bank. The display data DOES NOT go in Bank 6.

Just put :

 

bank6

temp1=temp1

 

Banks 2 thru 6 are almost 4K each and available for programming.

 

Bank 1 is almost filled with bB code, there is around 100 bytes so you can do a little bit of code or variables before jumping to bank 2,

the graphics bank has 4K where your sprites and playfield data go magically. You can't access the graphics bank, but the 256 bytes extra stack function may live there.

So that is 4K bB system, 20K of basic code, 4K graphic data, and 4K arm code = 32K binary.

  • Like 1
Link to comment
Share on other sites

Error:

It is false that you can't use bank 6.

Bank 6 is a normal empty bank. The display data DOES NOT go in Bank 6.

Just put :

 

bank6

temp1=temp1

 

Banks 2 thru 6 are almost 4K each and available for programming.

 

Bank 1 is almost filled with bB code, there is around 100 bytes so you can do a little bit of code or variables before jumping to bank 2,

the graphics bank has 4K where your sprites and playfield data go magically. You can't access the graphics bank, but the 256 bytes extra stack function may live there.

So that is 4K bB system, 20K of basic code, 4K graphic data, and 4K arm code = 32K binary.

 

Thanks. I don't remember how much of ScumSoft's text that I used. I hope I don't have more incorrect stuff on the page.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Random Terrain,

ScumSoft was pretty knowledgeable about his info. on DPC+, so most of his stuff is correct.

Re: ARM code in relation to DPC+ batari Basic

Display Processor Chip (DPC) was hardware used in Pitfall II that added new functions and a new type of bank switching. The DPC spec is two 4K banks for 6507 code and 2K of Display Data to hold graphics and other info that the 6507 code access via the DPC registers.  All of it is in ROM.

A new spec was developed using ideas from the DPC chip plus additional functions. This was called DPC+.

The ARM processor code emulates the DPC+ in software. The DPC+ spec is an extension of the DPC, with six 4K banks for 6507 code and 4K of Display Data. (For performance reasons the Display Data must be in RAM. The initial state of the Display Data is in ROM and copied into RAM when the cartridge first powers up. The ROM could be considered the seventh bank for 6507 code, but the spec doesn't have a hot-spot to bank it in.)

When Batari designed his latest "batari Basic kernel" he used the power of the emulated DPC+ to allow a kernel with most all of the options from older batari Basic, without having to make compromises (like allowing changing colors would lose a missile).

By not allowing the use of PF0 (the first four pixels and the last four pixels of the playfield), the DPC+ batari Basic kernel includes multiple background colors, multiple playfield colors and sizes, 10 sprites (single line, multiple color, 1 real & 9 virtual), sprite masking off the left and right side, the ball, missile0 and missile1, missile0 color, missile1 color (when missile is not on the same horizontal as its player), etc.

The DPC+ spec allows for more than is available in batari Basic (such as 3-channel music from one of the 2 sound channels). Assembly programmers can code 3-channel music and use the ARM processor to run code outside of the Atari's 6507 processor.

  • Like 1
Link to comment
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, so they renamed it DPC+.

 

Not entirely true.

 

The Display Processor Chip (DPC) in the Pitfall II is emulated in code by the ARM processor. The emulation is not exactly the same as DPC includes functionality which was not used by Pitfall II. The unused functionality is not emulated (if nothing used a function there was no point in coding it). This header file shows all the features in the DPC.

dpc.h.zip

 

I believe the features not used in Pitfall II are DF#DATAWSWP (swap nybbles), DF#DATAWREV (reverse bits), DF#DATAWROR (rotate right), DF#DATAWROL (rotate left) and MOVAMT# (line drawing). There's 8 of each of those functions, replace # with 0-7. I'm sure Activision planned to use those features in future games, but the industry collapsed so those games never came to be.

 

 

 

In March of 2010 I did some experiments with DPC. I liked what I saw, but thought we could do better so asked if it would be possible to expand DPC:

expandedDPC.pdf

 

batari, Chris Walton and myself then hashed out what eventually became DPC+. We decided not to implement those unused DPC functions and replaced them with other features:

  • Fast Fetch mode
  • fractional datafetchers
  • custom waveforms
  • ability for 6507 code to change Display Data (via DF#PUSH and DF#WRITE)
  • call ARM subroutines

DPCplus.h.zip

 

 

We developed DPC+ first in Stella (with stephena's help), then batari wrote the DPC+ driver for Harmony/Melody.

  • Like 2
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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