DPC+ Questions

[MissCommand]

Hey guys

 

I think I have been playing enough on DPC+ now to (hopefully) ask some questions that are not too obvious... heh heh

 

1) Do all bin's have to be 32K when say, I am only using two banks? Whenever I try to set the kernel to something else it doesn't compile.

 

2) Do all 10 of my sprites now have to be multi-color? COLUP[n] registers are not read? Is there any easy way of setting a sprite that is all the same color instead of adding the playcolor block of all the same value to each line of the sprite?

 

3) Kind of related to the above, the score is ONLY multi-colored? (I do like the faded look though).

 

4) When using pfscore, the last blocks of pfscore1 are lopped off... am I doing something wrong? There seems to be enough space before the score starts.

 

I am running into all sorts of questions while programming, can I use the thread to ask questions as I go along?

Edited July 13, 2017 by MissCommand

[MissCommand]

Sorry, this should be posted to Batari Basic forum... but I do not know how to move it!

[+Atarius Maximus]

Hey guys

 

I think I have been playing enough on DPC+ now to (hopefully) ask some questions that are not too obvious... heh heh

 

1) Do all bin's have to be 32K when say, I am only using two banks? Whenever I try to set the kernel to something else it doesn't compile.

 

2) Do all 10 of my sprites now have to be multi-color? COLUP[n] registers are not read? Is there any easy way of setting a sprite that is all the same color instead of adding the playcolor block of all the same value to each line of the sprite?

 

3) Kind of related to the above, the score is ONLY multi-colored? (I do like the faded look though).

 

4) When using pfscore, the last blocks of pfscore1 are lopped off... am I doing something wrong? There seems to be enough space before the score starts.

 

I am running into all sorts of questions while programming, can I use the thread to ask questions as I go along?

 

It's been a while since I've worked with bB, but I'll try and help a little bit. Anyone who knows better please correct me if I'm wrong.

 

1) Do all bin's have to be 32K when say, I am only using two banks? Whenever I try to set the kernel to something else it doesn't compile.

 

Yes, all are 32K.

 

2) Do all 10 of my sprites now have to be multi-color? COLUP[n] registers are not read? Is there any easy way of setting a sprite that is all the same color instead of adding the playcolor block of all the same value to each line of the sprite?

 

Sprites do not have to be multi-color. If I remember correctly, I always just set each line of color to the same value.

 

3) Kind of related to the above, the score is ONLY multi-colored? (I do like the faded look though).

 

You are not required to make the score multi-colored.

 

4) When using pfscore, the last blocks of pfscore1 are lopped off... am I doing something wrong? There seems to be enough space before the score starts.

 

A code example would help assist you with this.

 

I am running into all sorts of questions while programming, can I use the thread to ask questions as I go along?

 

Yes.

 

Here are a few notes I took about DPC back when I first tried to use it in 2013. Search the forums and download other people's code, looking at samples will probably help answer many of your questions. I also recommend reading Random Terrain's excellent documentation on his website here: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html.

 

The DPC+ kernel is hardware assisted and only works with melody/harmony cartridges.

 

There is support for pfpixel, pfvline and pfhline, but no playfield scrolling and no pfclear.

 

a-z are the only variables available, however:

 

You can "push" variables to the stack and reuse them, then "pull" them back off.

There are 256 bytes in it that can be used in a program. I don't have any examples of how to do this.

 

player1 only wraps because values larger than 165 cannot be supported, so to prevent crashes, DPC+ wraps automatically. It is up to the programmer to wrap player0, and the missiles and ball.

 

To fix issues with the harmony cart, put temp1=temp1 right after each bank declaration

 

vblank needs to go in bank 1

 

Collisions: The virtual sprites are all player1 so you can't use collision() to detect collisions between them, and when a virtual sprite collides with the playfield you won't know exactly which one did it without coordinate checking.

 

Each sprite allows its REFPx and NUSIZx to be set independently

 

I couldn't get player1 to reflect, but player2 thru player9 reflect with their NUSIZx

Example: reflect player 3

NUSIZ3{3} = 1

The 3 in curly brackets is bit 3.

 

Also, bits 6 and 7 control smooth entry, I think it is called masking, of a player {bit 7} to the screen from the left or right side {bit 6} but was never shown in an example.

 

It is a subtle effect, but useful if you don't want a player sprite wrapping from the left/right sides of the screen. (On both sides of the screen at the same time.)

You want the sprite to move off screen to the left without it sliding in on the right.

Bit 7 of NUSIZx turns the masking on: NUSIZ2{7} = 1

