Modifying Score Display?

[+Omegamatrix]

So I just have to subtract in BCD mode, such as:

dec variable = variable - 1
temp1 = variable2 & $0F
temp2 = variable2 & $F0
if !variable && temp1 then dec variable2 = temp1 - 1 + temp2
if !variable && !temp1 then variable = 0

... And so on?

Too much going on there. I believe that the score functions in BB will already be using decimal mode. So to start at 190 you have: $00 in the high score byte, $01 in the middle score byte, and $90 in the low score byte.

 

Then you would just subtract 1 from the score and it should take care of itself, as long as it doesn't roll over to 999,999. You kind of got the right idea of checking if it is at zero. First you check if the middle byte is zero (if not abort), and if it is zero then check if the low byte is zero.

[+Omegamatrix]

Here is an assembly version of decrementing a BCD score by 1. This is enough for me tonight:

    sed  ; set decimal mode
    sec  ; set carry

    lda    scoreLow  ; 1's digit and 10's digit
    sbc    #1   ; subtract 1
    sta    scoreLow

    lda    scoreMed  ; 100's digit and 100's digit
    sbc    #0   ; subtract 0, this is to handle rollover
    sta    scoreMed

    lda    scoreHigh  ; 1,000's digit and 10,000's digit
    sbc    #0   ; subtract 0, this is to handle rollover
    sta    scoreHigh

    cld  ; clear decimal mode

[Cybearg]

 

Here is an assembly version of decrementing a BCD score by 1. This is enough for me tonight:

Awesome, thanks so much, Omega!

 

By the way, is there any way for me to gauge how many cycles I'm using in DPC+? set debug cyclescore doesn't work, but I'd like an idea of where I'm at. Is there any way I can tell?

[RevEng]

Nope. When a real hardware screen starts bouncing or rolling, you've used too many cycles. Stella doesn't yet have cycle counts for the ARM emulation.

[Cybearg]

Gotcha.

 

Now everything seems great except that I need those two additional score digits for $A and $B, but apparently I can't have just 12 digits (if I try and compile, I just get a black screen), so I need either 10 (normal) or 16 (0-F), but 16 digits put me over by 10 bytes...

 

Is there a way to allow for more than 10 digits but fewer than 16 or to shave another 10-12 bytes off of the kernel size?

[iesposta]

Gotcha.

 

Now everything seems great except that I need those two additional score digits for $A and $B, but apparently I can't have just 12 digits (if I try and compile, I just get a black screen), so I need either 10 (normal) or 16 (0-F), but 16 digits put me over by 10 bytes...

 

Is there a way to allow for more than 10 digits but fewer than 16 or to shave another 10-12 bytes off of the kernel size?

I recall reading the DPC+ score is 11. 0 thru 9 and a blank $00-$0A.

If you get more working, please show a step-by-step.

[Cybearg]

I recall reading the DPC+ score is 11. 0 thru 9 and a blank $00-$0A.

If you get more working, please show a step-by-step.

I haven't had any luck getting more working. I'm guessing because somewhere the kernel defaults to either 10 (11?) or 16. If I have 10 or if I have 16 (tested by me cutting out a piece of the kernel just to make some space), it works, but nothing in between works.

[+Omegamatrix]

I think all you have to do is:

 

1) Add the extra digits you want in score_graphics.asm

2) Right before drawscreen update what you want to display.

 

Ex:

dim sc1 as score

dim sc2 as score+1

dim sc3 as score+2

 

...

 

rem draw graphics for A and B

sc1 = $AB

drawscreen

[Cybearg]

I think all you have to do is:

 

1) Add the extra digits you want in score_graphics.asm

2) Right before drawscreen update what you want to display.

 

Ex:

dim sc1 as score

dim sc2 as score+1

dim sc3 as score+2

 

...

 

rem draw graphics for A and B

sc1 = $AB

drawscreen

Essentially that's true, but if I add more than 10 digits to score_graphics.asm and fewer than 16, the game doesn't compile correctly; I just get a black screen as a result. Only when I increase it to 16 total digits does it work again, but at 16 digits, I'm too short on ROM for that to work at the moment.

BrokenOutput.zip

score_graphics.asm

Edited October 23, 2014 by Cybearg

[+Omegamatrix]

