Modifying Score Display?

[Cybearg]

At present, the score is the 2 sprites alternating to be side-by-side.

 

Would it be possible to modify the score so it displays the score in different pieces? For example, three digits on the left of the screen and three on the right? Or, in my case, two on the left and four on the right with a bit of a gap between,rather than all together in the center?

 

Ideally, I'd like this to be set by a variable so I could show something like a counter and timer with the two-and-four split and then switch back to normal to display a six-figure score again.

 

Also, on a somewhat unrelated note, I know that the score comes with sprites for values 0-9 normally, to display numbers, but does that leave an additional 6 possible values that could be set to display symbols instead (such as a symbol next to the number as a counter on the left and a little watch next to the timer on the right)? If so, how would you specify the BCD to display those A-F values?

Edited October 12, 2014 by Cybearg

[bogax]

I hesitate to comment since I'm a complete
novice but I think you're stuck with symmetry
unless you're willing to put up with flicker.

I don't think there's time to reposition the
sprites even if there's some way to (otherwise)
do it.

But flicker suggests some interesting possibilities.

hmm, I think I feel another minikernel comming on..

[Cybearg]

See, I would have thought that it would just be a matter of wasting a few operations worth of time between the sprite drawings, causing them to be spread out more. I guess the problem is having enough cycles to check whether or not that time should be wasted, eh? It would need time to compare a value and make a jump so one branch would have the normal timing and the other branch would waste a few cycles between the first two numbers and the last four numbers.

[+SpiceWare]

It'd be very easy to do that. Just shift the position of the sprites further to the right so their copies end up wrapping around to the left side of the screen.

 

Once that's done you'd need to update the timing of when GRP0 and GRP1 were written to. Might even be able to do away with using VDEL as well, which would free up 3 cycles in the kernel.

[Cybearg]

Great to hear that it's possible! I just have no idea how the modifications you mentioned would be done, I'm afraid.

[+Omegamatrix]

Don't be afraid, embrace it! This would require a custom mini kernel, but it really is simple to do as Spice said. Circus AtariAge does something similar, but more involved as it is a single digit on the left side for the lives, and a six digit display on the left for the score. It's more involved because I'm using writes to NUSIZ1 to get the maximum distance inward from the edges of the screen, and the score and lives have different colors on every single line.

 

 

What you are trying to do can be accomplished with a new mini-kernel in BB very easily.

 

 

Edit:

And I'm saying that without having taken a look, Bogax or somebody else will have to do it.

Edited October 12, 2014 by Omegamatrix

[+Random Terrain]

Is this close to what you want or could it be modified to get what you want?

 

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

[Cybearg]

Is this close to what you want or could it be modified to get what you want?

 

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

Almost! I do need a 6-digit score to be split into 2 and 4, though. If that could be modified to display a 2 digit score on one side and a 4 digit score on the other, that would be even better than I had hoped, since I could display the score at the same time!

 

Is that possible and if so, how would one modify the minikernel to make that happen?

[+Random Terrain]

Is that possible and if so, how would one modify the minikernel to make that happen?

Somebody with a working brain would have to answer that.

[Cybearg]

Has anyone with a working brain a bit of time to spare for this?

 

Tweaking the linked minikernel to support a second 6-digit score separated into 2 digits and 4 digits would be ideal, but setting a bit somewhere to switch the normal score between normal and a 00___0000 version would be great, too.

 

If it matters, I'm working in the DPC+ kernel.

Edited October 19, 2014 by Cybearg

[+Omegamatrix]

Anyone else, anyone?

 

 

Okay, I'll do it. Try substituting your DPCplus_kernel.asm with this one.

 

SplitScore_2_4.zip

 

 

 

This is completely untested. You'll be the first one to try it. You need to use splitscore_2_4 as an option. When it is set you will have two digits on the left, and four on the right. When you don't use it you will have the regular six digit display. For the "splitscore_2_4" I cut out pfscore, but I believe it is possible to add it back in to the center of the screen.

 

Again, this is all untested. I don't know if it will compile at all.

 

 

 

I also left in my development rom and test file for anyone who wants to learn how I do these things. Basically:

 

1) Find out what and where I have to change the code. In this case the score routine is in the DPCplus_kernel.asm file in the includes directory of BB.

2) Build a test rom that does the exact same function, but is really bare bones code restricted to doing only what needs to be done. This allows you to get a good clean look at what is going on, and helps to troubleshoot. Isolate and modify is the approach.

[Cybearg]

Thanks, Omega! Unfortunately, when I stick the new DPCplus_kernal.asm into my game folder and try to compile, I get this:

 

No idea what that means.

 

Also, from testing your example .bin (which does work), it looks like the score is set permanently for the ROM, am I correct in that? I need the ability to switch between the separated score and the normal score display in real time by setting a bit or by sacrificing a variable or something. The idea is that I want to show a counter and a timer, then switch to the score when points are gained, then switch back to the counter and timer again in-game.

[+Omegamatrix]

That's okay, it hardly ever goes right the first try.

 

 

I have a few guesses what is going on, but SpiceWare will know better. First things first:

 

1) Is there more than 1 DPC+ kernel out there? I using one from BB_dpc_03.17.13.

2) What bit do you want checked? I can add that in, but I need to know what ram location, and which bit set/cleared for switching between standard score or split score. Having both routines will of course cost a little more rom.

 

 

