Modifying Score Display?

[Cybearg]

The only files I changed were scoregraphics.asm and DPCplus_kernel.asm

Yeah, I really have no idea why it's on the fritz for me. I'm more suspicious of vbB itself, since it has shared computer-wide configurations regardless of where it's being run from.

[Omegamatrix]

Did you use the configuration wizard when switching stuff before? I also find restarting the computer never hurts.

 

 

At this point I suggest building a new project (and my new DPCplus_kernel.asm file). Start with basically nothing and just try to get the score to have more digits. Then keep slowly adding in stuff until it breaks.

[Cybearg]

Did you use the configuration wizard when switching stuff before? I also find restarting the computer never hurts.

I was under the impression that was the only way to do it. And yes, I've done the computer restarting thing, though it doesn't really make much sense to me. What about bB would cause lingering changes that could be cleared by restarting your computer?

 

At this point I suggest building a new project (and my new DPCplus_kernel.asm file). Start with basically nothing and just try to get the score to have more digits. Then keep slowly adding in stuff until it breaks.

Alright. I made a new project and thought I'd start with as basic as I could get:

 

 set romsize 4k
 set tv ntsc
  scorecolor = $0E

main
 drawscreen

 goto main

This won't compile. Don't know how to really step back from there.

segment: fffc vs current org: 10004

2869 bytes of ROM space left

 

B:\vBTest\New Project\default.bas.asm (1952): error: Origin Reverse-indexed.

 

Errors were encountered during assembly.

However, this will compile:

 set kernel DPC+
 const splitscore_2_4 = 0
 
 dim splitKernelVar = z
 const SPLIT_KERN_BIT = BIT_7
 
 goto main bank2
 
 bank 2
 
main
 scorecolors:
 $40
 $42
 $44
 $46
 $48
 $4A
 $4C
 $4E
end
 
 drawscreen
 
 goto main

It works with additional scores right up until this point:

    .byte $00 ; |        | $FF70
     .byte $7E ; | XXXXXX | $FF71
     .byte $60 ; | XX     | $FF72
     .byte $60 ; | XX     | $FF73
     .byte $7C ; | XXXXX  | $FF74
     .byte $60 ; | XX     | $FF75
     .byte $60 ; | XX     | $FF76
;     .byte $7E ; | XXXXXX | $FF77

;     .byte $00 ; |        | $FF78
;     .byte $60 ; | XX     | $FF79
;     .byte $60 ; | XX     | $FF7A
;     .byte $60 ; | XX     | $FF7B
;     .byte $7C ; | XXXXX  | $FF7C
;     .byte $60 ; | XX     | $FF7D
;     .byte $60 ; | XX     | $FF7E
;     .byte $7E ; | XXXXXX | $FF7F

Any additional bytes cause it to crash during compilation. It only allows 7 out of 8 bytes of E. If I uncomment one more byte, I get:

 

 

segment: 1fd4 eqm vs current org: 1fd5

free ram: 0

DPC free RAM= 603

-1 bytes of ROM space left in bank 1

B:\vBTest\New Project\default.bas.asm (1453): error: Origin Reverse-indexed.

Errors were encountered during assembly.

So at least I'm running out of ROM here before trouble arises. That doesn't really tell me much about why I get problems at other times, though.

Edited October 24, 2014 by Cybearg

[Omegamatrix]

Alright. I made a new project and thought I'd start with as basic as I could get:

 set romsize 4k
 set tv ntsc
  scorecolor = $0E

main
 drawscreen

 goto main

This won't compile. Don't know how to really step back from there.

segment:  fffc                    vs current org: 10004
      2869 bytes of ROM space left
 
B:\vBTest\New Project\default.bas.asm (1952): error: Origin Reverse-indexed.
 
Errors were encountered during assembly.

 

I meant start a new DPC+ project and start building it up to do what you want it to do, until it breaks.

 

 