Essentially that's true, but if I add more than 10 digits to score_graphics.asm and fewer than 16, the game doesn't compile correctly; I just get a black screen as a result. Only when I increase it to 16 total digits does it work again, but at 16 digits, I'm too short on ROM for that to work at the moment.

Huh, it's working for me. I'm not using RevEng's copy though.

 

Something doesn't sound right here. Are you doing any adding or subtracting to the score? Try doing what I did, except don't touch the score otherwise.

[Cybearg]

Huh, it's working for me. I'm not using RevEng's copy though.

 

Something doesn't sound right here. Are you doing any adding or subtracting to the score? Try doing what I did, except don't touch the score otherwise.

That's exactly what I'm doing already.

   dim sc1 = score
   dim sc2 = score+1
   dim sc3 = score+2

...

   if !split_score then goto __Draw_Main_Score

   scorecolors:
 $46
 $44
 $1E
 $1E
 $1C
 $1C
 $1A
 $1A
end
   sc1 = $01
   sc2 = $23
   sc3 = $45

  goto __Main_Draw
__Draw_Main_Score
   scorecolors:
 $46
 $44
 $AE
 $AE
 $AC
 $AC
 $AA
 $AA
end
   sc1 = $67
   sc2 = $89
   sc3 = $ab

__Main_Draw

That's the only place I'm manipulating the score. Again, it only works if I have 10 or 16 score digits. Nothing in between will compile correctly. See the zip I attached to my previous post for the compile.

[+Omegamatrix]

What happens if you don't do anything different for each kernel, i.e. just do:

   scorecolors:
 $46
 $44
 $AE
 $AE
 $AC
 $AC
 $AA
 $AA
end
   sc1 = $67
   sc2 = $89
   sc3 = $ab

And leave out all the branching between splitscore and center score. That is just do the update in one place for both kernels.

[Cybearg]

What happens if you don't do anything different for each kernel, i.e. just do:

   scorecolors:
 $46
 $44
 $AE
 $AE
 $AC
 $AC
 $AA
 $AA
end
   sc1 = $67
   sc2 = $89
   sc3 = $ab

And leave out all the branching between splitscore and center score. That is just do the update in one place for both kernels.

I get the same thing: a black screen.

 