Bit 6 of NUSIZx sets Left or Right masking (L/R): NUSIZ2{6} = 0 will let the sprite disappear off the left side of the screen.

Once it is moved off screen you should set its location, because if you keep subtracting its position it will appear on the right side and continue right to left.

NUSIZ2{6} = 1 will let the sprite disappear off the right side of the screen.

 

If you want to disable a sprite, do not set its Y value to zero but to around 200 so it is off-screen. Zero won't work right as it is on-screen.

 

Using 'set kernel_options collision(player1,playfield)' will return the y-coordinate where the first such collision occurs, so you can later figure out what sprite it was. Value is returned in temp4 after a drawscreen. The 1.1d version of the DPCplus_kernel has a timing error if you don't use this option, always include it for now.

 

Put this at the beginning of your code:

set kernel DPC+

Games must start in bank 2. Put a "goto" statement in bank 1 to a label in bank 2.

 

Sets Playfield Resolution:

Horizontal resolution is 32 across, Vertical can be set up to 255. DF commands must be placed in the main loop before/with the drawscreen.

DF0FRACINC=<x>
DF1FRACINC=<x>
DF2FRACINC=<x>
DF3FRACINC=<x>

Here is a chart of working vertical resolutions. A "*" in the resolution column means that the bottom row isn't full height.

The original chart from batari is here: http://www.atariage....00#entry2253460

Lines Res DF(0-3) DF4
1 176 255 -
2 88 128 255
3 59 * 86 -
4 44 64 128
5 36 * 52 -
6 30 * 43 86
7 26 * 37 -
8 22 32 64
9 20 * 29 -
10 18 * 26 52
11 16 24 -
12 15 * 22 44
13 14 * 20 -
14 13 * 19 38
15 12 * 18 -
16 11 16 32
18 10 * 15 30
19 10 * 14 -
20 9 * 13 26
22 8 12 24
24 8 * 11 22
26 7 * 10 20
29 7 * 9 -
32 6 * 8 16
37 5 * 7 -
44 4 6 12
52 4 * 5 10
64 3 * 4 8
86 3 * 3 6
128 2 * 2 4
176 1 1 or 0 1 or 0

Assymetrical Playfield color:

DF4FRACINC Changes the asymetrical playfield color. You would think you could set a color for each scan line, but the playfield blocks only change every other line, so you only need half the data.

DF4FRACINC = 255

DF6FRACINC Will let you pick a color for each scan line on the background.

DF6FRACINC = 0
bkcolors:
$45
end

The above code will make the background all red.

 

Setting DF6FRACINC to 0 will give you one background color, setting DF4FRACINC to 0 will give you one playfield color. DF commands must be placed in the main loop before/with the drawscreen.

 

Sets Scorecolors (multi-line):

scorecolors:
<x>
end

Missiles:

Each missile must share its color with its player on every scanline. This is a hardware limitation. If a missile is on a scanline where its player is not present, you can control the color.

Sets Missile Colors:

COLUM1=<x>
COLUM0=<x>

Sets Heights for missiles and ball (You must set these before they appear):

missile0height=<x>
missile1height=<x>
ballheight=<x>

Sets Background Color (multi-line):

bkcolors:
<x>
end

Sets Playfield Color (multi-line):

pfcolors:
<x>
end

Sets Player Colors (players 0-9, multi-line):

player0color:
<x>
end

Set Playfield (no pfclear):

Playfield:
................................
end

[MissCommand]

Hi and thanks for the response!

 

I do have some comments for your observations... and it could be updates to DPC+ since you last used it.

 

 

There is support for pfpixel, pfvline and pfhline, but no playfield scrolling and no pfclear.

 

Pfclear does work and there is downward vertical scrolling (I use both in mine)... but it is just limited to that one type for scrolling.

a-z are the only variables available, however:

 

There are a few more to be used with caution var and temp mentioned on RandTerr excellent website (which I have read twice through and I use for constant reference).

Each sprite allows its REFPx and NUSIZx to be set independently
I couldn't get player1 to reflect, but player2 thru player9 reflect with their NUSIZx
Example: reflect player 3
NUSIZ3{3} = 1

 

You will have to use _NUSIZ for player1. They use the underscore only for player1 as the other sprites are copies of player1 and don't have their own registers so _NUSIZ1 and NUSIZ2-9 are provided by DPC+.

[+SpiceWare]

a-z are the only variables available, however:

 

You can "push" variables to the stack and reuse them, then "pull" them back off.

There are 256 bytes in it that can be used in a program. I don't have any examples of how to do this.

Its possible to bypass the stack and use a few functions to set/get values directly to/from Display Data RAM to keep track of hundreds of extra values. Check this topic for more info.