But in the above output it is telling you why it breaks. The origin is reversed. If you look in the .lst file you will find this:

   1654  f467							; feel free to modify the score graphics - just keep each digit 8 high
   1655  f467							; and keep the conditional compilation stuff intact
   1656  f467				  -	      ifconst	ROM2k
   1657  f467				  -	      ORG	$F7AC-8
   1658  f467					      else
   1659  f467				  -	      ifconst	bankswitch
   1660  f467				  -	      if	bankswitch == 8
   1661  f467				  -	      ORG	$2F94-bscode_length
   1662  f467				  -	      RORG	$FF94-bscode_length
   1663  f467				  -	      endif
   1664  f467				  -	      if	bankswitch == 16
   1665  f467				  -	      ORG	$4F94-bscode_length
   1666  f467				  -	      RORG	$FF94-bscode_length
   1667  f467				  -	      endif
   1668  f467				  -	      if	bankswitch == 32
   1669  f467				  -	      ORG	$8F94-bscode_length
   1670  f467				  -	      RORG	$FF94-bscode_length
   1671  f467				  -	      endif
   1672  f467				  -	      if	bankswitch == 64
   1673  f467				  -	      ORG	$10F80-bscode_length
   1674  f467				  -	      RORG	$1FF80-bscode_length
   1675  f467				  -	      endif
   1676  f467					      else
   1677  ff9c					      ORG	$FF9C
   1678  ff9c					      endif
   1679  ff9c					      endif

As you can see you've set the romsize to 4K, so none of those statements are compiled (remember you can tell that by the "-" to the left of it, and the the current byte index is $F467, which will only increase if new bytes are added or an ORG is used). It's actually the "else" case at the bottom setting the origin to $FF9C. The idea of this particular origin is to push the score graphics to the end of the rom (as far as possible) to give the user as much free bytes as possible for their game program. In this case you can see you have bytes from $FF67 to $FF9B free to use. But at this point you are still using the particular scoregraphics.asm I gave you with some extra digits in it, so it will never fit with that origin. In fact to fix that you have to adjust the ORG $FF9C. If you wanted to add one digit (8 bytes tall) then:

 

ORG $FF9C - 8

 

or two digits:

 

ORG $FF9C - 16

 

or three:

 

ORG $FF9C - 24

 

 

And so on. Of course I'm not sure why you are trying to do this with a 4K rom in the first place. Your old projects of course won't compile with that scoregraphics.asm, as they probably don't have any bytes to spare. Now you're probably wondering why it says you have 2869 bytes free. This is the bytes free between $F467 and $FF9C, which you can see in the list file.

 

$F467 = 62567 (decimal), $FF9C = 65436 (decimal), and 65436 - 62567 = 2869 bytes free. These bytes occur before scoregraphics.asm, and not after. That's why we are subtracting the bytes we need from that origin. That origin statement is also found in scoregraphics.asm, so go there to change it if you ever need to do so for your projects.

 

 

 

However, this will compile:

set kernel DPC+

const splitscore_2_4 = 0

 

dim splitKernelVar = z

const SPLIT_KERN_BIT = BIT_7

 

goto main bank2

 

bank 2

 

main

scorecolors:

$40

$42

$44

$46

$48

$4A

$4C

$4E

end

 

drawscreen

 

goto main

It works with additional scores right up until this point:

.byte $00 ; | | $FF70

.byte $7E ; | XXXXXX | $FF71

.byte $60 ; | XX | $FF72

.byte $60 ; | XX | $FF73

.byte $7C ; | XXXXX | $FF74

.byte $60 ; | XX | $FF75

.byte $60 ; | XX | $FF76

; .byte $7E ; | XXXXXX | $FF77

 

; .byte $00 ; | | $FF78

; .byte $60 ; | XX | $FF79

; .byte $60 ; | XX | $FF7A

; .byte $60 ; | XX | $FF7B

; .byte $7C ; | XXXXX | $FF7C

; .byte $60 ; | XX | $FF7D

; .byte $60 ; | XX | $FF7E

; .byte $7E ; | XXXXXX | $FF7F

Any additional bytes cause it to crash during compilation. It only allows 7 out of 8 bytes of E. If I uncomment one more byte, I get:

 

segment: 1fd4 eqm vs current org: 1fd5

free ram: 0

DPC free RAM= 603

-1 bytes of ROM space left in bank 1

 

B:\vBTest\New Project\default.bas.asm (1453): error: Origin Reverse-indexed.

 

Errors were encountered during assembly.

 

So at least I'm running out of ROM here before trouble arises. That doesn't really tell me much about why I get problems at other times, though.

 

This also makes sense because you have too many bytes. Really though you don't need more than the "A" and "B". Unlike the other rom size options the DPC+ kernel doesn't use an ORG statement before the score graphics, so you can keep adding graphics provided you have the bytes. You don't need all the way up to "E", just add "A" and "B" and start building you code little bit by little bit to see if it works.

