Multisprite kernel and const noscore

[Sknarp]

Hello, I've been looking for a solution to this for over a day-

const noscore =1

in

multisprite kernel

This is documented as being broken, I found a post where Karl G said he "found a fix" but the only other mentions are one suggestion to modify multisprite_kernel.asm with 2 pla's, which I  tried and did nothing, and a custom multisprite.h, which I downloaded and tried and did nothing.

Description for those unfamiliar:
When setting const noscore in multisprite kernel games you end up with screen rolls, playern's flying off the screen, general chaos. obviously something is very wrong with the noscore jump in the MSK. There are a million little nuances to this kernel, I can deal with/work around/fix most of them, but this one is stumping me.

I'm currently using a 4k rom, so no need for bankswitching stuff, if that makes a difference in how this can be fixed. Any help?

 

EDIT: I ended up removing all the score related code from the kernel. I have managed to free up the roughly 70bytes (86 bytes)  Also frees up 10 vars (score and scorepointers) also you do not need to use const noscore so that saves you a few bytes itself. (Roughly 108 bytes in total savings)

The ASM on THIS post is the most recent version
 

SansScore_multisprite_kernel.asm

Edited July 26, 2019 by Sknarp
improved byte savings

[+Karl G]

This should be in the batari Basic forum.

 

I don't think there has been a bB release since I found that fix, but if you post your source (or send it to me if you don't want to post it) along with your customized multisprite_kernel.asm, then I can see why this isn't working for you. 

[Sknarp]

Sorry, I thought since it's an asm question it belonged with other asm questions. I'm a little confused...

There's no mention anywhere of what "the fix" is that I could find- except a different post that as I mentioned said to add two PLAs before the jmp. Is this all the fix is, or is the fix something else completely?

I'm not using any modifications here, I've reverted back to stock when the above mentioned (pla) fix didn't change anything.

Sending you a PM with the files you requested.

 

EDIT: Thank you Karl G for reviewing this and sending me a fixed asm- I also think I probably forgot at some point to move the newest modded include into the same directory *facepalm* so it wouldn't have changed anything anyway.

Edited July 18, 2019 by Sknarp
Solved

[orange808]

I haven't seen the fix in question, but if you're not going to use the score at all, you might be better off making your own fix, completely skipping the score kernel, and freeing the cycles for your program.

[+Karl G]

19 hours ago, orange808 said:

I haven't seen the fix in question, but if you're not going to use the score at all, you might be better off making your own fix, completely skipping the score kernel, and freeing the cycles for your program.

Using the "noscore" option does indeed skip the score code, but it has a stack bug.  The aforementioned fix worked for the OP when he put the fixed version of the kernel in the same directory as his project.  For anyone else who needs it, the fixed multisprite_kernel.asm is attached to this post.  Hopefully it will be included next time there is a bB release.

[Sknarp]

What I think orange808 meant was if I am not using the score at all that I should remove all the score code from the multisprite asm so I can gain back the bytes that it wastes (I think this is what they meant anyway and it is a good idea)

I attempted to do this, but now I have an issue where sprites, ball, missiles all have a strange x offset problem (worse the closer to the bottom of the screen it gets). If this can be fixed then a completely scoreless kernel could save about 70 bytes on one where the code is just being skipped.(not to mention the parts of the mem map that could be freed up) Here is what I have, right now you have to use const noscore=1 and since score is completely removed you can't use this kernel for debug or cyclescore either.

multisprite_kernel_scoreless.asm

[+Karl G]

Also not needed. The code won't be compiled in if you define noscore=1 due to conditional compilation. Check the number of bytes free with the code removed or not removed to double check this. 

[Sknarp]

fixed multisprite with no options: 748 b free

fixed multisprite with noscore defined: 728 b free

"                      " with debug cyclescore: 558 b free

 

scoreless multisprite: 938 b free

[+Karl G]

I guess I didn't read your original post closely enough. I'll take a look at it soon and see how much can be saved without breaking anything else in the process. 

[Sknarp]

I think I just messed up some of the re positioning using HMP0. if you search for the label cycle74_HMCLR and change the preceding line from
 lda #$80

to

 LDA #0

then it only gets offset by -4 (x) at 2 (y) positions, which makes me think I'm close

[+Karl G]

Well - I was wrong.  The Multisprite kernel does not use conditional compilation to not compile the score code when noscore=1 is defined. The other kernels do this, so I made a false assumption. I made an attempt to make this change without success. Getting it to work without messing up other timings is more work than I have time to try to get to work at the moment. Sorry for any confusion/misinformation.

[Sknarp]