Back to the problem. My best guess is the ARM code needs to be recompiled because the places where the datafetchers are fetching are different. I think SpiceWare used a two step system in the past. The first was DASM was ran to get the locations of all the datafetch calls, and then the second step was to update the ARM code with those locations.

 

So let me know about 1 and 2, and after it's fixed see if Darrell can help you with the ARM compile.

Edited October 20, 2014 by Omegamatrix

[Cybearg]

1. I'm using batariBasic v1.01dreveng36 - I don't know what version that means I have, though.

 

2. Would it be possible to allow that to be set? For instance, use the highest bit of an arbitrary name that the user gets to define in batariBasic, such as "dim bit_variable = c" or something? If not then, personally, just assigning it to the highest bit of "a" is fine. That should be something that I can manage to modify if I have a need.

 

EDIT: I've attached my version of DPCplus_kernel.asm. Comparing them in Notepad++, I see quite a few differences, but I don't know how many mean anything important.

DPCplus_kernel.asm

Edited October 20, 2014 by Cybearg

[+Omegamatrix]

What zp ram register is "a" mapped to? I need to hardwire it for now.

[Cybearg]

I don't know, because DPC+ seems to auto-assign variable locations or something. DPCplusbB.h, which should have those definitions, like with the standard kernel in 2600basic.h below:

 

A = $d6

a = $d6

B = $d7

b = $d7

C = $d8

c = $d8

Instead looks like this:

 

A ds 1

a = A

B ds 1

b = B

C ds 1

c = C

2600basic.h.txt

DPCplusbB.h.txt

Edited October 20, 2014 by Cybearg

[+Omegamatrix]

Okay, here is a new version built of off RevEng's edits.

 

DPCplus_kernel.zip

 

 

You can use both kernels, and 1 bit is used to select which kernel you want to be displayed. Unfortunately to change which ram location holds that bit (or even which bit you want to use) then you have to edit the controls I placed at the top of the DPCplus_kernel.asm file.

 

But in the end you can do it, and it shouldn't be too painful. Now I'm about 90% sure we'll probably have the same problem as before. Seeing that RevEng did some edits you might ask him to recompile the project. It has a good chance of working then provided that there is enough space in that bank, and I counted the cycles right and didn't go over any page boundaries.

 

[Cybearg]

Hmm... There seems to be a bit of a problem with the sizing. Before this, I was getting a report of 60 bytes free in bank1, but this brings me over by 28:

 

 

Compiling K:\vbB\projects\main.bas

segment: 1fd4 eqm vs current org: 1ff0

free ram: 0

DPC free RAM= 603

-28 bytes of ROM space left in bank 1

K:\vbB\projects\main.bas.asm (1317): error: Origin Reverse-indexed.

Errors were encountered during assembly.

 

This is what my game looks like, so there's not much I can do to cut down on that space:

   set kernel DPC+
   set tv ntsc
   set kernel_options collision(playfield,player1)

   goto __Bank_2 bank2


   bank 2
   temp1=temp1
__Bank_2
...

[+Omegamatrix]

Here is the mapping of the ram locations in VB. 'DS' stands for designated space. The code segment starts at origin $80 and each designated space is added onto that. You can look at the second column in this file to determine which locations are being used. Ignore the 'U00' in front of the number.

 

BB_DPC_ram.txt

 

 

 

[+Omegamatrix]

Cybearg, can you please take out my DPCplus_kernel.asm files, replace it with your original, compile, and send me the .lst file? I need to see how the space is being aligned in that bank.

 

 

We can cut down the routines, maybe combine them better with some branching, but I want to see if maybe something can be shifted first.

[Cybearg]

Alright, I think that this is the file you want. Let me know if it's not.

 

Odd that they compile automatically to .list.txt now. I could have sworn it used to make .lst files.

 

Looks like A and a reside in $d1.

main.bas.list.txt

Edited October 20, 2014 by Cybearg

[+Omegamatrix]

Okay, I will take a look at this, and also crunch down the code so that it fits. I will probably do this tomorrow as it's getting a little late now.

 

After it fits you'll need to talk to RevEng to re-compile the ARM, or if there are some instructions somewhere you can try yourself.

[Cybearg]

Is the ARM those .c files? So it's not just running raw ASM but it's actually running the ASM through a C program in an external processor, or something?

 

Thanks a ton for your effort, Omega. I'll let RevEng know.

[RevEng]

Unless the bB ARM .c file has changed, we shouldn't have to recompile the ARM binary code.

 

My memory is a bit hazy on this, but I think I added a new parameter to the default call the 6502 DPC+ kernel makes to the ARM code, to allow for a user-selectable number of virtual sprites. The reason you guys had trouble initially was you were using the old 6502 DPC+ kernel code with the new ARM code.

 

Also, if you want the kernel to use a user-selected memory location, you can just get them to dim a special name and use that name for the memory in the assembly. If you feel especially kind, wrap an error echo statement with "ifconst MYVARNAME" and "endif" to warn them if they forget to dim the name.

[iesposta]

set kernel DPC+

set tv ntsc

set kernel_options collision(playfield,player1)

 

Cybearg,

The set kernel_options collision...

is no longer needed as RevEng repaired the problem for that work-around, no?