Need help compiling and updating DPC+ information

[+Random Terrain]

No. DPC+ has an arm based 32-bit LFSR for random numbers.

 

Thanks. I better add that to the bB page.

[+Random Terrain]

At a y position of zero, the missiles and sprites are a little lower than the top of the playfield:

 

 

Is there any way to fix that?

[RevEng]

Yeah, a few of the elements are delayed by a scanline, namely P0, M0, M1. I don't think that's going away without some other equally odd delay taking its place.

 

Currently you can set ENAM0 and ENAM1 before your drawscreen and the missiles will start enabled. They won't be the right color at the top line though - for that you'll need to wait for the next release, which won't be too long.

[+Random Terrain]

The stack is useless to me at this time since I don't know how to use it. Are there any bB variables that the DPC+ kernel doesn't use that we can use as variables?

 

There could be an additional way to get variables. Say I only use 4 virtual sprites in a game, I could use player5x, player6x, player7x, player8x, and player9x as variables as long as player5y, player6y, player7y, player8y, and player9y are set to something like 200 to avoid any trouble with collision detection.

[RevEng]

I'm still planning get around to some more stack examples, but even the example of how to push and pull 1 variable is enough to get started.

 

There aren't additional unused variables; you just get a-z. And as you observed, you can steal the NUSIZ and X variables for any unused virtual players.

[Byte Knight]

The stack is useless to me at this time since I don't know how to use it. Are there any bB variables that the DPC+ kernel doesn't use that we can use as variables?

 

The stack isn't that complicated, but it uses a lot of cycles. It's best utilized between levels or room changes. I used the stack in EMR II to store and retrieve the y position of items with room changes. You can check it out in the code that's posted here, although there's no rem statements...

 

 

There could be an additional way to get variables. Say I only use 4 virtual sprites in a game, I could use player5x, player6x, player7x, player8x, and player9x as variables as long as player5y, player6y, player7y, player8y, and player9y are set to something like 200 to avoid any trouble with collision detection.

 

Yes, this works and setting the corresponding player1-9y value to 200 will avoid flicker of the on-screen virtual sprites as well.

[+Random Terrain]

Here's something I didn't realize. Since we have to use collision(player0,player1) for all virtual sprites, if I use a virtual sprite as the ball and another virtual sprite as a bonus item in a Breakout rip-off and they would happen to be at the same y position when only one of them touches the paddle (player0), the program wouldn't know which item was touching the paddle if I only check y. I'll have to know how wide the paddle is and check x and y to avoid any problems.

[iesposta]

Collision(player0,AnyVirtualPlayer) works just fine for me.

[+Random Terrain]

Collision(player0,AnyVirtualPlayer) works just fine for me.

 

Forget what I posted here earlier if you saw it before I edited this post. The problem is that collision isn't detecting the part of player0 that is double-sized or quad-sized. Using collision(player0,player1) works on all parts of a stretched player0, but collision(player0,player2) only works on the first left 8 bits of a stretched player0.

[RevEng]

RT, this bit of your Playfield Resolution (DPC+) docs can now be dropped...

• Although you can have 176 single scanline rows, part of the bottom scanline will appear in the upper right side of the screen, so it's best to leave it unset or the color of the background.

...the bug that caused it was fixed a release or two back.

[+Random Terrain]

RT, this bit of your Playfield Resolution (DPC+) docs can now be dropped...

• Although you can have 176 single scanline rows, part of the bottom scanline will appear in the upper right side of the screen, so it's best to leave it unset or the color of the background.

...the bug that caused it was fixed a release or two back.

 

 

Thanks. I'll fix it tomorrow. If you see anything else that needs to be changed, please let me know.

[RevEng]

Will do.

[RevEng]

I took a look over all of the DPC+ info, and it's good. Just this small typo...

• Nine of the six sprites are subject to certain limitations, however.

...obviously it should read "Nine of the ten"

[+Random Terrain]

I took a look over all of the DPC+ info, and it's good. Just this small typo...

• Nine of the six sprites are subject to certain limitations, however.

...obviously it should read "Nine of the ten"

 

 

Thanks. I just fixed it.

[RevEng]

Byte Knight found a limitation of the DPC+ kernel that should probably be documented...

 

The missile bit of the kernel is actually 2 lines in resolution. If you set missile height to 1, it doesn't show up, depending on if it's on an even or odd row.

[iesposta]

Byte Knight found a limitation of the DPC+ kernel that should probably be documented...

 

The missile bit of the kernel is actually 2 lines in resolution. If you set missile height to 1, it doesn't show up, depending on if it's on an even or odd row.

That explains why my Missile stick (vertical) and vertical Ball do not exactly line up!

[+Random Terrain]

Byte Knight found a limitation of the DPC+ kernel that should probably be documented...

 

The missile bit of the kernel is actually 2 lines in resolution. If you set missile height to 1, it doesn't show up, depending on if it's on an even or odd row.

 

Thanks. I noticed that DPC+ missile height didn't work the same as the standard kernel when I made the example program below, but I thought it was a known difference in kernels:

 

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

[iesposta]

Random Terrain,

I just wanted to repeat this info, I don't know if you have it on your site or not.

 

The older DPC+ template is wrong. Put temp1=temp1 in Bank 6. It is a whole bank, and not reserved for anything. (ScumSoft had his info wrong about that bank.)

The next bank (after bank six) is used for graphics and sprites and colors. Those definitions and data for players, playfields and colors get copied to that bank.

In other words, the Playfield defined in bank 2 and Playfield colors defined in bank 2 and sprites defined in bank 2 don't use any bank 2 space, they use space after bank 6.

 

So your batari Basic DPC+ rom gets compiled to:

Bank 1: batari Basic code (a few free bytes)

Bank 2-6: Your game code

Bank 7: Graphics bank (no user control)

Bank 8: ARM code (no user control)

Each bank is 4K

8 Banks times 4K equals your 32K binary!

[+Random Terrain]

Random Terrain,

I just wanted to repeat this info, I don't know if you have it on your site or not.

 

I think it is:

 

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

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_harmony

[iesposta]

Thank you for being both random AND accurate!

[ScumSoft]

On 11/12/2013 at 6:41 PM, iesposta said:

Random Terrain,

I just wanted to repeat this info, I don't know if you have it on your site or not.

 

The older DPC+ template is wrong. Put temp1=temp1 in Bank 6. It is a whole bank, and not reserved for anything. (ScumSoft had his info wrong about that bank.)

The next bank (after bank six) is used for graphics and sprites and colors. Those definitions and data for players, playfields and colors get copied to that bank.

In other words, the Playfield defined in bank 2 and Playfield colors defined in bank 2 and sprites defined in bank 2 don't use any bank 2 space, they use space after bank 6.

 

So your batari Basic DPC+ rom gets compiled to:

Bank 1: batari Basic code (a few free bytes)

Bank 2-6: Your game code

Bank 7: Graphics bank (no user control)

Bank 8: ARM code (no user control)

Each bank is 4K

8 Banks times 4K equals your 32K binary!

I would have responded earlier but Hiatus ect...

See Batari's original comment here of Bank 6
We were indexing the banks from 0 in ASM back then, and Batari Basic indexed them from 1.  It became worse as I did lots of ASM work back then and my Bank6 was purely for graphic content...

Sorry for the confusion, the template is for sure wrong and Bank 6 in bB is free for normal usage in ASM however, Bank 6 is your bB Bank 7 and only for DPC+ prefetching usage.

 

I hope this massive bump doesn't bother anyone, I feel bad for causing so much confusion with that template.

Poor iesposta had to keep correcting it all over the place.