Jump to content
IGNORED

A few new score kernels


batari

Recommended Posts

There have been multiple requests for alternative score kernels. Some minikernels have helped, but I think they were limited to two 2-digit scores.

 

I have learned of a few ways tweak the normal 6-digit score, but instead of keeping these to myself until the next release of bB, I thought I'd share what I have now as minikernels so you can use them now. To use them, first disable the normal score with "const noscore=1" and after the bB code and in the last bank, if applicable, place "inline scoreXX.asm" with XX being 33, 42, or 51, depending on which score configuration you wish to use.

 

Most requested is two 3-digit scores. It's not perfect, as the two scores are on the extreme left and right of the screen, and I don't think there is any other way to pull this off.

 

I've also worked up a 4+2 and 5+1 arrangement, which might be useful for game selections, level counters, etc. But unlike the 3+3 arrangement, the position of the two scores is not at the extreme left and right, due to a NUSIZ trick I learned about recently. This trick won't work on a 3+3 score.

 

With any of the score kernels, bB doesn't (yet) know that you're using them, so you don't get two separate score variables. However, it's not hard to work with what's already there. Think of the score as one homogeneous figure that happens to have more space between some digits than others.

 

For example: With any score, adding 1 to the right score is done with score=score+1. With the 3+3, 4+2 and 5+1 scores, adding 1 to the left score would be done with score=score+1000, 100, or 10 respectively. In other words, adding to the left score will not affect the right score if you place zeros were appropriate. This is also true of the right score unless you allow it to get larger than 999, 99, or 9.

 

Enjoy!

scoreformats.zip

  • Like 1
Link to comment
Share on other sites

Thanks. I'm especially happy to relearn about const noscore=1. I totally forgot about that. If you don't need the score, does using const noscore=1 provide any other benefits besides getting rid of the score? Is it better than changing the score color so it's invisible?

Link to comment
Share on other sites

Most requested is two 3-digit scores. It's not perfect, as the two scores are on the extreme left and right of the screen, and I don't think there is any other way to pull this off.

 

Not so! Refer to

showing 3-digit scores not at extreme edges. This bit of trickery from Thomas Jentzsch.
Link to comment
Share on other sites

Most requested is two 3-digit scores. It's not perfect, as the two scores are on the extreme left and right of the screen, and I don't think there is any other way to pull this off.

 

Not so! Refer to

showing 3-digit scores not at extreme edges. This bit of trickery from Thomas Jentzsch.

:-o any hints as to how that's done? I have no clue!

Link to comment
Share on other sites

Most requested is two 3-digit scores. It's not perfect, as the two scores are on the extreme left and right of the screen, and I don't think there is any other way to pull this off.

 

Not so! Refer to

showing 3-digit scores not at extreme edges. This bit of trickery from Thomas Jentzsch.

:-o any hints as to how that's done? I have no clue!

Does it have anything to do with RESPx?

 

Michael

Link to comment
Share on other sites

Most requested is two 3-digit scores. It's not perfect, as the two scores are on the extreme left and right of the screen, and I don't think there is any other way to pull this off.

 

Not so! Refer to

showing 3-digit scores not at extreme edges. This bit of trickery from Thomas Jentzsch.

:-o any hints as to how that's done? I have no clue!

Does it have anything to do with RESPx?

 

Michael

Could be a part of it, but I sense there's more to the picture than that.

Link to comment
Share on other sites

I found some demo code in [stella] and it is indeed just a matter of a STA RESPx. However, since RESPx can only position with 9-pixel granularity, it would require two sets of score graphics, one bit-shifted by a pixel. It looks like I'll be able to do this eventually. Unfortunately, Stella doesn't seem to emulate some of these RESP tricks properly right now, so I'll wait until the next version is released, which supposedly has a new TIA core.

Link to comment
Share on other sites

I found some demo code in [stella] and it is indeed just a matter of a STA RESPx. However, since RESPx can only position with 9-pixel granularity, it would require two sets of score graphics, one bit-shifted by a pixel. It looks like I'll be able to do this eventually. Unfortunately, Stella doesn't seem to emulate some of these RESP tricks properly right now, so I'll wait until the next version is released, which supposedly has a new TIA core.

 

Have you considered using a narrower font for the score? If you use a 3-pixel wide font with 1 pixel space then you can fit two digits into one 8-pixel sprite. This would give you a lot more flexibility, e.g. two six-digit scores using the wrap around trick, or three four-digit scores using 3 copies wide spacing (01..01..01), or even one 12 digit score!

 

