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

[RevEng]

Don't you mean pfread?

I sure did. Edited now. Thanks!

[RevEng]

I've temporarily lost the ability to test on real hardware again. If someone can verify that this version of msdpc.bas.bin doesn't blow up on harmony and displays the same there as it does in stella, I'll have a new release ready. (DPC+ capable harmony firmware required)

 

msdpc.bas.bin

[iesposta]

That version of msdpc.bas.bin doesn't "blow up" on harmony and is the same in Stella.

Joystick 2 cycle changes the color in a line in the score. The line that is the center horizontal on the number 8. Stella and Harmony on real hardware does this also.

[RevEng]

Perfect, and thank-you! All of that is expected.

[RevEng]

Version 13 is now in the first post.

 

Added...

-DPC+ pfclear

-enabled DPC+ player#-#color:

 

Fixed...

-DPC+ virtual sprite positioning bug, where virtual sprite positioning was skipped when the top vsprite was only partially on screen.

 

ARM space is running tight, so short of a big rewrite I don't believe DPC+ pfscroll is going to happen. Maybe batari will have some miracles here when he takes it back.

[iesposta]

ARM space is running tight, so short of a big rewrite, I don't believe DPC+ pfscroll is going to happen. Maybe batari will have some miracles here when he takes it back.

Thank you!

I've notice the space in Bank 1 has shrunk from 100 bytes to 39 bytes free.

How do you get player8-9color: to work? It fails for me.

Nevermind, stupid Windows 7. Didn't change the files.

Edited August 28, 2013 by iesposta

[RevEng]

Yup, the ARM code gets stuck in that bank with the kernel.

 

I didn't do anything special...

 

   player8-9color:
   $9A
   $92
   $96
   $98
   $9C
   $96
   $9C
   $98
   $96
   $92
   $9A
end

Which environment are you working in (Windows? vbb?) and is there a partial .asm file created that you can share?

[RevEng]

Nevermind, stupid Windows 7. Didn't change the files.

Excellent that it's working now. Had me worried.

[iesposta]

Excellent that it's working now. Had me worried.

Yea, so sorry. It works great!

Now the free space in Bank 1 has gone back up! I think it was 97 or 94.

The stuff I put in bank 1 used to have 7 bytes free. Now it reports 4 bytes free.

See, you did all that in 3 bytes! Ok, I'll shut up now, I don't know what I'm taking about here.

[RevEng]

Hah, no judgments here. Just the other day I posted the titlescreen kernel instead of bB.

 

I managed to squeeze the arm code a bit by using a later version of gcc with additional arm optimizations, otherwise I wouldn't have gotten pfclear to fit. So in reality it was a bit more than 3 bytes.

[+Random Terrain]

Is it my imagination or is pfclear with DPC+ faster than pfclear with the standard kernel?

[iesposta]

RT, where is your code for your "spaceship test?"

 

Maybe pfclear it is faster because the playfield in DPC+ is in RAM?

 

RevEng,

I recompiled my "Food Fight" and when the player0 goes to the top, it disappears and doesn't scroll off, and also it corrupts the first playfield PF1 or PF2, I don't know which one is first (upper left)

[RevEng]

DPC+ pfclear is faster than regular pfclear because the ARM CPU is faster than a 6507 at clearing it's memory.

 

Thanks for the bug report, iesposta. Its on my list now.

[+Random Terrain]

RT, where is your code for your "spaceship test?"

 

I was waiting until I was done adding more text that you guys posted, but I just uploaded it anyway since you asked for it:

 

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

[RevEng]

Version 14 is now in the first post.

 

I know I'm risking everybody getting update fatigue with all of these back to back releases, but I think we'll be relatively bug-free very soon. This version allows for DPC+ player0 to nicely wrap the top of the screen, at a cost of 14 bytes from the first bank.

[+Random Terrain]

Version 14 is now in the first post.

 

I know I'm risking everybody getting update fatigue with all of these back to back releases, but I think we'll be relatively bug-free very soon. This version allows for DPC+ player0 to nicely wrap the top of the screen, at a cost of 14 bytes from the first bank.

 