[Omegamatrix]

Any luck with this?

[Cybearg]

Any luck with this?

Sorry, I'll give it a try in a few days. I've been a bit occupied lately.

 

Also, since what I've got is working and fiddling with all this stuff is frustrating (because the line between "works" and "doesn't work" seems entirely arbitrary), I'm not overly inclined to keep messing with it.

 

I'll give it a try again in a few days. I just don't understand why this would reveal anything different. Either it's something wrong with my version of bB (which makes no sense to my mind) or it's a ROM boundary issue, unless there's some other probable cause that's not been mentioned, I'd say we have it narrowed down.

Edited October 27, 2014 by Cybearg

[Omegamatrix]

I just don't understand why this would reveal anything different.

We don't know exactly what is breaking, but building up your DPC+ rom with little bits of code should tell us where it starts going south.

 

 

Split score is working, and I believe something small would be stopping 2 more digits being used.

 

 

Before I forget to mention, a DPC+ game is 32K (32,768 bytes). If you are getting a black screen check the rom size first.

[Cybearg]

Found the problem.

 

If I have

   set kernel_options collision(playfield,player1)

... Things won't work. If I remove it, having only 2 extra score digits is perfectly fine.

 

Isn't that kernel option required to avoid some bug or something, though?

[iesposta]

Re: ^Above question.

There was a bug in one of the official versions whereby it would mess up the screen if it wasn't used. That was fixed.

 

But if you want the first Y coordinate of a specific collision, you still use that kernel option.

[Cybearg]

Hmm... Well, the ability to know the y-coordinate of a collision would be very convenient, though I can maybe make do without.

 

Any idea why that kernel setting would be the cause of this issue?

[+Random Terrain]

There was a bug in one of the official versions whereby it would mess up the screen if it wasn't used. That was fixed.

 

But if you want the first Y coordinate of a specific collision, you still use that kernel option.

 

I wasn't sure, but I checked and that info is in the DPC+ collision detection section:

 

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

 

Is the NUSIZ0 problem mentioned in that section still true?

[RevEng]

Is the NUSIZ0 problem mentioned in that section still true?

Yeah, its still an issue. We just don't have the free bytes left to enhance the soft-collision to support NUSIZ variations.

[+Gemintronic]

Not perfect but I'll take it. On the Sega Genesis side I can either detect that a collision happened (period) or resort to soft collision for potentially over 80 sprites. Ick.

[Cybearg]

Any insight on why setting kernel_options collision(player1,playfield) causes trouble with scores greater than 10 digits?

Edited November 1, 2014 by Cybearg

[iesposta]

Any insight on why setting kernel_options collision(player1,playfield) causes trouble with scores greater than 10 digits?

I, myself, couldn't say why that happens.

I've seen other strange things.

I have a subroutine that sets player0 colors and data. That is all it does. There is one spot where if I put a gosub to that it crashes real hardware. I have to duplicate the code in just that one spot. The other gosubs in the same bank work just fine.

[Omegamatrix]

I have a few ideas. I did notice that when you enable that settings DPC_kernel_options starts getting compiled in and code is a little shifted. I'm taking a look but first I'm cleaning up the DPC+ source code as I can't follow it. The spacing is not consistent. So I'm cleaning it up and freeing cycles as I go. Then I will set up the compile options so that the number of bytes is always even whether it's compiled in or not. Next I double check the cycles, and make sure the page branching is all good.

 

After that if the game is still malfunctioning it might be in the DPC+ code.

[Cybearg]

I have a few ideas. I did notice that when you enable that settings DPC_kernel_options starts getting compiled in and code is a little shifted. I'm taking a look but first I'm cleaning up the DPC+ source code as I can't follow it. The spacing is not consistent. So I'm cleaning it up and freeing cycles as I go. Then I will set up the compile options so that the number of bytes is always even whether it's compiled in or not. Next I double check the cycles, and make sure the page branching is all good.

 

After that if the game is still malfunctioning it might be in the DPC+ code.

Even if you can't find a solution to this bug, I hope you release that cleaned up DPC+! Every spare cycle/byte counts!

[Omegamatrix]

Even if you can't find a solution to this bug, I hope you release that cleaned up DPC+! Every spare cycle/byte counts!

Yes, I will. First I must kill this bug.

 

 

I've identified the area where the bug is occurring. Actually I'm talking about the bug with this test rom here:

 

frozen.bin

 

 

