Well, the startup company has kept me very busy.  We’ve working on two products -- one competes with Google and Microsoft, the other competes with Garmin and TomTom. You might see why I’ve been busy :-)

I’ve made progress on the electrical and software design of the second version... but first, about my summer.

I ordered a design kit for the new processor that I want to use.  They don’t make a ready-made module for the exact chip I want to use, so I got a similar chip to prototype with. For my purposes, there are two main differences -- the prototype has only 8KB of memory instead of the 32KB I want, and it lacks a real-time clock.

Graphically, Ping Pong is a fairly simple game. Updating the screen basically involves drawing the two paddles and the ball, plus occasionally updating the score or the centerline -- 90% of the screen is untouched.  The next game my watch will run will be substantially more complicated: a home-made variation of Asteroids.  Big rocks will be flying all over the screen, there will be lots of laser shots in flight, and a score will again keep time.  When rocks overlap, they must be drawn transparently on top of each other. The graphics are so much more complicated, I’ll be taking a different approach to animation: For each frame, I’ll redraw the entire screen from scratch.  This requires a lot more processing power, but, thankfully, the new processor seems up to the task.

I started with a single rock:

and then added lots of rocks:

The frame rate looked good, so I added a lot of game logic: rocks of multiple sizes, a player’s spaceship, laser bursts, and logic to detect when a rock was hit and blow it up in to smaller pieces:

There is still no player’s logic (in the above video, the spaceship just flies around in a big circle always firing), and although I can detect if the player has been mortally wounded, I don’t do anything.

I built a version that runs on my Mac ... it basically uses ASCII graphics to simulate the play. I added a score display at the top (using a nice retro 5x7 font, not vector graphics) and made an AI routine that makes the player look realistic. I also added extra graphics for player’s ship that show when the rockets are firing.  Unfortunately, these improvements made the code size explode!  The code in the video above is just below 8KB, the latest version is about 12KB.  It’s still small compared to the processor I want to use, but too big to run with the demo board I’ve been using.

So, to continue with software development, it looks live I’ve got three options:

1. Keep on with the desktop-only version

2. Shrink the code to make it fit in the development kit

3. Start building hardware!

As much as I’d love to do #3, there are some hardware new features that I’ll be adding that I should test before I commit to a PC Board.  #2 looks possible... I can cut the size of the sprite data in half at the expense of slower execution (I’ll post on the detail of this later). That would help a lot because the graphics now make up the majority of the code:

My Mac platform has some advantages for debugging-- such as the ability to output extra debug info to the screen -- but it also hides things that could become a problem with the real hardware.  For example, the code had a bug that overwrote memory -- in the PC, this caused the player’s ship to move a little, but I didn’t notice because it was already in constant motion. In the real hardware, it caused hundreds of laser shots to appear: