Jess Ragan

It's legendary kusoge, among the worst games on the Super NES. As a result, it's frequently reviewed by YouTube content creators, particularly the yellers like AVGN. That notoriety probably explains its high market value. (Don't buy it, though! It's crap! It's like the Simpsons arcade game, if it had been made by the people who made Bart vs. The Space Mutants!)

It'd make more sense if you saw the ending in the arcade version. Just... trust me on this one.

whackem_game.rom Fixed the previously mentioned issues, and added some extra graphics for when Byron gets bonked. Oh, this is shaping up pretty darned well!

We have collision detection! And point labels! (You would not believe how annoyed I get when ColecoVision arcade ports don't have these.) One slight problem: new Byrons will pop up in holes where there is already activity from bonked Byrons. This seems easy enough to fix, by placing a flag in the PoppinByrons routine preventing new Byrons from being spawned in those locations. There's still no trace of sound or music. I have ideas for these, but as I've stated before this is not my strong suit. whackem_game.rom

On a related note, can you check for tiles near or colliding with a sprite? I presume VPEEK would be the way to go for this.

Dang! Good call! I just made the change and the game runs more consistently now. Can you explain why?

whackem_game.romwhackem_game.bas The game! It's starting to resemble a game! I'm excited. So far I've got a working mallet, a working score (built from one 16-bit variable and one 8-bit variable; when both are full the score rolls over), a working timer, and one to three Byrons that pop out of holes when the timer "interval" reaches "intervalmax." There is still no collision detection; I'll need to squeeze that in there in a later update. The game is probably way too fast at the moment, but I'm planning to include a dynamic difficulty adjustment based on the stage reached. The higher the stage, the faster the action and the more Byrons that appear. Butts will also appear more frequently in later stages, as well as deadly bombs that end the game instantly. As with your standard whack-a-mole style video games, the player is expected to reach a target score for that stage, which raises depending on the difficulty level. Everything's running well so far, even if the code is an absolute mess. One sticking point is that swinging the mallet noticeably slows the game down, and spamming it will reduce the action to a crawl. I'm not sure if this can be fixed, but I certainly hope there's a solution.

More progress. I've got the mallet up on the screen... it's fully controllable with the joystick, and can be swung by pressing the fire button. (Probably either fire button, judging from the way the Coleco controller is read and how I've set it up. I don't know how to parse bits out of a byte, although I'm sure there's a way to do it.) Next on the menu? Getting the Byrons to pop up! whackem_game.rom

We've reached a slight impasse, it seems. CONT1 can't be used to read diagonals, at least not by saying things like IF CONT1.LEFT AND CONT1.UP... for up and left. I can read the individual directions by addressing CONT1 directly, but this presents its own problems... pressing fire in conjunction with one of the directions adds 64 to the total, and could complicate matters slightly. I'll have to brainstorm and see what I can do to work around this.

It's said that the ColecoVision was made with "off the shelf" parts. Evidently the parts of the MSX and SG-1000 were taken from the same shelf, because the machines are so similar that they're dangerously close to compatible. The Dina 2-in-1 offers cross compatibility with the SG-1000 and the ColecoVision, and the MSX library is chock full of games originally released for the ColecoVision. The ColecoVision can even play music originally written for the Sega Master System, the next gen upgrade of the SG-1000! So we know what these machines have in common. What's the difference between them? I know the MSX has a lot more RAM than the ColecoVision, but how do the SG-1000 and ColecoVision compare? Wikipedia offers scant information about the SG-1000, but for all I know the two systems could be one and the same, aside from a different BIOS and address calls. And what of the ZX Spectrum? How close is that to all of these "off the shelf" game consoles?

Golly. This is way better than the Parker Bros. version, and I was okay with the Parker Bros. version back in the 1980s. Moving up and down is a little tricky, but past that, it's hard to complain about what's here. It feels less like an abstraction of the arcade game and more like a legitimate port.

Now we're making tracks! I've got a playfield for the game, along with some limited animation. You can probably guess where I'm going with this... it's a Whack A Mole/Mole Attack style game, with Byron popping out from one of nine holes. A cartoon mallet is controlled by the player, and the fire button swings it. Bopping Byron on the head scores you points, while bopping him on the butt subtracts them. Reach the target score in the allotted span of time and you advance to the next stage; fail to do this and you lose. (Later stages have Byron holding up a bomb... this will instantly end the game if you strike it.) In addition to the standard whack a mole gameplay, I'm planning quick draw bonus rounds which challenge you to hit one safe target from several that pop up at once, or hit Byrons in the order that they appear (kind of like Simon). It's still not playable, but I've got most (all?) of the graphics ready. I just need to figure out the game logic; I'm probably going to use a DIM statement to split the screen into nine sections, and each section operates independently from the others. Sound will likely be a problem... I've never been good at this, but it seems there are various tools that will make things easier for me, including one by the ever-busy Tursi. byron_bash.bas byron_bash.rom byron_title.rom byron_title.bas

I've finally advanced to sprites on the ColecoVision, and noticed something peculiar. If you stack one sprite on top of another to add color and detail to it, it will flicker ever so slightly as the two sprites struggle for dominance. I thought it was because I was putting the sprite drawing commands inside an infinite loop, but no, even using the command once still resulted in flicker. Evidently, you can't overlay sprites without the two of them fighting over which one displays, even if you're just using two sprites. It explains why when they drew Mario on Donkey Kong, they only had ALL red pixels, ALL blue pixels, and ALL white pixels in each of his three sprites, with none of the pixels from different colors touching.

Damn, Sly. I just saw your slideshow... you're swinging for the fences in a big way! Can you imagine how players in 1982 would have reacted to seeing this on a ColecoVision? A ColecoVision!