CurtisP

I have not noticed this issue on my 4-switch, so it might be a heavy-sixer thing. If you can post the binary you used to test the timers, I will let you know if that binary has a distorted score. BTW, have you noticed any weirdness with the score on all bB 1.0 binaries, or just this one? Thanks for the info. It was a pain getting the cycles right, but I may have to work on it some more. I pulled out my heavy six so I can do some more testing. Looks like I'm going to have to buy some more 2600s, all I have are heavy-sixers.

Then go ahead and do it.

Thanks bAtari. I will get those changes in. My main purpose for doing this was so that I made sure my minikernel didn't have any conflicts. It;s how I discovered that it will crash the multisprite kernel. But now I know how to fix it.

Have you looked at the sample program and documentation? The scores already have different colors.

I already found one mistake. If anyone wants to look it over and point out any mistakes, feel free to do so.

Here is a Memory Map I created from the std_kernel.asm and multisprite_kernel.asm Location Standard Kernel Multisprite Kernel $80 player0x missile0x $81 player1x missile1x $82 missile0x player0colorstore ballx $83 missile1x missile0y objecty $84 ballx missile1y $85 player0y objecty bally $86 player1y SpriteIndex $87 missile1height player1color player0x $88 missile1y player1x NewSpriteX $89 bally player2x $8A player0pointer player0pointerlo player3x $8B player0pointerhi player4x $8C player1pointer player1pointerlo player5x $8D player1pointerhi player0y $8E player0height player1y NewSpriteY $8F player1height player0color player2y $90 missile0height currentpaddle player3y $91 missile0y paddle player4y $92 ballheight player5y $93 score _NUSIZ1 NewNUSIZ $94 NUSIZ2 $95 NUSIZ3 $96 scorepointers NUSIZ4 $97 NUSIZ5 $98 _COLUP1 NewCOLUP1 $99 COLUP2 $9A COLUP3 $9B COLUP4 $9C temp1 COLUP5 $9D temp2 SpriteGfxIndex P1display $9E temp3 $9F temp4 RepoLine $A0 temp5 P0Top $A1 temp6 unused? $A2 rand player0pointerlo player0pointer $A3 scorecolor player0pointerhi $A4 playfieldbase var0 P0Bottom $A5 var1 P1Bottom $A6 var2 player1pointerlo $A7 var3 player2pointerlo $A8 var4 player3pointerlo $A9 var5 player4pointerlo $AA var6 player5pointerlo $AB var7 player1pointerhi $AC var8 player2pointerhi $AD var9 player3pointerhi $AE var10 player4pointerhi $AF var11 player5pointerhi $B0 var12 player0height $B1 var13 player1height spriteheight $B2 var14 player2height $B3 var15 player3height $B4 var16 player4height $B5 var17 player5height $B6 var18 PF1temp1 $B7 var19 PF1temp2 $B8 var20 PF2temp1 $B9 var21 PF2temp2 $BA var22 pfpixelheight $BB var23 PF1pointer playfield $BC var24 $BD var25 PF2pointer $BE var26 $BF var27 aux3 statusbarlength $C0 var28 aux4 pfscorecolor lifecolor $C1 var29 aux5 pfscore1 lifepointer $C2 var30 aux6 pfscore2 lives $C3 var31 playfieldpos $C4 var32 scorepointers $C5 var33 $C6 var34 $C7 var35 $C8 var36 $C9 var37 $CA var38 temp1 $CB var39 temp2 $CC var40 temp3 $CD var41 temp4 $CE var42 temp5 $CF var43 temp6 $D0 var44 temp7 $D1 var45 score $D2 var46 $D3 var47 $D4 temp7 pfheight $D5 playfieldpos scorecolor $D6 A a rand $D7 B b A a $D8 C c B b $D9 D d C c $DA E e D d $DB F f E e $DC G g F f $DD H h G g $DE I i H h $DF J j I i $E0 K k J j $E1 L l K k $E2 M m L l $E3 N n M m $E4 O o N n $E5 P p O o $E6 Q q P p $E7 R r Q q $E8 S s R r $E9 T t S s $EA U u T t $EB V v U u $EC W w V v $ED X x W w $EE Y y X x $EF Z z Y y $F0 aux1 pfcolortable pfheighttable Z z $F1 aux2 spritesort $F2 aux3 pfscore1 lifepointer spritesort2 $F3 aux4 pfscore2 lives spritesort3 $F4 aux5 pfscorecolor lifecolor spritesort4 $F5 aux6 statusbarlength spritesort5 $F6 stack1 stack1 $F7 stack2 stack2 $F8 stack3 stack3 $F9 stack4 stack4 $FA stack stack $FB $FC $FD $FE

