Oh flip!!!

 Some good progress today even though there's not a lot to show for it.

I fixed a couple of bugs (including the stubborn explosion sprite one) that weren't directly related to transcoding the actual Z80 instructions to C. And speaking of the sprite bug; I stared at it a while longer before it struck me that the sprite codes for half the ship explosion were out of range! What that meant was that they had flip X/Y bits set - which I hadn't yet implemented!

The other bug was the 'graphical glitch' on the text way back from Day 1. Today I noticed that it only seemed to occur on the attract screens, and then I noticed it was only on the 'space' character, and always the same glitch. Didn't take long to realise that my text strings were using the wrong character code for space! All fixed now.

I worked through the collision routines for the ship and different objects, such as rockets, ufos, fireballs, and ground-based objects, and finally the landscape. I had to patch the code temporarily to trigger different collisions in demo mode, but everything I can test in the demo seems to work now. I also did a big clean-up of all the C code, removing the ASM code (comments) from routines that are considered complete.

So on to starting a game; implementing coin-up, reading from hardware (dipswitches, coin mechanisms and buttons), more scripts and initialisation code to transcode. I also had to hack a fix for a race condition between my two threads - since I don't actually have a proper, pre-emptive vertical blank interrupt (NMI) routine - but works better now.

Current state of progress is that you can coin up and start a game, but you don't get to see any evidence of the latter as of yet.

Coining up

Next I'll continue on with getting a game to start, and either moving the ship or finishing off the higher level mechanics of the 1 and 2 player game lifecycle. That'll leave bullets, bombs and their interactions.

And then I went and spoiled it all by doing something stupid like explode you...

 I've added the player, player explosion and rocket explosion. And in the process I've encountered my first stubbon bug since I began the transcode.

The player explosion is obviously wrong

You can see that the player explosion is using the same sprite for both halves of the ship. Trouble is, I've checked and double-checked the code, printed debug messages, and I still can't explain it. It's driving me nuts. Here's hoping a new day will shed some light.

That aside, there is a *LOT* of code for the collision detection and explosions. The top level collision routine calls no less than 13 subroutines, each checking collisions between a player/bullet/bomb and object/landscape. And there'll be a lot of cut-and-paste in those routines. I'd even estimate that once I've completed both, I'll be 75-80% through the transcode. The remainder will be for coining up, player controls and mechanics of one and two player games and scoring.

Stay tuned.

All your base are belong to us!

 I now have all the objects that aren't related to the player rendering and animating - including the end of game 'base' which is an otherwise unremarkable so-called ground object.

UFO stage

There's a fair bit of near-identical code in the object handlers, so today was more cut and paste and creating tables rather than implementing new behaviours.

Fireball stage

I've added a few build options to the C code, such as the ability to jump straight to the demo in attract mode and also select the starting stage in the demo. No doubt I'll also add options such as infinite fuel, player invincibility and/or infinite lives to facilitate play testing.

The base at the end the final stage

This really has been a staightforward transcode and now, roughly 50% through the code, I don't see any surprises to come. The code structure accomodates a C translation very nicely indeed.

In fact I took another quick look at Scott's Galaxian disassembly today and Scramble is undoubtedly derived from the Galaxian code base, despite the fact that Galaxian was released in 1979 by Namco and Scramble in 1981 by Konami. Galaxian would also be another straightforward transcode, and I'm tempted to work on it sooner rather than later whilst the project is fresh in my mind.

Next up is animating the player and fuel gauge, scores, mission flags etc. Since the player is inevitably destroyed by a rocket early in the demo, I'll have to also implement at least some of the explosion routines sooner rather than later.

I'm starting to consider which platform(s) I'll target for this transcode. I think Neo Geo will (still) be my preferred target, even if in rotated (vertical) mode initially. I'm trying to work out how difficult it will be to convert to horizontal - likely a lot easier than Space Invaders has proved to be - but I probably won't really know until I try.

Rocket to me, baby!

Some eye candy today. I've now got the rockets launching and following their pre-described path. Every 64 interrupts the code scans the ground-based objects to see if there are any rockets likely to hit the player (within a hard-coded window towards the left side of the screen) and if so, launches the first one it finds.

