Jump to content
IGNORED

score question


atari2600land

Recommended Posts

If I make an 8k game, it garbles up the score instead of using the .asm file I made specifically for the game. The asm file has two extra characters. Am I doing something wrong here? (more info in my GoSub blog)

I haven't checked your program yet, but the bankswitching routines go near the top of the banks, and the score characters also go near the top of the last bank, so if you use a custom score file that has extra extra characters in it, you'll probably need to adjust the ORG/RORG addresses.

 

Michael

Link to comment
Share on other sites

I haven't checked your program yet, but the bankswitching routines go near the top of the banks, and the score characters also go near the top of the last bank, so if you use a custom score file that has extra extra characters in it, you'll probably need to adjust the ORG/RORG addresses.

So what does that mean? I put the extra characters in the game itself and not the asm file, or I can only change the score in the last bank? How would I go about adjusting the ORG/RORG adresses. (Also, what are ORG/RORG addresses?) Here's the ASM file in txt (you can change the type of file it is using notepad.)

score_graphicsgosub.txt

Link to comment
Share on other sites

I haven't checked your program yet, but the bankswitching routines go near the top of the banks, and the score characters also go near the top of the last bank, so if you use a custom score file that has extra extra characters in it, you'll probably need to adjust the ORG/RORG addresses.

So what does that mean? I put the extra characters in the game itself and not the asm file, or I can only change the score in the last bank? How would I go about adjusting the ORG/RORG adresses. (Also, what are ORG/RORG addresses?) Here's the ASM file in txt (you can change the type of file it is using notepad.)

You were close; it looks like you had changed some of the addresses correctly, but not all of them. Your custom file has two extra characters in it, which are 16 bytes (8 bytes per character). So the correct custom addresses, the standard addresses, and the addresses you were using, are as follows:

 

  ifconst ROM2k
 ORG $F79C; standard is $F7AC; you had $F7A4 (off by 8 bytes)
  else
 ifconst bankswitch
   if bankswitch == 8
	 ORG $2F94-bscode_length; standard is $2FA4; you had $2FA4 (off by 16 bytes)
	 RORG $FF94-bscode_length; standard is $FFA4; you had $FFA4 (off by 16 bytes)
   endif
   if bankswitch == 16
	 ORG $4F94-bscode_length; standard is $4FA4; you had $4F94 (correct!)
	 RORG $FF94-bscode_length; standard is $FFA4; you had $FF94 (correct!)
   endif
   if bankswitch == 32
	 ORG $8F94-bscode_length; standard is $8FA4; you had $8F94 (correct!)
	 RORG $FF94-bscode_length; standard is $FFA4; you had $FF94 (correct!)
   endif
 else
   ORG $FF9C; standard is $FFAC; you had $FF9C (correct!)
 endif
  endif

ORG and RORG addresses tell the DASM compiler where to put the machine code when it's compiling your (or bB's) assembly code. "ORG" is (I think) short for "origin," or the starting address, so it tells the compiler that the code that follows (up to the next "ORG" statement, if there are any more "ORG" statements) will start at that address in memory. "RORG" is basically the same as "ORG," but with a very important difference-- the "R" stands for "relocate," so it tells the compiler that even though the following code will *physically* start at the "ORG" address, the compiler should pretend that it starts at the "RORG" address. For example, suppose you have the following code in your program:

 

  ORG $1000
  RORG $F000

program_start

 ; bunch of code follows

When DASM compiles your program, the code which follows the "program_start" label will actually begin at address $1000, but the compiler will pretend that the "program_start" label is pointing to address $F000, so it will use $F000 in the program whenever it sees you refer to "program_start"-- e.g., when you do "JMP program_start" or "BEQ program_start." Generally speaking, the only time you need to use "RORG" when writing an assembly program for the 2600 is if you're using some kind of bankswitching, because it lets you compile your program so that it ends up being 8K, or 16K, or 32K, etc., but each bank will end up starting at address $F000-- i.e., in the cart's memory, each bank will come one after the other, but when they get loaded (or switched) into the 2600's memory space, they will be correctly positioned at $F000.

 

So try compiling with the following corrected file, and the score should come out okay.

 

Michael

score_graphicsgosub.txt

Link to comment
Share on other sites

Sorry, but it's still being stubborn. Do I change the values at the end? They're still the standard. I had the score characters working fine when it was 4K. I'd send a pic, but I bet you have both my .bas and .asm file.