I don't care if you post a new version every 12 hours, as long as it means we're getting closer and closer to perfection. Thanks.

 

And if you have to use even more space to fix the sprite weirdness, that's fine with me too. All I need is enough space to have a goto jump to bank 2.

[+Random Terrain]

Just in case, I won't put any code in bank 1 in any example programs that I make. Then if most of the space we have right now in bank 1 ends up getting used for improvements, I won't have to go back and edit every program.

[RevEng]

Thanks, and yes, keeping bank 1 free except for the goto is the wisest course for compatibility with future versions.

 

The sprite weirdness glitch is still on my to-do list. I just need to go a bit deeper down the rabbit hole for that one.

 

 

[iesposta]

Player moves off the top just great!

 

I think I see something else.

You can turn on P0's columns. They used to just extend the playfield colors out to the edges. You can't set its pixels.

PF0 = $FF would turn all 4 colums on the left and all 4 columns on the right 'on'.

Now there is some alignment problem.

[RevEng]

Ok, thanks for the bug report!

[RevEng]

iesposta, I've been looking a bit deeper into the PF0 color change alignment issue, and it looks the the color change happen there because it's normally not visible and there isn't anywhere else it can fit in. Its actually been the case since batari released 1.1d.

 

Is it possible you could use bkcolors: instead of pfcolors: for your screen above? Or was it just illustrative?

[iesposta]

Just illustrative.

I guess that function is most useful when you have the playfield defined as black and you use changing background colors then you can turn PF zero on to mask the playfield colors on the left and the right.

 

The food fight demo as first written had colored background and a playfield that was all black that I could erase sections to make the background color show through like the yellow pits and the black masking on the left and right was PF0.

I've always thought about rewriting it so the background is black and playfield pixels would have the color. That's why I saw the single-line I had across the top was stretched out strangely on the left side and right side.

 

I was remembering when I threw that Satan's hollow together I tried to mask the left and the right side of the screen black but they came up as bands of color as defined in the playfield. I just assumed they lined up.

 

Thanks again for all your work on this I'm always happy with any addition I wish batari can take it Over at some time because when it was released bugs got squashed and features were added quite quickly.

[iesposta]

You don't have to do any more work and I would perfectly happy with the way it is now!

[+Random Terrain]

-Added the "dec" command. dec is a variation of "let" that adds and subtracts values in decimal mode. e.g "dec player0score=player0score-1". Other math operations aren't valid in decimal mode.

 

So that wouldn't be "dec player0score = player0score - $01"?

 

 

 

 

I'd say its pretty useful. It was previously possible to hit the separate score bytes, but the two methods were a bit cumbersome. You could wrap the arithmetic with assembly "sed" and "cld" commands like I did a few posts back, or you could use large numbers in your arithmetic to bypass earlier score digits. e.g score=score+100 would add 1 to the middle score digit.

 

Having the dec command keeps the source compact and means you can use it in the middle of a long if...then. Avoiding the "large number" method means you don't need to worry about the score byte overflowing into the higher score digit.

 

The converse of that is, if you do use dec, the score digit will roll over once it goes past 99, or roll back if it goes under 0.

 

The one thing to keep in mind is you need to use BCD numbers when you're adding or subtracting. So to add 13 to a score digit, you'd actually add $13.

 

 

The only other new things were 64k support and DPC+ pfpixel pfread support. The majority of the rest of changes have been bugfixes, in addition to some behind the scenes stuff like the -v version switch and the rarely triggered bankswitch hotspot warning.

 

 

So instead of this:

__

   asm
   sed ; set decimal mode
end

   a = a + $05

   asm
   cld ; clear decimal mode
end

   score = score + a

__

__

We'd use this instead?

__

   dec a = a + $05
   score = score + a

[RevEng]

My example works since hex and decimal are equivalent from 0 to 9, but your form is better for an example.

 

[edit - and yes, your dec example is equivalent to the version with inline asm.]