There are a maximum of 4 in-flight objects at any one time, and that includes rockets, ufos and even fireballs. Yes, hard to believe that there are only ever 4 fireballs on the screen in stage 3, and that they cause so much trouble!

Rockets launching

Each so-called 'in-flight' object has a table that describes their flight path, which is used to apply a delta to its position every interrupt. Not surprisingly, the path table for the rocket consists of a single entry that moves it up the screen.

Rendering the ceiling and the floor

It's interesting that you don't notice the imperfections in the game until you're debugging a transcode. The rocket sprites actually overwrite the progress bar before disappearing - confirmed on MAME.

You tend not to notice the gaudy palette when you're playing...

Next up is to add the routines to handle ufos and fireballs, and also to render the base (a ground-based object). Aside from the fuel gauge, which is currently not updated, that'll be about all I can do before adding the player ship and handling collision detection & explosion to round out the demo.

All that will leave handling of player controls, bullets and bombs, things exploding and game mechanics suchs as coin-up, scoring, high score updating etc. If I had to take a guess, I think I'm approaching the halfway point in the transcode. It's hard to estimate at this stage because the ASM-to-C code line ratio varies considerably with the code itself.

Completely floored!

No eye candy today but some progress; rockets, fuel tanks and so-called 'mystery' objects are rendered as they appear and then deleted as they scroll off the screen. Interesting to note that they simply disappear as soon as they hit the edge of the visible area of the display, as confirmed in MAME. There is also a maximum of 8 ground-based objects on the screen at any one time.

I've also implemented the routine that switches landscape meta-data as you reach the end of the level. As a result, the demo now scrolls through the entire game, looping endlessly on the BASE level. I've currently only implemented the routine to decode (and render) the floor, so next task is to implement the routine to decode the ceiling.

I was thinking once that's done, I should put together some code that renders all 6 levels into a bitmap.

Scrollin' scrolling' scrollin'...

 A couple of days ago I implemented the landscape scrolling and, much to my amazement, it actually worked first time - at least until the end of the first stage.

In the last few days I've been working on getting the so-called ground-based objects rendering. There was a bit of infrastructure to implement and also a minor re-architecture on some of the structures in RAM (simplfying them) but after fixing a bug this morning I've got the rockets rendering.

Too bad I can't upload a video of the scrolling landscape

Getting the rest of the ground-based objects rendering should now be straightforward, as they're all handled using a common object structure.

In fact looking at the disassembly it looks like most of the variables have been defined in the C code, so hopefully that'll be the last tweak of the structures.

The next few days will likely involve just working through the routines to create the rest of the ground-based objects and then 'animating' them which I am assuming is how the rockets are launched. Since the code simply operates on the existing structures, it should be a matter of cranking the handle.

Land(scape) ahoy!

Now up to the demo proper. The initial landscape is drawn (hard-coded routine, not part of the landscape data), the stage indicator on the head-up display is rendered, and things are about to start moving! As I suspected, the demo will comprise much of the remainder of the code, which is a good thing.

The demo is about to start...

At this stage there's still lots of variables being added as I go and a little re-architecting as I learn how the variables are accessed, keeping in mind that in some cases the type of variable is optimised for the C code if it does not appreciably affect the code. Scott has defined structures in his disassembly and I'm staying true to his design as far as possible. It helps self-document the code and also helps the transcode which, I must say, has been going particularly smoothly.

A note on the structure of the Scramble code as a whole:

The main routine is a busy loop that waits for tasks to be written onto a circular queue by the NMI routine. If there is nothing on the queue, it will periodically call a few non-time-critical routines, such as blinking text, drawing the fuel gauge, drawing a column of landscape that is just about to be scrolled onto the screen etc.

The NMI, 60Hz driven off the vertical blanking interrupt, does all the heaving lifting. It's one big state machine that Scott refers to as 'scripts' that control high level program flow and subsequently the low level mechanics of the game logic, controller inputs, and video hardware updates.

Quite a neat design, and one that could be applied to any number of early arcade games. Scott has mentioned that Galaxian is very similar, and I'm hoping that's the case as it would make a transcode similarly straightforward, especially as it's running on the same hardware.

Things should really start to get interesting now. Without <F10> I'm going to have to patch the code to run the demo immediately after start-up so I don't have to sit through the attract mode every time...