No, you don't need to change the addresses at the end, just the ones that come before the data for the characters. And yes, I have both the BAS and ASM files. How are you compiling it-- with the standard bB 0.99c (i.e., version 0.99b with the patch), or are you using a customized version that I'd posted to the forum for the Superchip and "user score" modifications? I'm using just the standard 0.99c version (I had to restore them back over my customizations, because they were causing me problems whenever I tried to compile other people's bB programs).

 

Another thought-- if you're using a custom score file with a different name than the standard name, then you need to modify the default.inc and/or the bankswitch.inc file(s) to use the custom name. Did you do that? Since it seems to work okay in 4K, then I guess you did change the default.inc file to use your new score file. But if you want to use your new score file in an 8K (bankswitched) game, then you need to change the bankswitch.inc file as well, because bB uses the bankswitch.inc file instead of the default.inc file when you compile a bankswitched bB game. When I make that change and compile with bB 0.99c, the score looks okay, so try that and see if it fixes it for you.

 

Michael

Link to comment
Share on other sites

Another score question. Decided not to start a new thread because it is a question related to the score. I can't seem to find the proper way to get $B1 back to $B0 and j back to 0 once the selectswitch has been pressed twice. The line in question is line 47. How in the heck do I do this?

gosub120506b.bas

Link to comment
Share on other sites

Another score question. Decided not to start a new thread because it is a question related to the score. I can't seem to find the proper way to get $B1 back to $B0 and j back to 0 once the selectswitch has been pressed twice. The line in question is line 47. How in the heck do I do this?

The problem is, j will never get to be greater than 1, since you're increasing it only when select is pressed *and* j is 0. So take out the part about "and j is 0," and it will work the way you want:

 

  rem 47 if switchselect && j=0 then j=j+1 : byte3=byte3+1
47 if switchselect then j=j+1 : byte3=byte3+1
  if j>1 then byte3=$B0 : j=0

However, this raises another issue, which is that you'll probably want to use some kind of "debounce" routine. In other words, it may take only a fraction of a second for you to press select, but that's a very long time to the Atari, and even though you're checking the select switch only once per frame, that's a mere 60th of a second, and it takes longer than that for your finger to push the select switch down and then let it back up, so the Atari will keep performing the select switch logic during every frame for as long as it thinks you're pressing the select switch. This makes it turn into something of a crap shoot as to whether the Atari will stop with j set to 0 or 1. What you need to do is add some sort of "debounce" logic, which basically tells the Atari to ignore the select switch (or whatever else it is that you're "debouncing") for a certain period of time after it's first pressed. Here's an example of how you might program the debounce:

 

  dim select_debounce=f

  rem more code here...

47 if !switchselect then select_debounce=0 else gosub check_select_debounce
  if select_debounce>0 then select_debounce=select_debounce-1
  if j>1 then byte3=$B0 : j=0

  rem more code here...

check_select_debounce
  if select_debounce=0 then select_debounce=30 : j=j+1 : byte3=byte3+1
  return

What this will do is set the select_debounce variable to 0 when select is *not* pressed, otherwise it will go to the check_select_debounce subroutine. That subroutine will check if the select_debounce is currently equal to 0, and if it is, the subroutine will set the select_debounce variable to a number that determines how long (measured in frames, or 60ths of a second) that you want to wait before letting the select switch "repeat" itself, and then it will perform whatever actions you want to have happen when the user presses the select switch. After that, the subroutine returns to where you called it from, and the next thing the program does is decrement the select_debounce variable if it's greater than 0. Thus, your program will effectively ignore the select switch unless the select_debounce is 0 (meaning it hasn't been pressed yet), and will let the select switch repeat itself (if the user keeps it held down) once every half of a second (every 30 frames, or 30/60ths of a second), but as soon as the user lets go of the select switch the select_debounce will be reset to 0. So you can press it over and over again as fast as you want, and the program will respond each time, but if you keep it held down it will repeat at a slower speed to keep it from accidentally repeating itself too quickly. Try it and see-- hold it down and watch how slowly j changes from 0 to 1 to 0 to 1, and then press select rapidly and watch j change each time. By changing the value that you set select_debounce to, you can control the speed at which the select switch will repeat itself (e.g., try changing the 30 to a 60 and see what happens, then change it to a 15 and see what happens).

 

Michael

gosub120506b.bas

Link to comment
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.
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...