Getting started with the DPC+ Kernel

[+Atarius Maximus]

I've been playing around with DPC the last day or so just to see what I could figure out. Many thanks to Byte Knight (for EMR II) and iesposta (Food Fight) for their code samples, that's been very helpful. I've read lots of random forum posts about how to use it which have helped quite a bit, but it's really shown me how completely dependent I am on Random Terrain's website for bB info. Not having a source for documentation makes this much harder!

 

I plan on testing as much as time allows and sharing what I can about what I've been able to figure out. I will share more details once I've actually figured out what I'm doing. It's already late now (and I need to get to bed), so I'm not going to get into great detail now about what I've learned today, but I thought I'd post what I've worked on in the last 24 hours. I made a quick "space shooter" type demo game today and it's all about learning the new kernel. I'm not neccessarily looking to finish this up as a real game. I just want to learn the ins and outs of what's new and I had to start somewhere.

 

In this playable demo, you can move your ship and shoot the seven enemies that scroll back and forth above you. They'll disappear when you shoot them and you'll be awarded points. When you've shot them all nothing happens, I was trying to test collision detection. It partially works. The sprites disappear when you shoot them, but when you keep shooting at the blank screen points are still awarded for hitting the invisible sprites... not sure why at this point. I blanked out the sprites and changed their color to black when they're hit, but it doesn't seem to work like I thought it would. Any thoughts or comments from those more experienced than me with DPC would be appreciated.

 

More to come in the future, but I'd appreciate feedback from those who have used this kernel more than me. Thanks!

 

EDIT: I just attached the most recent bB DPC build with all the recent fixes by bB and RevEng (BB_dpc.zip - 3/17/2013) It includes the fix for the color problem on COLUM0 as mentioned in post #10 of this thread. For a quick review about the differences in the DPC kernel vs. the standard & multisprite kernels, see post #9.

dpcgame.txt

dpcgame.bin

BB_dpc_03.17.13.zip

[Cybearg]

Apparently it doesn't have a per-pixel hit detection on those sprites, hence them still being hit even when blanked out.

 

Personally, when I'm not using a sprite, I always move it to 0,0 to make sure it's out of the way.

[+Atarius Maximus]

Apparently it doesn't have a per-pixel hit detection on those sprites, hence them still being hit even when blanked out.

 

Personally, when I'm not using a sprite, I always move it to 0,0 to make sure it's out of the way.

Thanks. That makes perfect sense and I've done that before, it just didn't seem so obvious at nearly midnight last night.

[iesposta]

I think 0,0 is still onscreen unlike before.

I heard it is best to make y value below the bottom of the screen.

[iesposta]

Also it is false that you can't use 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.

[+Gemintronic]

I heard there is some extra EEPROM space on Melody boards that assembly DPC+ programs can access. If so, I wonder if our assembly familiar members could make a function to access that similar to DATA statements. That kind of storage could make Ultima possible on the 2600.

 

Of course, I could be dreaming this. I forgot what topic mentioned this capability..

[RevEng]

I heard there is some extra EEPROM space on Melody boards that assembly DPC+ programs can access. If so, I wonder if our assembly familiar members could make a function to access that similar to DATA statements. That kind of storage could make Ultima possible on the 2600.

 

Of course, I could be dreaming this. I forgot what topic mentioned this capability..

 

ARM assembly and integration into the existing bB DPC+ code would be required. Also, batari never published what kind of eeprom or what kind of interface (I2C, SPI, ?) or what pins are involved.

 

None of this is impossible to overcome, but its enough of a pain that it makes sense to let batari lead on it.

[+Gemintronic]

ARM assembly and integration into the existing bB DPC+ code would be required. Also, batari never published what kind of eeprom or what kind of interface (I2C, SPI, ?).

 

None of this makes it impossible to overcome, but its enough of a pain that it makes sense to let batari lead on it.

I'm ready for him to take the lead! Where's the line? I'll even buy Army boots and a uniform!

[+Atarius Maximus]

Here's a quick bulleted list of things I've read about DPC in various posts. I thought this might be useful to someone just getting started with it. Let me know if there's any errors and I'll edit them.

 

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

[+Atarius Maximus]

Just another demo that shows using missiles. I have missile 0 full height on the left side and missile 1 full height on the right side. Both are set to the color red with COLUM0=66 and COLUM1=66. You can see that missile 0 will take on the color of player 0 on it's scanlines (the sprite at the very top of the screen in this demo) and missile 1 will take on the colors of all the virtual sprites on their scanlines (all the other sprites on the screen). Interestingly, after you shoot the player0 sprite, missile 0 turns completely black and disappears.

 