I really don't think the problem is with me setting those things. As I said, if I use 10 digits it works fine and if I use 16 digits it works fine. 11-15 gives nothing but a black screen. I suspect there is memory being automatically reserved for 10 or 16 digits but if I try to have just 12 then I'm short of the 16 digits it expects. I need to to accept me setting only 12 digits instead of 16 (because there isn't enough space for a full 16 unless you can chop another 10 bytes out of the kernel--then there would be).

main.bas.bin

Edited October 23, 2014 by Cybearg

[+Omegamatrix]

Does this work? I just borrowed some code for a posted .bas file as I'm not too quick with BB.

 

TryThis.zip

 

 

Set this up as a different project. I compiled this with RevEng's version of DPC+. Try adding and removing digits for score_graphics.asm.

 

I had troubles compiling with RevEng's DPC+. Avast! did not like 'bbfilter.exe' at all. Avast fought me downloading it, and using it.

 

I agree something is probably getting misaligned, but I'm not sure what. I would try a very small source and keep adding options until it breaks.

 

 

Edit: And if you can compare your .bin to the one I posted. Do they match 100%? If you don't know how to compare files post the bin and I'll do it.

Edited October 23, 2014 by Omegamatrix

[Cybearg]

I put it in a separate project folder, as you said. As before, it compiles with a black screen for me.

 

I'm afraid I don't know how to compare them, so here's the .bin.

default.bas.bin

default.bas.asm

default.bas.list.txt

default.bas.symbol.txt

Edited October 23, 2014 by Cybearg

[+Omegamatrix]

Looks like something is wrong with your BB. You will need to restart your computer.

 

 

Also this is what I'm using (with VB). You can try using it.

 

bB.1.1d.reveng36.zip

[Cybearg]

Looks like something is wrong with your BB. You will need to restart your computer.

 

 

Also this is what I'm using (with VB). You can try using it.

 

bB.1.1d.reveng36.zip

That's exactly what I was using. I downloaded, unzipped, and set things up to use this one just in case there were any tiny differences. I restarted my computer, etc. Same result--I only get a black screen.

 

Apparently nothing could be garnered from any of the list, asm, or bin files I posted?

 

Maybe RevEng has an idea of what might be wrong here, because I'm baffled.

 

But, again, it DOES work if I have exactly 10 or 16 numbers. I'm just short about 10 bytes from just being able to use 16 numbers and avoiding this blank screen issue. Any suggestions where I can cut those 10 bytes out from in case I just can't get it to compile correctly?

dpctest.bas

dpctest.bas.asm

dpctest.bas.list.txt

dpctest.bas.symbol.txt

score_graphics.asm

dpctest.bas.bin

Edited October 23, 2014 by Cybearg

[Cybearg]

Update... Apparently it did change something; now my game won't compile correctly at any time, regardless of whether I used the modified kernel or modified score files or not... Great.

 

EDIT: This includes kernels outside of DPC+, too. Stuff I was working on just tonight now won't compile. What the shit?

 

EDIT: Oh, phew... Just had to restart VBB after making a change in compiler. That was a scare. Checking progress...

 

EDIT: Okay, apparently it wasn't just vBB. I don't know what the deal is, Omega, but the 2600basic in that zip you posted doesn't work... at all. For any kernel or any configuration of any of the games I've ever worked on. DPC+ kernels will compile and get a black screen when run. Non-DPC+ kernels will fail to compile at all. I've restarted vbB multiple times.

 

EDIT: I've tried restarting my computer. No dice. I've copied the latest version of vbB to a new directory, got it set up to the batariBasic Omega linked and... nothing. Still doesn't compile anything.

 

EDIT: Oh, I found one thing it will compile! A 2kb game I played with when still learning bB. Nothing else, though.

 

EDIT: I give up! I hope someone can offer some insight, because I'm about ready to piss boiling water.

 

EDIT: And, again, this problem doesn't happen at all if I use exactly 10 or exactly 16 score digits. Anyone know why that might be?

 

EDIT: Scratch that: this doesn't happen if I have 10 OR FEWER score values OR exactly 16. But 11-15 causes the apocalypse, apparently.

 

EDIT: Well, I managed to squeak by with 15.125 scores (see the attached score_graphics file to know what I'm talking about). It allows me to compile and has just enough free bytes to not break, so, in the immortal words of Bill O'Reill, "FUCK IT!"

 

EDIT: As a final edit, I just want to thank everyone who helped me out here, especially Omega. Don't let my frustration here with things acting weird as an insult, debasement, or demeaning of the work you guys have done. Omega and RevEng, I wouldn't have gotten far at all without you two, so thank you!

 

EDIT: Hmm... Apparently all is not perfectly well after all. While the game using Omega's modified kernel and the score is working alright now, a different game I was working on earlier today now has a compile error where it didn't before. All I get is the same error I got with the non-DPC+ games when I tried to use the bB that Omega posted:

 

 

segment: 2fd4 eqm vs current org: 2fe4

4034 bytes of ROM space left in bank 1

1252 bytes of ROM space left in bank 2

K:\vbB\projects\Misc\ClownAnimate.bas.asm (3586): error: Origin Reverse-indexed.

Errors were encountered during assembly.

 

Any idea what this is or why it has spread from that other version of bB and now infected the one I've been using for months without issue?

 

EDIT: And if I copy that now-not-working code into another .bas file in a different project directory, it now works. Two files with the exact same code, one works and one doesn't after I switched vbB to the bB Omega posted then back to the one I've been using. What the hell?

 

At least it's not an imposing issue, but I don't like this uncertainty.

score_graphics.asm

Edited October 23, 2014 by Cybearg

[RevEng]

I'm not going to be near a computer for days (posting from a cell) but did you adjust the ORG in score_graphics to allow for the extra characters?

 

Also, regarding problems with other basic files... did you modify the official files, or did you copy them into your project directory before modifying them? The latter is the way to keep your changes limited to a single project.

[Cybearg]

I'm not going to be near a computer for days (posting from a cell) but did you adjust the ORG in score_graphics to allow for the extra characters?

I did attempt this, but I had read in another thread that the ORG/RORG modifications weren't necessary with DPC+ because it apparently ignored it and managed the memory itself. Apparently not? In any case, I didn't have any luck when I tried to subtract 16 from all the ORG/RORG definitions at the top of the file to make room for two more digits.

 

 

Also, regarding problems with other basic files... did you modify the official files, or did you copy them into your project directory before modifying them? The latter is the way to keep your changes limited to a single project.

I only modified versions that I had copied into the local directory so changes would't affect unrelated projects.

[RevEng]

Ok, its been a while since I looked at the DPC+ score code. Its possible that it doesn't need a specific location.

 

I do know that before stuffing bank 1 entirely, if I let the kernel get too bloated, there seemed to be some size boundary that when crossed would cause crashing or unpredictable failures. I don't know why it did this, I always figured that it was an ARM or DPC+ alignment requirement I wasn't aware of. This may or may not be what you're experiencing.

 

If you've worked within the same project directory with your changes, I'm at a loss as to how they could "infect" other projects.

[Cybearg]

I do know that before stuffing bank 1 entirely, if I let the kernel get too bloated, there seemed to be some size boundary that when crossed would cause crashing or unpredictable failures. I don't know why it did this, I always figured that it was an ARM or DPC+ alignment requirement I wasn't aware of. This may or may not be what you're experiencing.

Must be... The last score digit is just this:

       .byte %00000000

A single byte definition. If I add more bytes, it still works, but if I remove that single byte, it stops working until I've removed 32 additional bytes (i.e. cut it down to 10 score digits).

 

If you've worked within the same project directory with your changes, I'm at a loss as to how they could "infect" other projects.

I have no idea, either. Suddenly the one game won't compile in the directory I'd been working on it in, but copying the code to somewhere else suddenly makes it work. Strange, that.

[+Omegamatrix]

I still think your BB is corrupted. I tested this theory by downloading the build I posted and I was able to add letters A, B, C, and D one at a time. It all worked. When I got to letter E the build failed and it clearly told me that origin was reversed. I'm using Win7, although I'm on my laptop which is 32 bit.

 

 

Here is the version of VB I'm using:

VisualbB_1.0_Build_554.zip

 

 

And the .bas file:

default.zip

 

 

The first thing I do is run VB and in particular the configuration wizard. I point the way to the 2600basic.exe, the one for the new BB. I shut down VB and open it back up again. Then I create a new project and generate some default code. I copy and paste the code from the .bas file I posted into the new one (I'm doing this because I have it open in another editor, no real reason otherwise). After that it compiles just fine. It runs the split score just fine although in the rom I'm using variable Z and maybe that is shared with something else in the code because it seems to cycle between split score and centred score. I don't mind as this is just a proof of concept.

 

Just remember that scoregraphics.asm in the BB I posted has some extra characters added into it. If you try to compile other code you made before it will probably cause misalignment with ORG and RORG. If you look in the .lst file I include with the .bas file then search for "DPCplus.arm" without the quotes. That is right above the score graphics. Right below it you see an ORG and RORG for $1000, which aligns to a start of a bank. Next is some custom code (which without looking I don't know what, probably ARM code). Looking below that are more ORG and RORG statements but they are not compiled in. You can tell this in the list file by see the "-" to the far left of them. You can also see the current byte of the rom you are on. It is to the left as well. In this case it says "1894" which is hex address $1894. That number is repeated as there is no bytes being added in the rom for several lines. It is just conditional code. Finally you reach the actual score graphics and you can see the count increase byte by byte $1894, $1895, $1896, etc... You can see the extra digits I added (A,B,C,D). Now if you go way down or just search for "6 bytes of ROM space left in bank 1" you will see that with this rom we still have 6 bytes left. Adding digit E (which is 8 bytes) is too much and the rom fails to compile, but I get a warning with that.

 

Sorry to go a little off topic there. I'm just trying to teach you a little bit what the list file says (or how to read it). List files are extremely useful for trouble shooting. In your case the rom didn't compile in the first place. It was the wrong size. So maybe try everything I posted and see if you get there.

[Cybearg]

Okay I followed your directions exactly, Omega. The good news is, for whatever reason, it DOES work! The bad news is that it only works for that default game you posted. if I would try to compile my DPC+ game using the new test vbB/bB I set up with the score_graphics.asm and DPCplus_kernel.asm include from your bB post, it still compiles to an incomplete ROM. Again, that's even while using the vbB, bB, and everything else you posted except it's my .bas file and that's it.

 

That explains why your bB was causing problems; I didn't realize you replaced some files in it.

Edited October 24, 2014 by Cybearg

[+Omegamatrix]

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