RevEng

I'd help. Mrs. Gates might be a bit upset when little Bill doesn't come home from school that fateful day, but it's all for the greater good.

Didn't RT solve the problem in this post, with an added drawscreen? If I understand your code correctly, it seems that you're looping through the gap randomization routine until you get a value between the left and right border. Since your borders range from 1 to 31, and the random number ranges from 1 to 255, it means you're looping and generating random numbers (on average) 8 times per gap. The random factor means it's sometimes more than 8 loops, which is why the cycle issue happens only sometimes. Try using "h=rand/8" instead of "h=rand". This will scale down the random number so it will be a lot closer to value you want, resulting in fewer "do it again" loops.

Thanks! I missed your program the first time around. Its funny how both of our programs live in the same problem space but are fairly different in approach. Regarding the numeric value, it's pretty easy to rip the bB score routine and relabel everything so it will work independently, but if you want to save yourself the effort you can always grab the score .asm minikernel files from the titlescreen kernel code.

I've been working on a few different project that involved flicker to one degree or another, and I noticed that some colors seem to have more "hang time" than others. To explore this, and also to make picking colors for future projects easier, I wrote a small "flicker picker" utility. flickerpicker.ntsc.bin flickerpicker.pal.bin In a nutshell, the top part of the screen shows the TIA colors flickered with a black background, and if you move the joystick you can pick 2 color values to mix in the the bottom section of the screen. It seems to me that blue and purple have a slightly better hang time than the other colors, in addition to the usual rule about using low contrast values.

Excellent start!

The problem in a nutshell, is that if missile0y<=240 then you're always skipping the bit of code that increments your sound timer and turns off the sound when it reaches 2. If you move that bit of code above your missile0y check, so it's executed each frame, then everything works out... *** EXISTING CODE if missile0y>240 then goto skip missile0y = missile0y-2:goto drawlooping skip if joy0fire then missile0y=player0y-2:missile0x=player0x+4:AUDV0=4:AUDC0=3:p=0 p=p+1 if p=2 then AUDC0=0 drawlooping *** NEW CODE p=p+1 if p=2 then AUDC0=0 if missile0y>240 then goto skip missile0y = missile0y-2:goto drawlooping skip if joy0fire then missile0y=player0y-2:missile0x=player0x+4:AUDV0=4:AUDC0=3:p=0

Actually, it's a fair bit simpler than that. If you swap the wires to pin 5 and 7 in a genesis controller, then a 2600 program can read the "other set" of buttons (A and start) while the paddle capacitors are grounded. I've had the sneaking suspicion this was the case for a while, and I just tested it out a few minutes ago. The few regular 2 button games I tried out worked as they usually do, and a quick test program I wrote was able to read A and start. Harmony definitely wasn't happy with the controller though. I also believe it may be possible to read the remaining buttons on a 6-button controller without further hardware mods, as getting to them is just a matter of handshaking.

Try adding a "=0" to the end of your if statement. Without it "p" will be some value from 0-255 when the fire button is pressed.

Certainly there are fewer instructions, but in Assembly the contexts in which those instructions operate are a lot more complex. bB coders don't need to know about 6502 related topics like two's compliment, carry bits, overflow flags, BCD, various addressing modes, how the stack works, etc, in order to create games. Similarly, on the 2600 front they can also ignore details about horizontal positioning code, skipdraw, six-digit score, asymmetric playfield timing, bank switching, etc. And that isn't to say they can't later explore these topics within bB if they like. Take all of this with a grain of salt, because I pray at the altar of the opcode too. But I think there's great value in the fact that one can write their first "move the guy around with the joystick" 2600 program from scratch with a few lines of code. @Omegamatrix: I've mostly given up on helping people who keep their variables named after the alphabet and use no comments. Its not out of malice or anything; it just takes too much time to follow the spaghetti and understand the context of the variables in their program, and by then I'm bored and on to something else. It would probably be helpful to have a recommended style guide section in the bB manual. Something with the usual comments on self-documenting code, indentation, etc.

A version of Defender 2 that uses the Sega Genesis controller is in the 2 button hacks thread, along with a bunch of other converted games. The genesis B button is the regular fire, and the C button is smart bombs until you run out of smart bombs, then inviso until you run out of inviso, and finally hyperspace. The joystick 2 inviso/hyperspace selection still works too. It's a compromise, but I find it way more playable than trying to use 2 joysticks. I concede that a custom controller would be the best solution.

Yup, though it's a 2600 limitation, rather than a batari Basic one. Nice demo! It looks like you're hitting 263 scanlines instead of the usual 262, but that should be easily enough fixed up.

You'll want to modify it when the display kernel doesn't give you what you need for a game. You may find one day you want to make a game with 2 sprites on the top of the screen and 2 on the bottom, with an asymmetric destructable playfield and no flickering. Or you may decide you want a 4 color playfield that uses flickerblinds. Or a screen that displays a 5x5 grid of colors with a unique color possible in each spot. Or some weird kernel that nobody has dreamed of. Or you may find that the standard kernels do exactly what you need. Give the bB manual a read, look at what people have produced with it, and see if it matches the games in your head. But either way, its a good framework in which to learn about the 2600 and assembly language.

It depends on what you want to modify. To use a car analogy, its like you're asking me how hard is it to work on an engine. Upgrade the spark plugs or air filter? Easy. Replace the radiator? Not as easy.

I believe these games use the stock bB kernels, and they've been released on cart... Gingerbread man Cave-In Evil Magician Returns Dodge-it Solar Plexus There could be more. These are just the ones I know of.

If you use bB without any assembly, you need to use one of the provided display kernels. While the bB kernels are very flexible, certain game designs will either require a custom kernel, or will look better with one. Many successful bB programmers don't know a lick of assembly, so its definitely not a requirement to getting games made.

There are 2 distinct disciplines involved in creating a game for the 2600. One is coding 6507 assembly, and the other is tweaking the 2600's hardware registers to get what you want to happen. Even if you plan to eventually learn assembly, my recommendation is to take the bB route first; it will allow you to get your feet wet with the hardware registers. Then when you're comfortable with that (and if you still decide that you're interested in assembly) you can use bB to get your feet wet with assembly, by writing inline asm, minikernels, and alternate kernels.

So near, yet so far. Carry on.

Philsan, I had a thought on how you could use "no_blank_lines", use whatever color you want on the meteor, and still achieve a side thrust effect... If you increase the shading a bit on the upper module, I think you can get away with adding a "blank" line between the upper and lower module. This would be colored red and have no data. Then you just change your sprite data when the thrust is turned on. "A" represents the easy way to do it with your present 7-pixel wide sprite. If you get a bit more fancy, you can do "B" with an 8-pixel wide sprite. In this case you'd need to mirror the sprite and temporarily re-adjust its position depending on which side the thrust is on.

Check out the discussion in the best prince of persia thread.

Use the no_blank_lines kernel option. It does come at a cost though, so read that link before you enable it.

On the theoretical side... We're talking about a 2-cycle difference. Count up if it makes your bB code more understandable, as that's more valuable. On the practical side... A countdown loop to zero in bB isn't optimized. It still uses a "CMP #0" before the branch. So there's actually no savings.

You're presently using 2 banks. Really I'd recommend that you mostly dedicate most of a bank to the titlescreen, so you might need to go to 4 banks... if this isn't a problem, then a titlescreen is doable. Nothing comes to mind initially for images. I'll mull it over. The other thing you need to figure out what else you want in the layout - what text do you want displayed, if you want the score displayed, game selection (probably not, based on your code so far), do you want scrolling text, etc.

I've always wondered why Nintendo doesn't do a 2D Smash Bros like that for the DS/DSi. Seems like a no-brainer to me. It's not like the console game actually uses 3 dimensions in any meaningful way.

Close enough for a contest to me. Here are my entries. The source images are also from NASA, and under the usual terms... If you don't use the text one, I'd still suggest you reproduce that plaque somewhere in your instructions, as it's too cool.

I have a feeling the demo might need to be reworked a bit for real hardware. I didn't have a harmony at the time, and I learned about the "starting in any bank" thing after I wrote it. Also, the demo relied on the games being 4k non-bankswitched. JH is 8k, so you'd still have to rework it's ASM code to do the right thing if the 2600 started up in one of the JH banks.