bB with native 64k cart support - 1.1d.reveng

[RevEng]

The multi-kernel framework uses its own score_graphics file, so no.

 

The score graphics there would need its own modification to have an extra space character.

[+Random Terrain]

 

. . . we now have the ability to reduce the number of DPC+ virtual sprites, so unused vsprite memory can be reclaimed ("set dpcspritemax #", where # is a number from 1-9)

 

So, if I use "set dpcspritemax 4" that means that I can use the following 15 as variables:

 

player5x, player5y, NUSIZ5

player6x, player6y, NUSIZ6

player7x, player7y, NUSIZ7

player8x, player8y, NUSIZ8

player9x, player9y, NUSIZ9

 

Question #1: Are there any other variables that I'm forgetting?

 

Question #2: Can all of those be used with dim?

 

 

Update:

 

After RevEng's reply, I now know that using "set dpcspritemax 4" would give us 20 extra variables:

 

player5x, player5y, NUSIZ5, player5height

player6x, player6y, NUSIZ6, player6height

player7x, player7y, NUSIZ7, player7height

player8x, player8y, NUSIZ8, player8height

player9x, player9y, NUSIZ9, player9height

 

 

Using "set dpcspritemax 3" would give us 24 extra variables:

 

player4x, player4y, NUSIZ4, player4height

player5x, player5y, NUSIZ5, player5height

player6x, player6y, NUSIZ6, player6height

player7x, player7y, NUSIZ7, player7height

player8x, player8y, NUSIZ8, player8height

player9x, player9y, NUSIZ9, player9height

 

 

Using "set dpcspritemax 2" would give us 28 extra variables:

 

player3x, player3y, NUSIZ3, player3height

player4x, player4y, NUSIZ4, player4height

player5x, player5y, NUSIZ5, player5height

player6x, player6y, NUSIZ6, player6height

player7x, player7y, NUSIZ7, player7height

player8x, player8y, NUSIZ8, player8height

player9x, player9y, NUSIZ9, player9height

[RevEng]

1. player5height -> player9height

2. yes

 

[+Random Terrain]

1. player5height -> player9height

 

Thanks. My brain must not be working correctly tonight because I don't remember what player#height is or does and I can't find it on the bB page.

[+Gemintronic]

I think we all recognize your work as a gynourmously huge gift RevEng. I don't expect you to maintain squat. I just really appeciate you, jwierer and CPUWIZ teaming up to make batari BASIC continue to shine.

 

UPDATE: I would mention R.T. for maintaining the batari BASIC command reference but I depend on that so much it's just part of living and can safely be ignored.

[RevEng]

Thanks. My brain must not be working correctly tonight because I don't remember what player#height is or does and I can't find it on the bB page.

Its a variable that automatically gets set to the player's height as part of the player#: command.

 

Its handy to know about, because you can use it to make a player "melt away" (or the reverse) without changing the player#: command, just by decreasing the value.

 

 

I think we all recognize your work as a gynourmously huge gift RevEng. I don't expect you to maintain squat. I just really appeciate you, jwierer and CPUWIZ teaming up to make batari BASIC continue to shine.

Thanks man, that means a lot to me.

[+Random Terrain]

Its a variable that automatically gets set to the player's height as part of the player#: command.

 

Its handy to know about, because you can use it to make a player "melt away" (or the reverse) without changing the player#: command, just by decreasing the value.

 

Thanks. I don't think that's on the bB page yet. Looks like I need to add it. Does it only work with the DPC+ kernel?

[+Atarius Maximus]

In response to the loon's post, I second his appreciation to RevEng for his hard work on bB (and for his help with my personal projects) and to Random Terrain for maintaining bB documentation on his web page. Thanks to both of you for your hard work. I wish I had more time to be active on AA and contribute more often, my work and personal life has prevented it for most of this year. My AtariVox has been calling my name for months, I will get around to making a bB game with voice, hopefully next year.

[RevEng]

Thanks AM!

 

Thanks. I don't think that's on the bB page yet. Looks like I need to add it. Does it only work with the DPC+ kernel?

It works with the standard and multisprite kernels too.

[+Random Terrain]

It works with the standard and multisprite kernels too.

 

Thanks. Now I see them in the Memory Maps. I didn't know anything about them until now. Seems like a useful thing to know about.

[+Random Terrain]

I think we all recognize your work as a gynourmously huge gift RevEng. I don't expect you to maintain squat. I just really appreciate you, jwierer and CPUWIZ teaming up to make batari BASIC continue to shine.

 

Yeah, I couldn't do anything without batari's bB, jwierer's VbB, RevEng's bB fixes and tools, code posted by various better programmers than I am, and so on. This latest change by RevEng might give me enough variables to make a DPC+ game that I'd like to play. 20 or 24 or 28 extra variables aren't as good as having 48 extra variables, but it's a lot better than only having 26. We might have enough extra variables now to cure my DPC+ depression. I can live with 5 multicolored single-height sprites or maybe even 4 or 3 if I have to.

 

And I don't need any pats on the back for maintaining the bB page. The page is as much for me as it is for anyone else. The people who should get pats on the back are batari, SeaGtGruff, RevEng, Robert M, and anyone else who provided text and example code for the page.

[+Random Terrain]

When anyone gets a chance, please take a look at these sections and see if they need to be edited:

 

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

 

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

[RevEng]

They look good to me.

[+Random Terrain]

They look good to me.

 

OK, thanks. If you or anyone reading this notices anything I forgot to add to any other section, please let me know.

[RevEng]

Version 28 is in the first post.

 

bug-fix: Previously the "end" for inline assembly had to follow a non-empty line, or else the preparser would format bB commands following it as inline asm, screwing up the rest of the compile.

 

feature: the DPC+ pfscroll command now has 2 optional values to indicate the start and end queue to scroll...

 

pfscroll 1 : rem as before, scrolls the DPC+ playfield one line

pfscroll 1 0 1 : rem scrolls the left half of the screen one line

pfscroll 1 2 3 : rem scrolls the right half of the screen one line

pfscroll 1 0 4 : rem scrolls the playfield and PF colors one line.

pfscroll 1 4 4 : rem scrolls the PF colors one line.

 

A note on the last 2 examples. Due to the way the kernel updates PF colors, to keep colors lock-step with the PF graphics you should either set DF4FRACINC to twice the # of DF[0-3]FRACINC fetchers, or scroll the PF queues twice as much as the 4th (color) queue.

[RevEng]

RT, when you get a chance can you add one note to the DPC+ collision documentation?

 

"The DPC+ collision is pixel perfect, but doesn't take hardware-reflected sprites into account."

 

I don't think there's a lot I can do to change this situation. There isn't enough space to add code to flip the bits of any reflected vsprite prior to testing.

[RevEng]

Version 29 is in the first post. It has fixes for the following bugs...

 

bug: player0y=0 started display on the second scanline, while virtual sprites displayed on the first scanline. This skew also threw off pixel-perfect DPC+ soft collision detection.

bug: DPC+ soft collision detection had an off-by-one bug, resulting in some glancing collisions going undetected.

 

Be warned that existing DPC+ bBasic code may need to be adjusted for the new player0y range.

[+Random Terrain]

RT, when you get a chance can you add one note to the DPC+ collision documentation?

 

"The DPC+ collision is pixel perfect, but doesn't take hardware-reflected sprites into account."

 

I don't think there's a lot I can do to change this situation. There isn't enough space to add code to flip the bits of any reflected vsprite prior to testing.

 

Yep, I'll add that and I'll also see what needs to be changed based on your last two updates (within the next day or two as I let the info sink into my brain). Thanks.

[+Random Terrain]

Version 28 is in the first post.

 

bug-fix: Previously the "end" for inline assembly had to follow a non-empty line, or else the preparser would format bB commands following it as inline asm, screwing up the rest of the compile.

 

feature: the DPC+ pfscroll command now has 2 optional values to indicate the start and end queue to scroll...

 

pfscroll 1 : rem as before, scrolls the DPC+ playfield one line

pfscroll 1 0 1 : rem scrolls the left half of the screen one line

pfscroll 1 2 3 : rem scrolls the right half of the screen one line

pfscroll 1 0 4 : rem scrolls the playfield and PF colors one line.

pfscroll 1 4 4 : rem scrolls the PF colors one line.

 

A note on the last 2 examples. Due to the way the kernel updates PF colors, to keep colors lock-step with the PF graphics you should either set DF4FRACINC to twice the # of DF[0-3]FRACINC fetchers, or scroll the PF queues twice as much as the 4th (color) queue.

 

The last version of this used "pfscroll [value]" or "pfscroll [variable]". Can variables be used for the other two values? If not, can the first be a variable if two numbers follow it?

 

Speaking of the optional values, is what you posted the only values that can be used? If not, is there some way that bB users can know what they can use without needing to type in every number combination they can think of to see what is possible? Thanks.

[RevEng]

Right now variables won't work for the queue numbers, but you can still use a variable for the scrolling value, even if you add queue values.

 

The 2 numbers after the scroll value represent the start and end DPC+ queue numbers. They match the same DPC+ queue numbers used in the DF#FRACINC resolution settings.

 

i.e.

 

0=left PF data

1=middle-left PF data

2=middle-right PF data

3=right PF data

4=PF color data

 

So you just pick the things you want to scroll. Remember its a range, so using "0 2" will scroll 0,1 and 2. (3/4 of the playfield)

[RevEng]

Version 30 is in the first post.

 

DPC+ bug: I had used so much space in the first bank with recent additions, that the extra space used by the kernel option "collision(THING,THING)" could cause bad things to happen.

 

To free up space and get everything working, I've made the blank score digit space mutually exclusive with this kernel option. If you use one, you can't use the other.

 

Special thanks to Atarius Maximus for the bug report!

[iesposta]

Version 30 is in the first post.DPC+ bug: I had used so much space in the first bank with recent additions, that the extra space used by the kernel option "collision(THING,THING)" could cause bad things to happen.To free up space and get everything working, I've made the blank score digit space mutually exclusive with this kernel option. If you use one, you can't use the other.Special thanks to Atarius Maximus for the bug report!

What does kernel option "collision thing, thing" give you?

[RevEng]

It gives the Y coordinate of the first such collision. RT has it documented.

[+Random Terrain]

Right now variables won't work for the queue numbers, but you can still use a variable for the scrolling value, even if you add queue values.

 

The 2 numbers after the scroll value represent the start and end DPC+ queue numbers. They match the same DPC+ queue numbers used in the DF#FRACINC resolution settings.

 

i.e.

 

0=left PF data

1=middle-left PF data

2=middle-right PF data

3=right PF data

4=PF color data

 

So you just pick the things you want to scroll. Remember its a range, so using "0 2" will scroll 0,1 and 2. (3/4 of the playfield)

 

 

Thanks. 0 through 3 now make sense to me. I'll post some examples to help make things clearer to myself and to ask a couple of questions. In the examples below, pfcolors: data is outside of the main loop. Hold down the fire button to scroll.

 

pfscroll 1 0 0 dpcpfscroll_1_0_0.bin

 

pfscroll 1 0 1 dpcpfscroll_1_0_1.bin

 

pfscroll 1 0 2 dpcpfscroll_1_0_2.bin

 

 

I don't need an example for "pfscroll 1 0 3" since it's the same as "pfscroll 1"

 

 

pfscroll 1 3 3 dpcpfscroll_1_3_3.bin

 

pfscroll 1 2 3 dpcpfscroll_1_2_3.bin

 

pfscroll 1 1 3 dpcpfscroll_1_1_3.bin

 

 

All examples above scroll the playfield without scrolling the color.

 

 

This example scrolls the color of the playfield without scrolling the playfield itself:

 

pfscroll 1 4 4 dpcpfscroll_1_4_4.bin

 

After the colors start scrolling off the screen, the colors displayed are yellow, then black, then it's back to the colors below again:

   pfcolors:
   $0E
   $0C
   $0A
   $08
   $06
   $1E
   $1C
   $1A
   $18
   $16
   $2E
   $2C
   $2A
   $28
   $26
   $3E
   $3C
   $3A
   $38
   $36
   $4E
   $4C
   $4A
   $48
   $46
   $5E
   $5C
   $5A
   $58
   $56
   $6E
   $6C
   $6A
   $68
   $66
   $7E
   $7C
   $7A
   $78
   $76
   $9E
   $9C
   $9A
   $98
   $96
   $AE
   $AC
   $AA
   $A8
   $A6
   $BE
   $BC
   $BA
   $B8
   $B6
   $CE
   $CC
   $CA
   $C8
   $C6
   $DE
   $DC
   $DA
   $D8
   $D6
   $EE
   $EC
   $EA
   $E8
   $E6
   $3E
   $3C
   $3A
   $38
   $36
   $4E
   $4C
   $4A
   $48
   $46
   $5E
   $5C
   $5A
   $58
   $56
   $6E
   $6C
   $6A
   $68
   $66
end

Seems like you'd need to have a lot more pfcolors: data to get rid of the yellow and black.

 

The example below scrolls pfcolors: data and the playfield:

 

pfscroll 1 0 4 dpcpfscroll_1_0_4.bin

 

When the fire button is held long enough for everything to scroll back on the screen again, we lose a little color at the top of what is scrolling back in (turns black). The yellow at the bottom is just because I wasn't using enough pfcolors: data.

[+Random Terrain]

When you get a chance, see if this is OK the way it is or if it needs to be edited:

 

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