I just realized that as currently written, this minikernel will crash when used with the multisprite kernel. It's an easy fix, so I will change it when I add the ability to show 4 scores (along with a few other tweeks).

Actually it really shouldn't work. I remember now what the deal with pfres is. The code references a specific offset from the value in the X register, which I found through trial and error. When using a pfres other than default, the offset varies by the pfres. I couldn't figure out the exact formula for figuring out the offset, so I just left it unimplemented for different playfield resolutions. It's entirely possible to make it work with different pfres, but I'll leave that to someone else. This is really just a proof of concept hack more than anything else. The right way to do this would be to include it in the pfheights+pfcolors routine as I mentioned before. Then the calculations are already done, and it's not using up any more space.

It was designed around the standard playfield resolution, so I have no idea what it will do. It might even crash. In any case. I'm pretty sure the background stripes will not match the foreground stripes.

Added Player Graphics. Here's the sample program. player0.bas player0.bas.bin

Wow that's a lot of code. I don't see any glaring inefficencies. It would just be a little optimizations here and there. For now I think I'll just leave that part alone.

If you would like to send me a copy of the source code, I can see if there is anything that can be optimized. I may also be able to help with the music. There's already a machine language 2600 tracker out there that I have wanted to integrate into bAtari Basic, and I have a friend who might want to write some original music.

Could you test this with your Krokodile Cart for me? My Supercharger and 2600 are packed away at the moment.

Any chance you might be able to do a 4 player version (4 2-digit scores)? If so, I could really use it. Probably not 4 on one line, but two on a line stacked on top of each other would be doable. It would require that the 6-digit score be turned off, though.

I agree. Television is actually interlaced: two 60th second frames make up a single 30th second frame. The phosphors last about a 30th of a second, so there should be very little flicker on an actual 2600.

The minikernel is complete and ready to use. playerscores.bas.bin playerscores.zip

To figure this out. I compiled the program, then opened the file 2600basic_variable_redefs.h and looked at lines 47 and 49 as listed in the output window. These lines are currentpaddle = b paddle = a Looks like you tried to assign these variables in yoru program. However, they are already defined by bAtari Basic when the readpaddles kernel option is set, so you are actually attempting to redefine them, which the assembler doesn't like. I took out the lines dim paddle=a dim currentpaddle=b and it compiled succesfully.

As long as you have a compatibility option to turn it off.

This is something I've wanted to do for a long time. A minikernel that gives you two 2-digit scores, each in a different color. So far I'm just displaying digits. No way to set them yet. Also I've only tested the timing in Stella, not in Z26 or a real 2600. playerscores.txt playerscores.bas playerscores.bas.bin

Where are the 12 available cycles located? Line 217 of std_kernel.asm

But then the variable's value would be different after the drawscreen than before, which would be bad in so many ways.

A paddle is read by setting a bit in VSYNC, then counting down until the appropriate register is zero. It can take nearly a whole frame for this register to clear, so the register is checked by the kernel each time it draws a new scanline. It takes 10 cycles to check one hardcoded paddle and 18 cycles to check a paddle selected by the code. The largest empty space I could find is 7 cycles. So, no paddle for you!

Good writeup, Michael. Some of those points will have to make it into my tutorial when get to multiple sprites.

Unfortunately it is the case. If you really want to use paddles, though, you might be able to do it with some ASM in the VBLANK routine. Personally, I find the multisprite kernel to be overrated

Oh yeah. They rock!