Fingers

Not much done recently due to some lovely arthritis pain in my fingers making it painful to type too much (or play guitar). Feeling a fair bit better now so back to it :)

Lock n Chase

Saw this one whilst watching some youtube reviews..

Obviously still needs the (I believe) gold bars drawing, the door at the top and your doors you can drop to stop the cops.

Bullet Hell

Spider fighter has been giving me the finger when I've asked it where the X/Y positions of all the bullets are. I've been making sure I've got ALL the necessary info for each of these 2600 games before I move on to continue them to completion but while the enemy and your ship positions have been easy to find, the bullets have not, or at least not been as easy to decipher.

Turns out there are 2 sets of values for each set of bullets (enemy and yours) one is the good old 2600 horizontal move (fine movement) register and the other is (and this is what took me a while to suss) an index into a bunch of different routines at the start of the ROM which handle the timing of when to start displaying the bullets.

The 2600 has no actual X/Y registers for stuff. You start displaying sprites down the screen as the scanline hits it, but the X position is a mix of waiting CPU cycles till you're near where you want the sprite to appear then turning it on whilst also adjusting that very coarse position with the HMx registers. So the Spider Fighter code creates the 2nd list for the X pos as the actual offset into the timing routines...

Almost everything I need for Spider Fighter now :)

VCS Envy

Working on this stuff has increased my knowledge of the good old 2600 somewhat.

I already knew how it "worked" as I'd started to write a 2600 emulator for GBA a good few years ago (gave up with games running but display taking waaaaaaaaay too much CPU).

It's such a complex little beastie considering it can't do much. The whole cycle timed stuff which demo coders now think is something clever to do was the norm for running a game on this machine. You've got to update the graphics/colours, check for collisions etc on EVERY scanline. You might only have background on one line, or you might have background, the two players, missiles and the ball, the complexity can become frightening.

All in all it's making me itchy. I want to code something on 2600 and I've got an idea what.. Still, too many other things I want to do and MUST finish first.

Spiders (from Mars?)

Quick bit of work on another suggested game, Spider Fighter...

Stay a while, stay forev.... wait, no, you can go now.

Just had family visiting so not got much done for the past week.

I did manage to grab the cop frames in the correct order so he doesn't flap about and do crazy stuff now :)

Keystone is going to need some more complex sprite splitting than Berzerk (which in fact has none). There's the possibility of 3 "enemy" objects (the second 2600 player in repeat 3 times mode) on each floor plus the cop, so 3(objects)*4(floors)+1(you)=13, a few more than the C64 has without raster splits. Not a problem though, there's plenty of screen to change registers before the new level of sprites is needed. I might decide to use 8 per level and use the others for the background static objects (blue blocks etc).

The split code for repeating sprites can be used later for Seaquest too :)

Keystone

While I'm working out the collision code for Berzerk I've dropped some preliminary sprites and background graphics into Keystone Kapers..

Just the floors and cop sprite atm, although I've managed to screw up the frames by grabbing them in the wrong order :/

Vid just shows the demo mode (kicks in if you leave the game for a while) where the cop just runs along each level and goes up escalators.

More Berzerk

After a bit more work on Berzerk I've now got the top/bottom walls drawing properly and fixed (or at least I thought I had) the rest of the wall drawing which was a byte or so off. It's still not right though as I found out on one particular screen!! :(

Preliminary enemy bullets are in (coarse movement atm) with collision detection working for bullets against walls (nice and easy to tell the pseudo 2600 hardware about this one). The same code can be used for your guys bullets. Put in the sprite frames for your guy. Score/lives/bonus is printed now (that's been in for a while).

Nearly done. Finding the best way to tell the 2600 code about C64 collisions is the main thing to do. I know how to fool it into thinking things have happened but I think I need to actual convince the pseudo hardware that it has rather than forcing the result of some variables to be what they would be on the 2600.

Atari 2600

So, after seeing Trip6's forum thread on Lemon and being fairly interested in some of the games I decided to start poking around at a few of them.

To be honest the 2600 games didn't appeal to me, probably because I'd never played them before so I downloaded them to have a quick look. I've got to say I'm a bit of a convert in a couple of cases. Keystone Kapers and Seaquest (especially the former) are really nice little games. Vanguard I've never been fond of and the 2600 version even less so. Kaboom! I can see the appeal of but it's not my kind of thing.

After playing them for a while I started to look at what was going on using Stella's debugger and soon found all the RAM locations of sprite positions, scores, lives etc etc in Keystone. So I used distella (6502 disassembler) to dump the ROM file to some asm source code. A quick C64 setup and subroutines here, a change a couple of bytes there and with a C64 number printing routine spitting out pertinent values I was running around levels on the 2600 version of the game now running almost untouched on the C64. Of course the only thing I could see on screen at this point were the numbers I was printing so I could tell what was going on.

I've now done the same thing with Seaquest, Kaboom and for no reason other than I quite like it, Berzerk.

As Berzerk was the last one I got running I decided to rip the sprites (using my multi purpose graphics finding tool) and include those. I've also done a routine to draw the room (2600 of course does this line by line as it's drawing the rest of the screen) by reading the memory where the 2600 kernel reads it from and interpreting the bits into solid or blank (or 1/2 and 1/2) C64 characters.

Here's the result so far..

The top and bottom lines of the room are drawn a different way, just coding that now.

The main thing to replace/reproduce somehow for doing 2600 to C64 is the collision detection. I know some games don't use the hardware (Pitfall for eg, although even then it might sometimes) but all of these do. In the screenshot above you can see the random placement of robots has dropped one right in a wall. This (I finally worked out) is how it decides how many robots are in the room. I'd originally thought it was random but it turns out if they're in a wall when the screen is drawn for the first time they're just killed off before you even see them.

I'll have to investigate the collision code (2600 hardware collisions are fairly simple) and replace it (or at least fill in the data) from the C64 code. Berzerk should be fairly easy as no robot can ever touch another one so any player vs player collision means you're dead, anyone hitting a wall (so a player against playfield collision) dies and the same goes for any bullet hitting any sprite (bullets are made from PF graphics too).

Not sure how far I'll go with these. The bounty has headed far in another direction but they might be fun to finish anyway..

Pete

New blog

I decided to set up a new blog for posting bits and pieces of game ports to/from generally 8-bit machines.

Some of them might just be for fun and never get finished, some may get finished eventually and some may be started with the express purpose of completing a full port.

Pete