Chris

Edited by cd-w
Link to comment
Share on other sites

Have you considered using a narrower font for the score? If you use a 3-pixel wide font with 1 pixel space then you can fit two digits into one 8-pixel sprite. This would give you a lot more flexibility, e.g. two six-digit scores using the wrap around trick, or three four-digit scores using 3 copies wide spacing (01..01..01), or even one 12 digit score!

 

Chris

Sounds great, but from a programming perspective it's not so great. You'd have to have more variables to store and point to the extra score digits, so some more bytes of precious zero-page RAM would need to be stolen from somewhere. And more to the point, there isn't enough time while drawing the score to load and combine both digits for each byte. Usually the procedure would be to preload half of the bytes and store them in RAM, then you would just barely have time to load and combine the other half of the digits during the score drawing routine, plus load and display the saved values. What it boils down to is you need (1) some extra blank lines above the score for the preloading/combining/saving, and (2) some free zero-page RAM for saving the preloaded/combined digits-- if you're preloading three bytes worth (half of the score), then you need three bytes of RAM for each scan line that you want to preload the graphics for, which would be 24 bytes of RAM if the digits are each 8 lines tall, or as few as 15 bytes of RAM if the digits are only 5 lines tall (which is the absolute shortest that numeric digits can be). However, this could probably be done as a special score minikernel that requires the Superchip option, because then the zero-page playfield RAM would be available for this.

 

Michael

Link to comment
Share on other sites

Have you considered using a narrower font for the score? If you use a 3-pixel wide font with 1 pixel space then you can fit two digits into one 8-pixel sprite. This would give you a lot more flexibility, e.g. two six-digit scores using the wrap around trick, or three four-digit scores using 3 copies wide spacing (01..01..01), or even one 12 digit score!

 

Chris

Sounds great, but from a programming perspective it's not so great. You'd have to have more variables to store and point to the extra score digits, so some more bytes of precious zero-page RAM would need to be stolen from somewhere. And more to the point, there isn't enough time while drawing the score to load and combine both digits for each byte. Usually the procedure would be to preload half of the bytes and store them in RAM, then you would just barely have time to load and combine the other half of the digits during the score drawing routine, plus load and display the saved values. What it boils down to is you need (1) some extra blank lines above the score for the preloading/combining/saving, and (2) some free zero-page RAM for saving the preloaded/combined digits-- if you're preloading three bytes worth (half of the score), then you need three bytes of RAM for each scan line that you want to preload the graphics for, which would be 24 bytes of RAM if the digits are each 8 lines tall, or as few as 15 bytes of RAM if the digits are only 5 lines tall (which is the absolute shortest that numeric digits can be). However, this could probably be done as a special score minikernel that requires the Superchip option, because then the zero-page playfield RAM would be available for this.

 

Michael

Well, you could just use a huge graphics table. If you went with, say, 5-high graphics, all 100 of them could fit in two pages. The pointer setup would require multiplying by 5, but that's not hard to do (multiply by 4 and add the original value.)

 

There is still the problem of extra RAM needed for the digits. You need 3 bytes that aren't really available. Well, I suppose one could eliminate that requirement by not storing the digits in RAM at all, and just updating the pointers directly, but I'd expect that a routine to add an arbitrary value to the score would take quite a few cycles.

Link to comment
Share on other sites

  • 3 months later...

I was poking around for a three-digit score routine for a (soon to be announced) project, and this actually works even better for my needs!

 

So, I assume it would be possible to have the two separate scores act as a "Count-up" and count-down" tally respectively? In other words, let's say you wanted to keep track of how many times the fire button was pressed. But you ALSO wanted to countdown from, say, 500 every time the button is pressed. So the 3-3 config would start out as

 

000500

 

And a press of the fire button would add 1000, and separately subtract 1, for:

 

001499

002498

003497

 

Very nice. This is gonna be perfect!

 

EDIT: Just realized a bit of an issue. I need the game to end when the right-hand side reads "000" (the countdown/move counter is empty). A countdown is usually an easy issue to check for. If it's equal to "0", you're done. But using this score counter, even if the righthand side is showing 000, the lefthand side is still counting up, ergo, it's not a variable equal to zero.

 

So, what would be a simple formula for testing whether a six-digit number's last three digits are all zero?