SUCCESS!

I figured out what the problem was, the scorepointerset and setscorepointer routines are either required by or factored in to the screen drawing. I was able to remove everything else and ended up with a working scoreless multisprite kernel. As far as I'm aware, any options will have no effect on this kernel, so you don't need to set noscore, and setting something like debug will do nothing.

Quote

 748  bytes free with fixed MSK
 728  bytes free with const noscore defined
 814  bytes free with noscore_MSK

This is a savings of 64-86 bytes!

noscore_multisprite_kernel.asm

[+Gemintronic]

I discovered the screen and virtual sprite positions are much more stable if I do this immediately before a drawscreen:

 

 rem //** Kludge to Stabilize Multi Sprite Kernel **//
 score = score + 0
 drawscreen

I don't know if that helps confirm your suspicions or not regarding screen drawing.

 

Does the noscore kernel you put together here also have other benefirs?  I guess freeing up the 3 score vars is one.  Does it also mean more CPU time for game logic?

 

[Sknarp]

It does free up the three score vars for whatever use you want, unfortunately it does not free up the 6 scorepointer vars because that's the one part I have yet to figure out (see below). As far as cycles are concerned, about 3-4k of asm is being completely removed, and while some of it was conditional (such as if const debug was set) a lot of it just always was executed. I replaced all of that with something like 3 WSYNCs over the course of the kernel, not entirely sure what the effect on cycle count would mean (should be faster?) Not sure how to measure it.

All that remains of the score code (with my added comments, sorry if they aren't 100% accurate) if someone can figure out how to skip all of this (Sleep? WSYNC again?) then those 6 additional vars could be free space in the mem map as well. Best I can figure this is what allows for the tens places in each section of the score?

Quote

setscorepointers
 lax score+2               ;simply loads the score vars
 jsr scorepointerset       ;one at a time
 sty scorepointers+5       ;jumps to scorepointerset
 stx scorepointers+2       ;and back here to do same thing with next var
 lax score+1               ;note that the score vars arent changed, just scorepointers vars are
 jsr scorepointerset
 sty scorepointers+4
 stx scorepointers+1
 lax score
 jsr scorepointerset
 sty scorepointers+3
 stx scorepointers
wastetime
 rts

scorepointerset
 and #$0F         ; score is in A and X, makes the the lowest four digits zero
 asl              ;   over the course of these shifts the 16s place digit becomes
 asl              ;   the 128s place                         
 asl              ; now shifted the number left 3, so we now should have  a000 0000
 adc #<scoretable ; ???.What is scoretable?   
 tay              ; move A (shifted: a000 0000) to Y  
 txa              ; move X(unshifted) to A
 and #$F0         ; makes the 4 highest values of A zero (0000 aaaa)
 lsr              ; shifts right once, now we should have 0000 0aaa
 adc #<scoretable ; ???? this again.What/where is scoretable?
 tax              ; move A  to X
 rts              ; X will store to scorepointer, Y will store to scorepointer+3

 

 

Edited July 23, 2019 by Sknarp

[Sknarp]

I can replace the quoted in the above post with

Quote

setscorepointers
 SLEEP 77
wastetime
 rts

scorepointerset
 sta WSYNC
 rts

to free up the scorepointers variables, but I feel like this is a really inefficient way of doing it. Could really use some ASM god to chime in here please.

Edited July 24, 2019 by Sknarp
clarity

[Sknarp]

That feeling when... you've literally had the answer staring you in the face the whole time. who would have thought that previously commented out align 256 was what was meant to be there in the first place. In retrospect I should have realized it a lot sooner. Here is the kernel,with all the score vars freed up (score as well as scorepointers) It should indeed be leaner, but I'm in no way saying it's been made as small/fast as it possibly can. I believe there are some stubs of code in there that can still be stripped out without throwing off any timing.

noscore_multisprite_kernel.asm

Edited July 24, 2019 by Sknarp

[Sknarp]

Removed the noscore const check previously it had a jsr to a routine I'd removed, so the whole check is gone now, in case someone accidentally set a constant. Cleaned up the part of the code where the sixdigitscore was patched in, it looked like at least 3 separate people had rewritten it, with the indentation changing abruptly. I aligned the indents and deleted obsolete comments so it's easier to read, no change in functionality.

scoreremoved_multisprite_kernel.asm

[Sknarp]

After reading the suggestions of BNE Jeff, I moved a couple subroutines into the extra space (where I previously had to sleep or align 256). This is pretty well cleaned up and has additional savings of 22-44 bytes over the previous posted versions.

multisprite_kernel_NOSCORE.asm