CurtisP

Nope, the way the kernel is structured, lines of color always go with lines of playfield. Sorry about that (on the plus side, I now understand the Kernel a little better).

I see now. Unfortunately PFCOLORS are tied directly to the PLAYFIELD lines, although a Kernel mod might get you what you want. I'll have to take a look.

I'm pretty sure that the playfield scrolls at low resolution (whatever pfheight is set to). If you are seeing something different, I would like to see the code.

I have considered writing a tutorial for programming in Bb. If there is interest, I may go ahead and do it.

As long as both CD Drives recognize multi-session files, you don't have to burn a new CD everytime you need to copy files. If you leave the disc open when you burn it, then you can put it in the burner again, import the existing sessions, then put the new files on it. If the files have the same name as old files, then the old ones will simply no longer be accesible. Or if you want access to all the files, put them in different directories (named by date or something). This way you can use the same CD for multiple tries.

The lives variable is actually two variables in one. The top three bits are the number of lives. and the bottom five bits are a pointer to the sprite data, like so: 128 64 32 16 8 4 2 1 | Lives | Pointer | If the pointer data happens to be less than 15, then subtracting sixteen will cause a carry, which will then subtract 1 from the Lives portion. Of course this should also mess up your Pointer and make the sprite look all wrong. Why did you use =16 anyway?

I wonded it. The precious is mines! And I gotsded to meet Albert too!

If its a Chinese Auction like last year, I will be putting a WHOLE lot of tickets in that bowl...

The Atari 2600 doesn't have a player3, so it has no way to detect any collisions involving player3. The multisprite kernel lets you display something it calls "player3," but which is actually player1. I'm pretty sure this is covered in the manual. You may want to go back and read it again. Now that you have an understanding of the system in general, the details will make a lot more sense.

What I did was to add a PAUSE at the end of 2600baside.bat (on the line after ":END"). Then you can see what ever happens to appear in the DOS box, then press Enter to continue on to the 2600IDE dialog box.

Actually it's not BCD in that case (which is binary coded decimal), but hexadecimal. Anyways, in case no one has posted it, here is a hexadecimal score_graphics.asm. score_graphics_hex_asm.txt

Did you try scrolling the colors each time you scroll the screen? I only see pfscroll used in two different places, so it doesn't look that hard to work in.

My first thought was, who the heck doesn't know how to hook up an Atari? But then I realized, that I have been hooking up systems like this for almost 30 years now. In fact, when I went to the electronic pecialty store (where the guys really know their stuff) to buy an RCA to F adapter so I could hook my 2600 to my TV, the salesman had no idea that the 2600 had an intenal RF modulator. I would say that anyone who's worked with audio/video for less than 10 years wold just try plugging the 2600 into the yellow video in jack, and then thnk it was broken, since there was no picture.

I think the syntx in this cse should be def foo = bar

I would be happy with a two digit dual score minikernal. Seems this would be mush easier anyway. I'm just not comfortable with trying to write a minikernal yet.

It seems to me that redefining the playfield colors could eat up a lot of ROM fast. Howvever, by increasing the number of playfield colors defined and directly manipulating the playfieldcolors variable, you can achieve a color scroll. Please note that this will NOT work if you are using both pfcolors and pfheights, since that uses a different indexing method. pfcolorscroll.bas pfcolorscroll.bas.bin

Ok, I made a label for the cartridge. Now I guess I just have to make some cartidges...

Well since all the way through is 999,999 points, that will take some doing.

When I was playtesting today in Z26, I got the BCD Score Problem again, so I completely rewrote that routine to use a bruteforce the score up with a loop. So here is the even more latest. Silhouette.bas Silhouette.bas.bin

Exactly one month later, I have added the last little bit and am calling the game complete. I added code to cycle colors after about 3 1/2 minutes of inactivity. Since redefining player1colors requires some brute force code, this ended up taking a good 400 bytes. I now have 15 bytes left after compiling, so I pretty much have to stop. Now I just have to play it a lot on the actual console, to make sure there's no bugs. Silhouette.bas Silhouette.bas.bin

That all sounds good. How are you going to handle the 400 usec wait? One of the timers. perhaps?

One of my ideas was to use the paddle variables for the keyboard. However, since they are shared with missile0, this would require the kernel_option no_blank_lines to be set. I think I like the idea of dimming the variable better. The way I would have used vblank was to spread the reading of the controller out over multiple vblanks. Set the output register in one and read it in the next. The drawscreen in between would give you plenty of microseconds. This would require two variables, one for a counter and one for the results. The results variable would just stay 0 until the keypad read was done. Another possible issue is that this code forces both controllers to be a keypad, whereas some people would like to use a keypad plus a joystick. All that said, it's fantastic that you got the reading code to work!

A little flickery, but not as much as a lot of games using the multisprite kernel. All in all, a fang nice game.

Actually 50 - 60 - 60 makes much more sense when you consider that these are the same people that brought you 12 inches in a foot, 3 feet in a yard, and 5 1/2 yards in a rod.

I've considered writing a Keypad routine as well. My thought was to stick the reading code in the VBLANK routine, and store the results in the variables used by the paddle routine to be read by the program. Don't know when I'll get to it though. Or we could collaborate...