Jump to content
Random Terrain

Need help compiling and updating DPC+ information

Recommended Posts

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

 

Thanks. I better add that to the bB page.

Share this post


Link to post
Share on other sites

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

 

post-13-0-54850800-1379443165_thumb.png

 

Is there any way to fix that?

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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"
  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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.

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