Edited by Snider-man
Link to comment
Share on other sites

I was poking around for a three-digit score routine for a (soon to be announced) project, and this actually works even better for my needs!

 

So, I assume it would be possible to have the two separate scores act as a "Count-up" and count-down" tally respectively? In other words, let's say you wanted to keep track of how many times the fire button was pressed. But you ALSO wanted to countdown from, say, 500 every time the button is pressed. So the 3-3 config would start out as

 

000500

 

And a press of the fire button would add 1000, and separately subtract 1, for:

 

001499

002498

003497

 

Very nice. This is gonna be perfect!

 

EDIT: Just realized a bit of an issue. I need the game to end when the right-hand side reads "000" (the countdown/move counter is empty). A countdown is usually an easy issue to check for. If it's equal to "0", you're done. But using this score counter, even if the righthand side is showing 000, the lefthand side is still counting up, ergo, it's not a variable equal to zero.

 

So, what would be a simple formula for testing whether a six-digit number's last three digits are all zero?

What you're trying to do is described in the bB manual:

. . .

If you plan to check to score, you will need to break out its 6 digits into 3 sets of two digits and check each one. One way to pull out the score digits is:

dim sc1=score

dim sc2=score+1

dim sc3=score+2

 

sc1 will contain the first two digits, sc2 the 3rd and 4th, and sc3 the last two. Since these are all BCD numbers, you need to place a "$" in front of any values you check. For example, to check if the score is less than 10:

if sc1=$00 && sc2=$00 && sc3<$10 then ...

 

To check if the score is greater than 123456:

if sc1>=$12 && sc2>=$34 && sc3>$56 then ...

 

Breaking out score digits is also useful for setting the score to display special values or custom graphics. You can modify score_graphics.asm to include definitions for digits "A-F" and set the score digits manually. How to do this is beyond the scope of this document, but it has been discussed in detail in the AtariAge 2600 Basic forum.

Link to comment
Share on other sites

What you're trying to do is described in the bB manual:
. . .

If you plan to check to score, you will need to break out its 6 digits into 3 sets of two digits and check each one. One way to pull out the score digits is:

dim sc1=score

dim sc2=score+1

dim sc3=score+2

 

sc1 will contain the first two digits, sc2 the 3rd and 4th, and sc3 the last two. Since these are all BCD numbers, you need to place a "$" in front of any values you check. For example, to check if the score is less than 10:

if sc1=$00 && sc2=$00 && sc3<$10 then ...

 

To check if the score is greater than 123456:

if sc1>=$12 && sc2>=$34 && sc3>$56 then ...

 

Breaking out score digits is also useful for setting the score to display special values or custom graphics. You can modify score_graphics.asm to include definitions for digits "A-F" and set the score digits manually. How to do this is beyond the scope of this document, but it has been discussed in detail in the AtariAge 2600 Basic forum.

Well, that certainly points me in the right direction, but I still need one blank filled. I need to check if the score is ever equal to XXX000. Well, it's seems easy enough with the info above to check the the last two digits. If sc3=$00, ta-da. But checking sc2 is going to be difficult unless I check for $10; $20; $30; $40; etc. Is that the easiest way to check that second block?

Link to comment
Share on other sites

What you're trying to do is described in the bB manual:
. . .

If you plan to check to score, you will need to break out its 6 digits into 3 sets of two digits and check each one. One way to pull out the score digits is:

dim sc1=score

dim sc2=score+1

dim sc3=score+2

 

sc1 will contain the first two digits, sc2 the 3rd and 4th, and sc3 the last two. Since these are all BCD numbers, you need to place a "$" in front of any values you check. For example, to check if the score is less than 10:

if sc1=$00 && sc2=$00 && sc3<$10 then ...

 

To check if the score is greater than 123456:

if sc1>=$12 && sc2>=$34 && sc3>$56 then ...

 

Breaking out score digits is also useful for setting the score to display special values or custom graphics. You can modify score_graphics.asm to include definitions for digits "A-F" and set the score digits manually. How to do this is beyond the scope of this document, but it has been discussed in detail in the AtariAge 2600 Basic forum.

You also need to split sc2 in half, but that's easy. One way would be to mask out the upper nybble:

  temp1=sc2 & $0F
 if temp1=0 && sc3=0 then ...

Edited by batari
Link to comment
Share on other sites

  • 10 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

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