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

[RevEng]

Version 18 is now in the first post.

 

Changes...

• My DPC+ pfread code had a bad bug, which is now fixed. (the test program unintentionally worked around the bug)
• COLUBK is now set to 0 prior to the DPC+ kernel running, to avoid a partial stripe of background color.
• COLUM0 is set prior to the first line pre-0 playfield line in the DPC+ kernel. If the bB program sets ENAM0 before drawscreen to enable missile display on the pre-0 line, it now displays with the correct COLUM0 color.
• multiplication by all powers-of-two uses shifting, instead of larger numbers requiring the mul8 library.

I haven't had the chance to take on any playfield offset code.

 

 

 

I was in a rush to post the new release this morning, and forgot to credit iesposta with discovering the DPC+ pfread bug. Thanks iesposta!

 

Without all of the excellent bug reports you guys submit, we wouldn't be anywhere near the current quality level. Keep it up!

[+Random Terrain]

Is it possible for you to add the ability for bB users to disable certain virtual sprites so all of their variables can be used without causing flicker or collision detection?

 

For example, if you aren't going to use player4 through player9 in your game, you could have 12 variables instead of 6 since you wouldn't have to move them below the screen. Here are a couple of examples of what it might look like:

 

const disvirtual = 4 (All virtual sprites from player4 through player9 would be disabled as sprites so they can be used as variables.)

 

const disvirtual = 6 (All virtual sprites from player6 through player9 would be disabled as sprites so they can be used as variables.)

[+Random Terrain]

If you saw this post earlier, forget what I said. The problem is that collision isn't detecting the part of player0 that is double-sized or quad-sized using player2 (and I assume it's that way up to player9). 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.

[+Random Terrain]

Post above has been updated. I misunderstood what I was seeing.

[RevEng]

Ah. batari stated that collision for virtual players didn't support NUSIZ settings yet, and there's no room for it now.

[+Random Terrain]

Ah. batari stated that collision for virtual players didn't support NUSIZ settings yet, and there's no room for it now.

 

OK, thanks.

 

On another subject, what happens to the old playfield variables when we use the DPC+ kernel? One of the best things about using Superchip RAM is getting 48 extra variables. I use bits for everything I can think of to save variables, but 26 variables just aren't enough for the kind of games I'd want to make.

[iesposta]

You will just have to figure how to reuse some variables by pushing them to the stack. There are 256 bytes of stack.

[+Random Terrain]

You will just have to figure how to reuse some variables by pushing them to the stack. There are 256 bytes of stack.

 

Byte Knight says the stack is slow:

 

 

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

[RevEng]

He's right, but slow is a relative term. If you're wanting to pull or push a-z it will take about ~419 6507 cycles for each operation, maybe a bit more. I'm still not entirely sure how the ARM overhead works out here, but I don't think it's very significant for pushing and pulling.

 

pushing or pulling a single value takes 7 6507 cycles for each operation.

 

When I get a second to try on real hardware, I'll see if I can quantify better how the ARM overhead works out.

[+Random Terrain]

While you're thinking about this stuff, does the DPC+ stuff have to fit in one bank? If it could use two banks, I could live with only having 4 banks free for my games if that would mean we could have more features.

[RevEng]

Yes, theoretically the DPC+ user functions could be spread into other banks. ARM sees it all as one space, as far as I understand.

 

But to be honest I don't think I have the time and understanding at this point to take that big a change on.

[+Random Terrain]

Yes, theoretically the DPC+ user functions could be spread into other banks. ARM sees it all as one space, as far as I understand.

 

But to be honest I don't think I have the time and understanding at this point to take that big a change on.

 

Thanks. That's good to know. When batari eventually comes back to us, maybe he'll be able to expand it to two banks.

[iesposta]

While you're thinking about this stuff, does the DPC+ stuff have to fit in one bank? If it could use two banks, I could live with only having 4 banks free for my games if that would mean we could have more features.

DPC+ kernel has bank 2, bank 3, bank 4, bank 5, and bank 6 for your programming, over 3,900 bytes.

So that 5 banks, almost 20K program space. 4K bB Kernel, 4K ARM, 4K Display Data (playfields, players) = 32K

(Everyone forgets bank 6 is program space!) The "invisible bank 7" is for Display Data where playfields and players data gets copied.

