Jump to content
RevEng

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

Recommended Posts

I put it on the SD card and loaded it that way.

 

I just did that and the playfield is also bouncing up and down for me (the score is steady). Is there a reason why I can't download it to the Harmony cart?

Share this post


Link to post
Share on other sites

Thanks guys. Is this one any better for the bouncing?

 

dpcpfread2.bas.bin

 

I'm not sure why the harmony direct load isn't working RT... maybe there's a bug in the loader. Even if it failed, I'd expect garbage rather than the last thing you loaded.

Share this post


Link to post
Share on other sites
I'm not sure why the harmony direct load isn't working RT... maybe there's a bug in the loader. Even if it failed, I'd expect garbage rather than the last thing you loaded.

 

There seems to be a problem with the latest version of the Harmony Programming Tool when it comes to downloading DPC+ programs. stephena is going to track down the problem.

Share this post


Link to post
Share on other sites

Thanks guys. Is this one any better for the bouncing?

 

Nope. Still bouncing. Is it my imagination or is the score smaller this time?

Share this post


Link to post
Share on other sites
There seems to be a problem with the latest version of the Harmony Programming Tool when it comes to downloading DPC+ programs. stephena is going to track down the problem.

 

If there is a problem with the programming tool, I can't find it. When it comes down to it, the programming tool is a very simple app. It simply appends the required ARM data to the binary (so the cart knows how to process the ROM), and then downloads it.

 

In the case of DPC+, FA2, etc (ie, ROMs that already have the ARM code in the binary), it simply downloads the ROM as-is. So I can't see why it wouldn't work. The download is completing (correctly, or so it would seem), and not giving any error messages.

 

I know that 32KB F4 ROMs are working, so it's not an issue of 32KB files not working, just the DPC+ and FA2 variety.

Share this post


Link to post
Share on other sites

Nope. Still bouncing. Is it my imagination or is the score smaller this time?

 

The tiny score font was part of another thing I was doing in the meantime, so ignore that.

 

Looks like I have a bit more work to do. Thanks for the help guys!

Share this post


Link to post
Share on other sites

Confirmed that there's a problem saving 32KB DPC+ and FA2 ROMs in single-ROM mode using Harmony Programming Tool. The commandline tools for saving those ROMs do work, so I know the ROMs are fine; it seems to be the programmer itself. I'll look into it over the next week, but progress will be slow, since my system is at home.

 

EDIT: I found the issue; I was forgetting to actually fill a buffer with ROM data when using DPC+ or Custom mode :dunce: There are a few other things I'd like to add, and then I'll do a new release by the end of next week.

  • Like 4

Share this post


Link to post
Share on other sites

Thanks stephena!

 

In other news, I cobbled together a working setup and discovered I just made the silly mistake of not putting the DF#FRACINC variables in the main loop. With that fixed up it runs just the same in Harmony as it does in Stella.

 

dpcpfread.bas.bin

 

I've attached version 9 of the dist (with DPC+ pfread compatibility and a reinstated "tiny" score font for iesposta) to the first post.

  • Like 1

Share this post


Link to post
Share on other sites

Harmony Programming Tool v1.3 is now released, as explained in further detail here. It fixes the issue with DPC+ ROMs in single-cart mode.

  • Like 2

Share this post


Link to post
Share on other sites

It looks like player1color: isn't allowed in if statements, which is causing the problem. If you move those into their own lines and conditionally skip them with if...then...goto it compiles fine.

 

This appears to be a limitation bug in all bB versions.

Share this post


Link to post
Share on other sites

I dug deeper, and found out there was a missing check for player1color: in the routine responsible for determining if the next word following if...then is a statement or a label. I've added this check in, and plim45.bas now compiles correctly without changes.

 

Version 11 with this fix is now in the first post.

  • Like 1

Share this post


Link to post
Share on other sites

I think I found another bug. it has to do with the player0score and player1score kernel by Curtis. Whenever it gets to adding or subtracting a playerscore, instead it just goes to the beginning. So you don't have to dig around for it, I've added the kernel files in a zip file.

playerscores.zip

plim46.bas

Share this post


Link to post
Share on other sites

bB function calls and Curtis' bcd_math.asm aren't bankswitch aware. So if you use them you need to stick the function call and the function in the same bank. Right now the functions in your bB code are jumping to the right rom address in the wrong bank.

 

An easy work around is to skip Curtis' bcd_math.asm and just use a wee bit of inline assembly to do the same thing...

 

rem we can replace "player0score=subbcd(player0score,1)" with the following...

 asm
 sed ; set decimal mode
end

 player0score=player0score-1

 asm
 cld ;clear decimal mode
end

Share this post


Link to post
Share on other sites

bB function calls and Curtis' bcd_math.asm aren't bankswitch aware. So if you use them you need to stick the function call and the function in the same bank. Right now the functions in your bB code are jumping to the right rom address in the wrong bank.

 

An easy work around is to skip Curtis' bcd_math.asm and just use a wee bit of inline assembly to do the same thing...

 

rem we can replace "player0score=subbcd(player0score,1)" with the following...

asm
sed ; set decimal mode
end

player0score=player0score-1

asm
cld ;clear decimal mode
end

 

I was going to add a link to your post on the bB page, but I already link to a similar post:

 

atariage.com/forums/topic/197486-solved-player-scores-minikernel-multi-bank-broken/#entry2516283

 

Should I keep linking to that or should I change it to your post above?

Share this post


Link to post
Share on other sites

Version 12 is now in the first post.

 

Fixed...

-The COLUM0 color bug. The missile should now be correctly colored above and below player0.

-Using PAL mode and no_blank_lines now produces the correct # of scan lines

 

Added...

-In the standard kernel "const scorefade=1" will enable the score fade effect. This adds shading to the score, or if you keep incrementing the scorecolor variable it will do the typical Atari color bar effect. score fade isn't available if you're using pfscore bars.

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

  • Like 2

Share this post


Link to post
Share on other sites

I ran across a show-stopper bug and corrected the zip in the first post. If you were that one brave soul that downloaded a copy, you should re-download it. Sorry for the hassle.

Share this post


Link to post
Share on other sites

Version 12 is now in the first post.

 

Fixed...

-The COLUM0 color bug. The missile should now be correctly colored above and below player0.

-Using PAL mode and no_blank_lines now produces the correct # of scan lines

 

Added...

-In the standard kernel "const scorefade=1" will enable the score fade effect. This adds shading to the score, or if you keep incrementing the scorecolor variable it will do the typical Atari color bar effect. score fade isn't available if you're using pfscore bars.

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

 

I think the dec command may be a HUGE win for debugging. If I understand this correctly dec would let us add or subtract values and get a sane result in the on-screen score.

Share this post


Link to post
Share on other sites

Added...

-In the standard kernel "const scorefade=1" will enable the score fade effect. This adds shading to the score, or if you keep incrementing the scorecolor variable it will do the typical Atari color bar effect. score fade isn't available if you're using pfscore bars.

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

 

After I change the bB page to say that they should download this version of bB, I should add that info to the bB page. Are there any other changes that I need to add to the page?

Share this post


Link to post
Share on other sites

I think the dec command may be a HUGE win for debugging. If I understand this correctly dec would let us add or subtract values and get a sane result in the on-screen score.

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

 

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.

 

 

After I change the bB page to say that they should download this version of bB, I should add that info to the bB page. Are there any other changes that I need to add to the page?

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

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