In Stella 4.1.1 it is frozen. I can't test it on real hardware until late tonight or tomorrow as the TV is being used right now. If someone else can then please report your results. It does however to appear to be a legitimate problem though, and I will attempt to explain my understanding of it below. Basically it looks like a fast fetch register is getting tripped when it shouldn't, and the game takes a dive...

 

 

You can follow the code is executing, and it reaches here:

    590  1aa5            ae 84 02         ldx   INTIM ; 68 timed for 192 lines
    591  1aa8            f0 60            beq   exitkernel  ; 70/71

.

.

At this point FASTFETCH mode is on. When the branch does get taken it is a forward branch crossing a page boundary. Cycle by cycle, this is what is happening:

  Relative addressing (BCC, BCS, BNE, BEQ, BPL, BMI, BVC, BVS)

        #   address  R/W description
       --- --------- --- ---------------------------------------------
        1     PC      R  fetch opcode, increment PC                    $F0,  $1AA8 --> $1AA9
        2     PC      R  fetch operand, increment PC                   $60,  $1AA9 --> $1AAA
        3     PC      R  Fetch opcode of next instruction,             $85,  $1AAA --> $1A0A (NOT $1B0A, as PCH not fixed)
                         If branch is taken, add operand to PCL.
                         Otherwise increment PC.
        4+    PC*     R  Fetch opcode of next instruction.             $A9,  $1A0A --> $1B0A (fetching LDA# IMM)!!
                         Fix PCH. If it did not change, increment PC.
        5!    PC      R  Fetch opcode of next instruction,             $20,  $1B0A --> $1B0B
                         increment PC.

       Notes: The opcode fetch of the next instruction is included to
              this diagram for illustration purposes. When determining
              real execution times, remember to subtract the last
              cycle.

              * The high byte of Program Counter (PCH) may be invalid
                at this time, i.e. it may be smaller or bigger by $100.

              + If branch is taken, this cycle will be executed.

              ! If branch occurs to different page, this cycle will be
                executed.

.

.

That branch initially grabbed the LDA# opcode from the address below. This will cause corruption in DPC+ while fast fetch is on.

    494  1a0a            a9 08            lda   #<(P0COLOR)
    495  1a0c            8d 50 10         sta   DF0LOW

.

.

In Stella the code continues and does branch to $1B0A, and the next instruction is JSR $5E9B (which is JSR $1E9B+$4000 in the code for some reason). When it jumps to that subroutine it actually goes to the Break routine at $1FD4 and starts resetting the game. So the game only plays the 1 frame before breaking and starting over. The game appears frozen because the same start to the game is drawn over and over.

 

 

Here is the list file if anyone wants to look further, but I think this is the problem.

frozen.list.txt

 

 

If this is the problem then we should be able to build macros that will check for this and break the rom during compiling. It would spit out an error message that the user might not understand, but at that point they will at least be able to ask for help with said error message, and not be banging their head on the keyboard for a few hours.

[Cybearg]

I just tested both frozen.bin and my own bugged game on real hardware--they both work fine. I didn't notice any strangeness whatsoever: no rolling, tearing, strange sounds, or any evidence of the game being caught in any loop.

[+SpiceWare]

If this is the problem then we should be able to build macros that will check for this and break the rom during compiling. It would spit out an error message that the user might not understand, but at that point they will at least be able to ask for help with said error message, and not be banging their head on the keyboard for a few hours.

 

Ran into similar problems with Stay Frosty 2 and certain revisions of the 7800. My 7800 is one of the problem revisions. I wrote a short program that would scan the listing from DASM to for problems. I was able to fix all the crashes I encountered. Additional checks could easily be added to it.

 

evil7800.zip

[Omegamatrix]

I didn't do much Atari during the week, but here is the current progress. I have a DPCplus_kernel.asm and score_graphics.asm file in the zip below. Ideally the user should be able to replace their files with these and they will work for DPC+ and non-DPC+ BB games (I.e. the score_graphics.asm file won't screw up other files).

 

 

Omega_DPCplusBB.zip

 

 

You should also be able to build regular DPC+ games without issue. If there are any incompatibilities I would like to hear about them. So far the main trouble seems to have been emulation. I'm waiting for Darrell to get back to me next week with some tests to know for sure... so no bug report yet. I did find another issue besides the one I posted. Stella didn't seem to like $A9 being the low byte in the operand of a JMP address. I still have to test that on real hardware too.

 