[oh, I see what you're saying. Make 2 banks for Kernel so we have more features?]

Wishlist! pfscroll; diagonal missiles and ball (with length) to use for masking; 3 channel music!!! (I would be willing to give up objects (missile 1) to have even scratchy 3 channel music!); playfield flipping. Just off the top of my head.

 

Also RevEng, any luck on "priming read"?

[+Random Terrain]

Wishlist!

 

Yeah, scrolling, ability to put playfield data starting at any row, fix virtual sprite collision problem, and so on.

[RevEng]

Also RevEng, any luck on "priming read"?

 

Truthfully I haven't had a chance to look at it yet. Maybe later this week.

 

What little free time I had last week I spent re-doing the Unix 2600basic.sh script to support bundling different OS binaries within the main bB distribution, and setting up (and documenting) the supporting stuff to cross-compile Windows, Linux, and OS X bB binaries all in one step. Thanks to Byte Knight's help with testing things out, multiple platform support should be much easier from here on out.

 

 

Is it possible for you to add the ability for bB users to disable certain virtual sprites so all of their variables can be used without causing flicker or collision detection?

I meant to answer this earlier. I don't think its going to be an easy addition, but I'll take a look. The main challenge here is that the ARM (thumb) code is just so damn expansive, especially compared to 6507 assembly.

[bogax]

 

Truthfully I haven't had a chance to look at it yet. Maybe later this week.

 

Feed me Seymour

[RevEng]

Version 20 is now in the first post.

 

The updates...

• I've added OS X binaries, and a Linux/OS X install script, and updated 2600basic.sh so it picks the right OS binaries to run. See README_UX.txt for details. Big thanks to Byte Knight for testing a bunch of things out here!
• I've added priming reads for the playfield fractional fetchers. This fixes the extra line of playfield that used to appear at the top of the screen in high resolutions.
• I indented various kernel files to make multiple levels of ifconst/ifnconst/if and endif easier to understand.

RT, I took a look at limiting the virtual sprites, and it's not going to be viable spacewise right now.

[+Random Terrain]

Oops, looks like we now have icing on the cake when doubling the column resolution number to use with DF4 (64 and 128, 32 and 64, 16 and 32, and so on). I put a yellow block under an empty block to show the green icing:

 

 

Is there a DF4 setting that will compensate perfectly for all rows? Right now I'm using 64 for DF0 - DF3 and 128 for DF4.

[RevEng]

I think the fractional fetchers used for the playfield/background colors need the same priming reads.

 

If you stick this in your project directory and rebuild, does it fix the icing?

 

[removed]

[+Random Terrain]

I think the fractional fetchers used for the playfield/background colors need the same priming reads.

 

If you stick this in your project directory and rebuild, does it fix the icing?

 

I had to put it in the includes folder for it to work, but it looks like it contaminates in reverse:

 

[RevEng]

Ugh. I guess we know why batari didn't do the priming reads in the first place.

 

I noted the double-playfield line in BUGS.txt, reverted the priming reads, and updated the first post.

[+Random Terrain]

Ugh. I guess we know why batari didn't do the priming reads in the first place.

 

I noted it in BUGS.txt, reverted the priming reads and updated the first post.

 

The thing is that your version 20 would be perfect for when the bB user wants to take advantage of the icing. We could have thin lines without needing to use higher resolutions. You'd want no icing as the default, but maybe you could include an icing on the cake DPCplus_kernel.asm that people could use if they want. Maybe you could call it icing_on_cake_DPCplus_kernel.asm or something similar. You might want to include your icing under the cake version too, for people who might want to use that.

[+Random Terrain]

In case it wasn't clear, I meant that bB users could rename the file they need to DPCplus_kernel.asm.

[iesposta]

Yea! Everything works fine so far for me in OSX.

Of course, with your script it is easier.

I am bummed the "priming read" didn't work out.

I was running DASM in Terminal to compile .asm files before.

 

About Playfields.

I can flip 2 high res playfields, but any changes with pfpixel or pfline etc. are wiped out when it loops back.

If I put the playfield: data outside the loop I can change the PF with pfpixel, pfline, etc. but I can't flip to another playfield, again it wipes all changes.

I can define two 2-line playfields in 176. Two 88 play fields, and even with inline asm flip between them, but again, when I loop back any changes are wiped.

Aren't the PF in RAM? Does it copy from ROM to RAM every time Playfield: is encountered?

This will set the 2nd half of two 88 line play fields:

 

asm

ldy #176

LDA #<(PF_data1 + 87)

LDX #((>PF_data1) & $0f) | (((>PF_data1) / 2) & $70)

sta temp7

lda #>(.ret_point1-1)

pha

lda #<(.ret_point1-1)

pha

lda #>(pfsetup-1)

pha

lda #<(pfsetup-1)

pha

lda temp7

pha

txa

pha

ldx #1

jmp BS_jsr

.ret_point1

end

Is there a way to point back and forth in the data stream without losing any pfpixel, pfline, etc. changes?

[RevEng]

Yea! Everything works fine so far for me in OSX.

Of course, with your script it is easier.

I am bummed the "priming read" didn't work out.

I was running DASM in Terminal to compile .asm files before.

Excellent. Thanks for the confirmation!

 

 

Aren't the PF in RAM? Does it copy from ROM to RAM every time Playfield: is encountered?

So far as ARM's perspective of DPC+, everything is in RAM, I think. But your playfield: data gets stored in the "code" part of memory, which pfpixel, pfline, etc. don't modify. Those commands modify the fetcher queue copy of the playfield.

 

And yes, every time playfield: is encountered, the ARM copies your playfield data into the fetcher queues.

 

 

Is there a way to point back and forth in the data stream without losing any pfpixel, pfline, etc. changes?

No.