Robo-Ninja Climb 2600

So I had this crazy idea.

The game logic of Robo-Ninja Climb is really simple. And so is the display. So in theory, with the NES and the Atari 2600 both having the same 6502 processor, I could take the NES source code for the game, rip out the rendering bits (and sound and controls), leaving just the core game logic, move it directly to the Atari, then rewrite all the rendering stuff.

In theory, this is made even easier by the fact that the Atari has built-in collision detection. On the NES, about half the work was tracking where you had scrolled, so you could do the math to compute collisions against spikes. On the Atari, I don't have to do that -- as long as I can draw them, it will do collisions for me. Which saves a ton of processing time.

So I got to work. First thing was stripping down everything I didn't need, replacing the controller code, and bringing over the main character physics. That went smoothly, and compiled for the Atari quite quickly. Of course, then I had to find a way to see if it worked.

It's certainly not as pretty as the NES version

Which meant writing an Atari kernel. I think it's somewhat like what women say after having a baby -- after a few years, you forget the pain and only remember the happy parts. Back to counting cycles, trying to squeeze everything into the 76 clock cycles per scanline. Ugh.

But it turns out it wasn't as bad for this game, as there's not nearly as much on the screen  (Anguna had a multi-color player, a  variable-length player missile (sword), changing playfield, a single color enemy, and en enemy missile. This has a single-color player, changing playfield, and single-color enemy. So not as bad.)

Anyway, after all that, I've got most of an Atari port of Robo-Ninja Climb working. Over the last few weeks, I've been slowly working through the more tedious or difficult parts: rendering items, adding title and level transition screens, etc. With a few more hours of work, I might have a Robo-Ninja Climb port for the Atari! (and I wonder if it's the first Atari port to ever directly use source code from the NES game that came first?)

Yes, I'm still working on the BlasterMasterMetroidVania game. And the 4-player adapter. I promise.

I blame Twitter

Huh. I haven't posted here since last December.  Not because I'm not doing things. But mostly because of all the NES dev folks that hang out on twitter and discord, so I've been posting short status updates there along with my usual twitter nonsense.

But because in 4 years when I come back here to this blog to try to remember what I was doing in early 2018, here you go future me. Turns out I have WAY too many projects going on at once! Begin wall-of-text mode!

• I've got cool destroyable blocks going in my metroidvania game, and the basics of some enemies. I've added music thanks to the awesome sound engine that Derek of Gradual Games made. And unfortunately, I've realized that the current version of the game won't actually boot and run on hardware. UGH.  I think on EVERY PROJECT I've ever done, I say "oops, I wish I would have tested on hardware sooner."  Time to pare things down and figure out where it's going wrong. Hopefully in time for Midwest Gaming Classic, where I hope to show it off a little.

I also added a map screen to help you figure out where you've been. 

• The Atari 4-player adapter hit a slight roadblock when I realized that there's something causing a weird static/flicker on the screen whenever player 4 moves their controller. It's hardware-related, not game-related, so I've been needing to do some hardware debugging, which is HARD. Thanks to some advice from Paul at InfiniteNESLives, I've added some capacitors in the last week or so, and they seemed to have helped. But now (based on some suggestions from another awesome Atari homebrewer, John Champeau), I've decided to test another design, based on 2 separate 1-to-2 joystick adapters, which gives some more options for a game to work with other peripherals at the same time (ie 2 joysticks plus an AtariVox speech synthesizer). We'll see how that goes -- I have the parts and the design should be pretty quick to slap together, but after that, I'm stuck in the same "how do I turn this from prototype to production" situation.

Yeah, I'm pretty sure that's NOT the recommended way to attach the capacitors to my board

• Speaking of hardware, I've also started helping Kevin from KHAN games (he pronounces that K-Han, not KHAAAAAN, which is crazy) on a project that involves connecting a NES to the internet.  So I've rigged up my raspberry pi to my NES via the controller port, and I've been trying to get them to talk. So far it's been mixed results, but this week I managed to get the PI to tell the NES to print the alphabet. Until halfway through the screen, when things got horribly out of sync.  I'm going to have to read up on serial protocols and error checking, I think.  

Things were looking good until suddenly they weren't.

• The results came in from the NESDev competition. Robo-Ninja-Climb got middle-of-the-pack results, which is what it deserved. The entries were really high-quality this year, so I'm pretty satisfied with where I ended up. If you want to hear me attempt to talk about it on the Assembly Line Podcast, now's your chance.

• Speaking of the competition, I decided to make a multi-cart of my competition entries (and in theory, will update it each year with any new small games that I make for the NES). So I spent the last couple weeks modifying my competition entries to work on a different board/mapper.  That took a bit of work, as the new mapper (GTROM) uses ram instead of rom for tile graphic data (chr-ram), and four screens-worth of tile map data (nametables) that I have to account for. But now I have a slick demo cart to show off my games. If I can't get the Blastervania game ready by MGC, I'll at least have something to demo!