In this version, I was able to fix the problem of shooting blank/zeroed out sprites (and still hitting them) by simply placing them off-screen.

dpcgame2.txt

dpcgame2.txt.bin

[iesposta]

I've noticed that the missile default color works as expected for COLUM1 and COLUM0 on the scanlines that come AFTER their respective sprites.  But for COLUM0, the colors will default to 0 (black) on non-player0 scanlines that come before it.  I've included a small program to demonstrate this (move joystick up and down to change the vertical position of the sprites.

 

DPCMissileColor.bas.bin

 

Edit: I so totally plagiarized the above.

Edited March 3, 2013 by iesposta

[Cybearg]

More to come in the future, but I'd appreciate feedback from those who have used this kernel more than me. Thanks!

 

 

I finally tried out the DPC Game demo you posted in the Getting Started with DPC+ thread. I hadn't really had the chance to until now.

 

I saved the .txt file as a .bas file, saved, and compiled, but it doesn't work for me. I just get an error:

 

 

[3/3/2013 2:56:22 PM] bblint found the following errors in dpcgame.bas

warning(): Found 29 commands that use end, and 31 "end" commands.

DASM V2.20.07, Macro Assembler ©1988-2003

free ram: 7

$1ae1

bytes of ROM space left in bank 1

--> HMdiv 1a41

bytes of ROM space left in bank 2

bytes of ROM space left in bank 3

bytes of ROM space left in bank 4

bytes of ROM space left in bank 5

bytes of ROM space left in bank 6

$d1a0

bytes of ROM space left in graphics bank

free ram: 7

2199 bytes of ROM space left in bank 2

3923 bytes of ROM space left in bank 3

3923 bytes of ROM space left in bank 4

3923 bytes of ROM space left in bank 5

3923 bytes of ROM space left in bank 6

$d1a0

3206 bytes of ROM space left in graphics bank

free ram: 7

2199 bytes of ROM space left in bank 2

3923 bytes of ROM space left in bank 3

3923 bytes of ROM space left in bank 4

3923 bytes of ROM space left in bank 5

3923 bytes of ROM space left in bank 6

$d1a0

3206 bytes of ROM space left in graphics bank

--- Unresolved Symbol List

 

Fatal assembly error: Source is not resolvable.

Errors were encountered during assembly.

 

Same goes for dpcgame2, except I get the additional error:

 

 

--- Unresolved Symbol List

COLUM0 0000 ???? (R )

COLUM1 0000 ???? (R )

 

Fatal assembly error: Source is not resolvable.

Errors were encountered during assembly.

 

Anyone know what's wrong? I'm using bB 1.1d with VisualbB 1.0 (build 565) and DASM 2.20.07 (the 2003 version that comes with bB).

 

NOTE: I also get the error with an absolutely-basic DPC+ game (attached) with basically nothing in it.

DPCbase.bas

Edited March 3, 2013 by Cybearg

[+Atarius Maximus]

I'm not sure what's causing your compliation errors. I've attached a zipped up copy of the bB folder I've been using for the couple of DPC demos I've shared. I believe there was a patch I applied. Try it out, it should work for you.

BB_dpc.zip

[Cybearg]

That works for me now. Thanks so much, Atarius!

[Cybearg]

Is there any way to have sprites drawn at double height in DPC so that they won't have to all be remade with double the lines? Since all pixels are the same width, that double resolution doesn't necessarily add the potential for significantly more detail, so it'd be nice if I could save half of the bytes and just have the pixels rendered square.

 

Also, is there a way to specify a single color for a whole sprite anymore, or are multi-line definitions required? Ditto for score colors.

Edited March 4, 2013 by Cybearg

[+Atarius Maximus]

I'm not an expert at DPC, but as far as I know sprites are drawn only at single pixel height in DPC. I'm also not sure about defining sprite colors, if defining only one line of color of with "playerXcolor:" doesn't work then I suspect there's no way to do it.

 

EDIT: Of course, you could always define the sprite with the same color on every line if you want a single colored sprite, same for score colors...

[+Gemintronic]

Faking single color and double height sprites completely defeats the purpose of DPC+ In some of the examples right here in this topic I see graphics comparable to 7800.

 

But, I've little grounds to talk. My next Sega Genesis game'll be text graphic based

[+Atarius Maximus]

Faking single color and double height sprites completely defeats the purpose of DPC+ In some of the examples right here in this topic I see graphics comparable to 7800.

 

But, I've little grounds to talk. My next Sega Genesis game'll be text graphic based

It's off topic for this post, but you're making a Genesis game? Very cool. Link please?

[Cybearg]

I'm trying out my first DPC+ game and I found a rather large problem: as soon as the game starts, it overcycles, leading to rolling for the entire game.

 

This puzzled me,because I first built the game (or what exists of it so far) in the standard kernel and it worked fine without rolling. Then I went into Stella and tested the game line by line immediately after a reset. Sure enough, the first frame (and only the first) overcycled.

 

So I put a drawscreen immediately after the kernel options, and I was STILL hitting 270 scanlines for the first frame and a solid 262 after that.

 

...Does this mean that DPC+ is broken for real 2600 hardware? I have attached the absolute minimum required to get the DPC+ to work and, if you go into Stella, hit reset, and watch the scanlines in the console, you'll see that it overcycles. So is DPC+ isn't any good on a real system?

DPCbase.bas

DPCbase.bas.bin

[iesposta]

Drawscreen takes data from the graphics bank. ("bank 7" and you can't put the titlescreen there by the way)

You haven't set up any players and/or background colour and/or playfield pixel data for it to draw.

You can make a program without the background and without the playfield, or just players and the background, etc., but I think you would have to define something for the screen before calling drawscreen.

 

Note: Playfield, players and/or background color can be coded in any bank (bank 2-6, probably no room left in bank1) and the data is stored in the graphics bank "bank 7". Again, it does not use space in the banks you code them in.

[iesposta]

Here is a mockup of Satan's Hollow I did over the last few days.

Edit: I wish it was this aspect ratio! It really is wider than it is tall. Something is off with the screenshot function.

 

I wanted to try a trick to see if I could get the flying in a circle without flicker, 2 wide copies, and it works. It is just using player0 and player1, 2, & 3. Player1 & player2 stay far enough away from each other that they don't flicker. Player3 is just sitting there. God is player9, fire pit is quad size player8. The bridge sections are playfield holes showing a white background.

The next hard part will be bullets since there are 2 wide copies, there are 2 wide missiles.

Updates further down this thread.

Edited March 6, 2013 by iesposta

[Cybearg]

Drawscreen takes data from the graphics bank. ("bank 7" and you can't put the titlescreen there by the way)

You haven't set up any players and/or background colour and/or playfield pixel data for it to draw.

You can make a program without the background and without the playfield, or just players and the background, etc., but I think you would have to define something for the screen before calling drawscreen.

 

Note: Playfield, players and/or background color can be coded in any bank (bank 2-6, probably no room left in bank1) and the data is stored in the graphics bank "bank 7". Again, it does not use space in the banks you code them in.

 

When you say that the data is stored in bank 7, you mean that it's automatically placed there in the assembly (which is why it comes at the end of the .asm file), correct? Because I actually define the graphics in bank6 because I can't make gosub calls to bank7 or it doesn't work.

 

But my big question is: why is the game overcycling on the first frame? It happens both in the game I'd worked on (which does have graphics) and on the above bare-bones sample.

Edited March 5, 2013 by Cybearg

[+Atarius Maximus]

I adapted SeaGtGruff's old "move around rooms" demo (originally from here: http://www.atariage.com/forums/topic/95820-adventure-type-game/?do=findComment&comment=1162741) to DPC+. I thought this could be useful to someone. It's basically a bare bones adventure demo. You can move around to all the different rooms in the game world but there isn't anything to do.

move.bin

move.txt

[+Gemintronic]

Speaking of SeaGtGruff, he was talking about adapting his wonderful pfhscroll routine to DPC+. If it could be done then horizontal scrolling would be jawsomeley possible in full DPC+ glory!! Space shooters.. side scrolling platformers.. *drool*

[Cybearg]

I adapted SeaGtGruff's old "move around rooms" demo (originally from here: http://www.atariage....e/#entry1162741) to DPC+. I thought this could be useful to someone. It's basically a bare bones adventure demo. You can move around to all the different rooms in the game world but there isn't anything to do.

 

Great demo! But it also demonstrates what I was talking about. If you add:

 

if switchreset then reboot

 

... right after the main loop and then check the scanlines immediately after rebooting, it overcycles.

 

I also tried putting it on my Harmony and testing it on a 2600 and the move demo isn't even viewable--it's just a garbled, shaking mess of white and grey.

 

Have there been any confirmed cases of DPC+ working on real 2600 hardware?