Robert M's Blog

Thanks for finding bugs - I wasn't aware of all of them.

 

pfheight default is 15 so I only need a table of 6 zeros for the initial playfield (as the PF is always drawn.)

 

The flickering algorithm works if no sprites overlap (in which there is no flicker, of course) or if all sprites that do overlap do so mutually (i.e if sprites 1-2 and 2-3 overlap, it may fail if 1-3 don't also overlap.) I've been meaning to improve the algorithm but haven't got around to it yet.

-> COLUP0 must be set every frame. The kernel resets it to black during drawscreen.

Actually, the kernel sets COLUP0 and COLUP1 to the scorecolor when it draws the score, so if you don't set them during every frame in the standard kernel, your player0 and player1 sprites will change to the scorecolor.

 

On the other hand, the multisprite kernel needs to use RAM to save the colors of player1 through player5, since they're all drawn with GRP1 and COLUP1, therefore it's able to remember what color to make them each time the frame is drawn. But since GRP0 isn't multiplexed (correct terminology?) the way GRP1 is, there's no separate RAM location for saving the color of player0, therefore the kernel can't remember what color to make it each time the frame is drawn; so it "inherits" the scorecolor, since that's the last color that COLUP0 is set to on each frame.

 

Aside from just setting COLUP0 during each frame (along with COLUP1 if you're using the standard kernel), a way to "correct" this behavior is to use one (or two) user variables for storing the color of player0 (and player1), and then use a vblank routine to automatically load the color into COLUP0 (and COLUP1) at the top of each frame. This would use up precious RAM, but it would save a few cycles during the overscan period. Or, you could just load a numeric literal into COLUP0 (and COLUP1) during a vblank routine, so that no RAM would need to be used; and if COLUP0 (and COLUP1) might vary depending on the situation, then you could use "if" or "on...goto" statements during the vblank to pick the correct color.

 

------> What is the default value for pfheight?

If you omit the "setheight" statement, it appears to default to 15 (16 double-lines), which gives 5.5 playfield pixels. But I'm not sure if this is always the case, or if it can vary depending on any factors.

 

------> The screenheights of 80 and 84 only work with some pfheights all 7 or less, but pfheight can be 15 and 31. What are the legal screenheights for those values. A table of legal combinations of screenheight and pfheight would make things more clear and complete.

The documentation says that screenheight can be only 80 or 84, and that 80 works only if pfheight is less than 8, but 84 works only if pfheight is less than 4. So the legal combinations should be as follows:

 

+-------+-------+-------+-------+
|-------| sh.88 | sh.84 | sh.80 |
+-------+-------+-------+-------+
| ph. 0 | valid | valid | valid |
+-------+-------+-------+-------+
| ph. 1 | valid | valid | valid |
+-------+-------+-------+-------+
| ph. 3 | valid | valid | valid |
+-------+-------+-------+-------+
| ph. 7 | valid |invalid| valid |
+-------+-------+-------+-------+
| ph.15 | valid |invalid|invalid|
+-------+-------+-------+-------+
| ph.31 | valid |invalid|invalid|
+-------+-------+-------+-------+

Note that 88 isn't a "legal" value for screenheight, but it's the default number of lines on the screen (if we exclude the score). However, you *can* set screenheight to 88, but you get the same result as if you'd set screenheight to 80-- for the most part. I defined 88 rows of playfield pixels, then tried all the combinations of pfheight and screenheight, and this is what I got:

 

+--------+------+------+------+------+
|--------|------| s.88 | s.84 | s.80 |
+--------+------+------+------+------+
| pfh. 0 | 88 r*| 80 r | 84 r*| 80 r*|
+--------+------+------+------+------+
| pfh. 1 | 44 r | 40 r | 42 r | 40 r |
+--------+------+------+------+------+
| pfh. 3 | 22 r | 20 r | 21 r | 20 r |
+--------+------+------+------+------+
| pfh. 7 | 11 r | 10 r | 10.5 | 10 r |
+--------+------+------+------+------+
| pfh.15 | 5.5r | X ***| X ***| X ***|
+--------+------+------+------+------+
| pfh.31 | 1 r**| X ***| 1 r**| X ***|
+--------+------+------+------+------+

The second column (with no screenheight shown) is where I didn't set the screenheight constant, so that the screen was the default height.

 

The third column shows where I set the screenheight constant to 88, even though that isn't supposed to be a valid value (but I wanted to try it anyway, since 88 is the default screen height). As you can see, it gave the same results as setting screenheight to 80, but with one interesting exception. In all cases where pfheights was set to 0, the last pfrow on the screen was the same as the one above, as if the next-to-last pfrow was stretched twice as high as the other pfrows. *But*, when I set screenheight to 88, I got the same number of lines as if I'd set screenheight to 80, except the last pfrow was correct!

 

In the boxes that say "1 r**," I got only 1 tall (32-line high) pfrow as indicated, except the rest of the screen was chopped off-- the single pfrow was followed by the score, and then by a huge overscan.

 

In the boxes that say "X ***," the screen rolled like crazy.

 

So my testing results don't quite jive with the "valid/invalid" chart given above. The "valid/invalid" chart is correct for screenheight 80, but pfheight 7 is actually valid (if weird) for screenheight 84. It's debatable whether pfheight 31 is valid with screenheight 84, since the screen is way too short. And it's debatable whether pfheight 31 is valid when no screenheight is specified (meaning it should default to 88), for the same reason.

 

Michael

Thanks for the feedback from both of you.

 

I just noticed that the virtual sprites can not scroll smoothly off and on the top of the screen as they can on the bottom. They just vanish 4 lines from the top. It looks like the horizontal positioning of the first virtual sprite happens in the top 4 lines on screen. Its no biggie, just a characteristic about the kernel worth noting.

 

Cheers!