A New Debugging Technique!

So, I was reading Nick Marentes' blog for his game project for the CoCo3 called Fortress.  Nick was kind enough to add an entry for Fahrfall to his Tandy Color Computer Games Workshop site, so I thought I would check-out some other people's projects there.  Anyway, while reading Nick's blog I stumbled across a reference to a little technique that I thought might come in handy sometime.

Timing Is Everything

In reference to one of the screenshots on his blog, Nick says "The red portion can be ignored. It's the way I test the speed of the code by setting the border color to red when I start my routine then reset it to black when finished."  That way, you can get a visual indication of how much of your cycle budget you are using without having to scan the assembler listings to count the cycles by hand -- what a cool idea!

There is just one catch...Nick is developing for the CoCo3.  That machine lets you specify the color of the background separately from everything else, so it is easy to switch it at will.  The VDG used in the original CoCo models doesn't allow for that -- the background color is predetermined by the video mode and (in some cases) the value of the CSS pin.  In the case of the alphanumeric/semi-graphics mode used in Fahrfall, the background is always black.

Still, that is a cool technique.  Surely we can find a way to use it?  Well, yes!  You see, the VDG is fairly dumb about its video settings and it mostly just goes along with whatever values are on its configuration pins at any given moment.  So, nothing stops you from switching to a different mode more-or-less at will.  So for example, you can switch to a graphics mode for part of the screen and back to alphanumeric/semi-graphics for the rest.  That doesn't give the prettiest display imaginable, but it does the basic job.

Size Matters

Switching back and forth between modes paints an ugly picture, but carelessly choosing the modes involved can make things worse.  In particular, choosing the wrong alternate mode can leave a big "glitch" at the border between the two modes.  In my test case, it made it look like the top of one mode was curled like a piece of paper.  I fixed that by ensuring that I was switching between two compatible modes -- modes with the same number of bytes per line and the same number of lines per screen.  In my case, the mode to partner with the 64x96 SG12 mode was the 128x96 "color" graphics (CG3) mode.  This paring still made for an ugly display, but it was stable and recognizable enough to potentially use for debugging a timing-related problem.

I intend to talk more about timing issues in a later post.  I was just excited about discovering this technique from Nick's blog and wanted to share!

Have Your Say?

Oh, one more thing...I'm thinking of changing the score text at the top of the screen to use the orange text color set rather than the green.

Any comments from the peanut gallery?  Which color do you like better for the scores?  The author reserves the right to ignore you, of course... :-)

Beyond that, thanks for checking-in!