CurtisP

A copy of the Basic source code would be helpful.

A number of functions use temp variables internally. At some point I hope to document them all. If you stick to TEMP4 through TEMP6 you should be fine.

Having jitter in NTSC and not in PAL is a pretty clear indication that you are using too many cycles, since there are more cycles available per frame on a PAL system AFAIK.

I'm currently upgrading the standard kernel. I'll see if i can add an optionl to display all 12 lines so that you don't have to do any of these tricks that might break.

I wouldn't bother with the AI, I'd just not have the second sprite in a 1 player game.

In an attempt to make hacking easier, I have determined what cycles each of the instructions in the display kernel code of the occurs on. I've also plotted out all of the conditional code and put it all into a handy Excel file. KernelTiming.zip

Keep in mind that the playerscores minikernel only allows two-digit scores, though I am planning to hack the kernel to display two six-digit scores. I'm also working on another minikernal that will let you tile multiple rows of six sprites each across the screen. The original purpose was card games, but I think you could get some pretty good looking dice with it. I could whip up a single row version with dice graphics pretty quick, I think.

During the title screen code, are you seetin COLUP0 and COLUP1 every time you call drawscreen? These are TIA registers and get overwritten by the Score routine, so that your players will end up being the same as the color of the last score. It looks like this doesn't happen with your cars because you redefine each player and it's color every frame.

the playercolor statement creates a table in ROM, which is why you can't put a variable in it. If you want to change colors when using playercolors, you would create two different sets playercolors and execute the one that you want when you go to change colors. Of course, since it's a banana, one color is probably just fine and tales up less code.

Dang, you people are just never satisfied. Actually it should be possible to have one six-digit score on top of the other by hacking the standard kernel. It would use up the Aux variables which would mean no minikernel, though, I'll look into it when I get a chance.

You could prefix the variable names with tmp, which would identify them as temporary.

I had to do some searching to find the answer. You have to put an extra space in front of your leading space(s), because the bbcode "eats" the first space. So if you want each line to begin with a space when displayed, begin each line with two spaces when entering the code.

If you have Stella set to emulate a paddle using the mouse, then it will likely ignore any joystick mapping. I would assume that the mouse button would act as a the paddle button, which would be read in bB using the appropriate joystick function.

If you alternate between displaying the fish and the octopus every other frame, you will get a little bit of flicker, but you can display both. Collision detection is also easier this way.

The paddle buttons map to joystick directions: paddle 0 = joy0right paddle 1 = joy0left paddle 2 = joy1right paddle 3 = joy1left

In a nutshell. The kernel has to write to the TIA registers everytime it wants something in the scanline to change. This includes, the data for both sprites, turning the missiles on and off and the playfield bits. In fact, in order to draw different patterns into the playfield, it has to write the playfield pattern twice every line. Each scan line lasts for 76 machine cycles and the average machine instruction (which can manipulate one byte of data) takes an average of 3 seconds. So you only have 25 instructions per scan line. In fact, there isn't enough time to manipulate the players and missiles in 1 line, so missles are done in one and players in another, so each screen line in a bAtari Basic program is actually two scanlines. this is also why missiles appear to be offset by a half line from players. So, if we want the kernel to be able to do anything else each scan line, we have to swap out one of the existing functions for the new one. Also, timing is critical - every isntruction must happen at the same time. Thus a routine that decrements a counter, then does a lookup can be easily implemented, but one that does an if (like what you are suggesting) can take a variable number of cycles, and will break the following code, which is wait makes it nigh-impossible.

Just to be clear, which score are you talking about, this minikernel one or the standard six-digit? And in exactly which digit (numbered from the left) are the graphics messed up?

As for the 6-digit score routine, I have never seen any problems with any of the digits. I saw things similar to what Michael was describing when I was playing around with my code to get the timing right, but once I did it's been fine. As far as i can tell, so is yours.

Sorry, I just downloaded your code and see that you were talking about your own 2-player score thing and not the bB 6-digit score. So does that one work, or does it have the same bug? Mine is working now. Your score code only has one color, whereas mine has two per line. Michael noticed that the color was off by one pixel, but i was able to fix it by adding a cycle. Getting that timing right sure can be a pain, can't it? Anyway, I've licensed the minikernel so that it can be included in future releases of bAtari Basic. I think it is pretty solid at this point.

Added Missile Graphics. Here is the sample program. missile0.bas missile0.bas.bin

Alright. I finally saw the color bug that Michael pointed out (right most pixel of the first digit). Adding a cycle into the middle of the display routine fixed it. I rewrote the code to reference existing labels instead of memory locations, so it should work with both kernels now. And I added support for 4 scores (each with it's own color of course). With just one minikernel, you can have 2 or 4 scores. See the documentation for more details. playerscores.zip playerscores.bin

Very nice game with lot's of stuff. I'll have to look at the code again. I think there's some more streamlining that can be done using lookup tables, etc. Any ideas what kind of music you want?

I updated playerscores.bas to cycle the score as well, and ran it on my heavy sixer. I didn't see any problems with either my playerscore (yay!) or bAtari's regular score routine. playerscores.bas.bin

Ok, I just spent the last four hours creating a new bkcolor kernel hack. This one does not require playercolors, etc. In fact it will only work if playercolors are all off. Now the background color is changed on every horizontal line. All you need to do is create a data table names bkcolor. The only downside is that you lose missile1. bkcolor.zip bkcolor.bas.bin

I'm designing the minikernel to work with both kernels, so I will stick with the variables available in both.