The good news now. You can have an extra six digits worth of graphics for DPC+ at any time. I have simply left place holders for these graphics as A-F in the score_graphics.asm file. There was no cost for this as I was able to cut out lots of bytes and there was enough space for the extra six digits as well as any kernel options. The new DPCplus_kernel also offers split score and centred score at no cost. I have gone through and cleaned up the code quite a bit, but it still would more work to make uniform to the rest of BB. I'm probably not going to do that.

 

 

Here's how you use everything as it is:

 

Extra Graphics

For extra graphics A-F (you can modify these and make a "Game Over" display for example):

1) Put " const DPC_EXTRA_DIGITS = 1" at the top of your .bas file. All capital letters and underscores are important.

2) Dim some new names for each score byte, "dim sc1 = score", "dim sc2 = score+1", "dim sc3 = score+2"

3) Above "drawscreen" set the digits you want:

 sc1 = $AB
 sc2 = $CD
 sc3 = $EF

 drawscreen

This displays A,B,C,D,E, and F in the score display. If you do have a score you want to keep intact, then you need to copy that score before you overwrite it with these extra digits. Afterwards copy the score back (do this right after main). I haven't actually tried this yet, but in theory it should be that easy. I'm hoping someone will try this for me. You should now be able to toggle between the final score and "game over" with this method

 

Split Score

You can toggle between a split 2_4 score and a centred score at any time. What is required is one bit to be set when you want split score, and cleared when you want centred score. You get decide what bit of what variable you want to use:)

1) Use " const splitscore_2_4 = 1". Punctuation is important.

2) Choose which bit to use in that variable. You set the bit with some predefined values, BIT_0, BIT_1, BIT_2, etc... all the way up to BIT_7. Punctuation and underscores are important. Here I use bit 7: " const SPLIT_KERN_BIT = BIT_7".

3) Choose a variable to use with splitKernelVar. Punctuation is important. Here I use variable z: " dim splitKernelVar = z".

 

Summary:

 const splitscore_2_4 = 1
 const SPLIT_KERN_BIT = BIT_7
 dim splitKernelVar = z

Finally To turn it on in game:

 rem Turn split screen ON during game. 
 temp1 = #BIT_7
 splitKernelVar = splitKernelVar | temp1

And to turn it off during the game (make a centred score)

 rem Turn split screen OFF during game.
 temp1 = #BIT_7
 temp1 = temp1 ^ $FF
 splitKernelVar = splitKernelVar & temp1

Note the # is really important here otherwise BB will make BIT_7 as zeropage (not LDA #imm), and that there are better ways to do above examples. These were just the first thing I had going where BB didn't throw a "complex statement detected" or try to make the immediate load a zeropage load. A zeropage load here will cause hard to find bugs later. I bet BB will have something built in to set/clear bits, but I didn't check.

[Omegamatrix]

I said above that you have to modify the score before drawscreen and right after main. Looking at the code some more I think it really is just before and after drawscreen. You only need to do this if you are switching between extra graphics and a regular score.

[Cybearg]

Just tested on Stella and on real hardware. I can confirm it works! I didn't see anything amiss, nor did I really modify my code, aside from adding the DPC_EXTRA_DIGITS const. I'll keep the warnings in mind as I move forward.

 

 

Thanks much, Omega!

[+Random Terrain]

On 11/7/2014 at 11:38 PM, Omegamatrix said:

The good news now. You can have an extra six digits worth of graphics for DPC+ at any time. I have simply left place holders for these graphics as A-F in the score_graphics.asm file. There was no cost for this as I was able to cut out lots of bytes and there was enough space for the extra six digits as well as any kernel options. The new DPCplus_kernel also offers split score and centred score at no cost. I have gone through and cleaned up the code quite a bit, but it still would more work to make uniform to the rest of BB. I'm probably not going to do that.

 

When I load score_graphics.asm into the VbB score editor, A through F are listed, but when I go to select any of them, VbB spits out an error. Do you know of a way to edit those extra characters besides loading the score_graphics.asm file into a text editor?

[Lillapojkenpåön]

36 minutes ago, Random Terrain said:

 

When I load score_graphics.asm into the VbB score editor, A through F are listed, but when I go to select any of them, VbB spits out an error. Do you know of a way to edit those extra characters besides loading the score_graphics.asm file into a text editor?

I also had trouble with the score editor, so I just changed it in notepad.