Development Environment

Some people have asked me about the development environment I am using to produce Fahrfall.  I suppose I could pretend that I am hunched over a CoCo, inches away from a television, furiously typing on the old chiclet keyboard while I wait for the assembler to finish writing to my floppy disk drive.  But in reality, I'm not quite that hard-core!

Development Host

Instead, I am comfortably seated at the controls of my laptop running Linux.  If it matters, I use the Fedora distribution of Linux.  I edit code in vi, and I use make to build it.  My assembler runs from a command-line as well, of course.  OK, maybe I am a little bit hard-core. ;-)

The assembler I use is called mamou.  I believe that the mamou assembler is derived from Motorola's freeware 6809 assembler.  It also includes some functionality to assist in targeting the CoCo platform (such as support for the CoCo's machine language binary format), and some features to mimic other assemblers from the CoCo's past.  The mamou assembler is part of a package of tools called Toolshed, which also contains a number of other utilities related to using the CoCo and for developing CoCo software.

I haven't yet reached the point with Fahrfall where I need macro support in my assembly language sources.  But if/when I do, I will probably just use m4 for the job.  Stop booing!  I used m4 in my CoCo3 Digital Video Player project in order to support building different versions both for the SuperIDE device and for the emulated hard drive interface that many CoCo emulators support.  It isn't that bad!  No seriously... :-)  Well, it gets the job done for me anyway.

One last little tool that I use for lots of development is minicom.  This requires some code running on the target, of course, and hardware as well.  But I do find that having that little terminal window into the soul of the CoCo provides a lot of power for software development.

CoCo Target Hardware

Here is a secret -- I'm not developing on a CoCo!  Well, not exactly...  I am using a TDP-100 for my development target.  The TDP-100 was a clone of the CoCo produced by Tandy and sold through stores other than it's own Radio Shack.  I guess the marketing folks back then thought this was a good idea?  Well whatever -- it is the same as a CoCo on the inside.  This particular box has been modified to output composite NTSC video so that I don't need an RF tuner to use it.  It has an internal speaker added as well, FWIW.

As I mentioned, I am using a serial connection as part of my development.  The hardware I am using is the "Wireless Drive Pak", which seems no longer to be available.  Anyway, it is basically a clone of the RS-232 serial expansion that Radio Shack sold for the CoCo years ago.  But, the serial port itself is replaced by an off-the-shelf Bluetooth module that implements the RFCOMM profile.  This allows me to hack on the CoCo from across the room -- awesome!!

CoCo Target Software

So what is on the other side of that serial link?  A 6809 monitor program, of course!  The one I am using is MON09, available as part of the Micro-C for the 6809 package from Dunfield Development Systems.  I ported it to run as a CoCo ROM as part of another project a couple of years ago.  I used that code to replace the EPROM that came with the Wireless Drive Pak originally.

Having a monitor program available is insanely handy, especially for initial development and experimenting.  Easy commands allow for you to poke at memory and registers for a variety of purposes, including video mode experiments that would be painful to do at the actual CoCo keyboard.  Loading code over the serial port is trivial, especially since mamou outputs the S-record format that MON09 expects to see.  And did I mention that the monitor supports breakpoints, single-stepping, and automatic disassembly of the code?  It is hard to imagine doing CoCo work without it.

Wrap-Up

Well, there you have it -- a nice overview of my development setup.  If you have any questions about what I'm doing or how I'm doing it, then feel free to ask.  If you have any suggestions to make it better then I would love to hear those as well.

Otherwise, stay tuned for more Fahrfall progress reports coming soon!

About The Graphics Mode

This one is a bit long -- strap yourself in!

The video in the CoCo comes from the Motorola 6847 VDG. The VDG is configured by means of several digital signals on its external pins. The CoCo uses some of its PIA outputs and some clever wiring to control the VDG configuration.

The VDG offers a handful of video modes which can be grouped into 4 basic categories: 2-color "resolution" graphics modes; 4-color "color" graphics modes; 4- or 8-color (+ black) "semi-graphics" modes; and alphanumeric modes. In the CoCo and its cousins, the last two categories are combined using the clever wiring mentioned above. Also, one of the "resolution" graphics modes can be used to produce a different 4-color mode by means of NTSC "artifact" colors.

Resolution Graphics

I'm not sure why the VDG designers chose to use the term "resolution" graphics for the 2-color modes. I guess it's because these modes pack more on-screen pixel resolution into the same video buffer space as their 4-color counterparts.

Anyway, in these modes pixel values are encoded with one-bit per pixel, or eight pixels per byte. Any "0" bit values correspond to black. The "1" values correspond to either green or buff (i.e. almost white), depending on the value of the Color Set Select (CSS) configuration pin. This encoding is available in 128x64, 128x96, 128x192, and 256x192 resolutions. The last of those is really only available on black and white televisions due to "artifact" color effects on NTSC monitors.

NTSC Artifact Colors

The combination of the way the NTSC video system encodes color information and the common practice of combining Luma and Chroma signals together into a Composite video signal creates the possibility for certain anomalies when interpreting such video signals. In particular, the signal created by the 256x192 "resolution" graphics mode tricks a color television into producing 4-color pictures! The effective resolution of this mode then becomes 128x192.

The black/green color set produces drab, muddy greenish colors that usually aren't very useful. But the black/buff color set produces a black/white/orange/blue color set. The only real problem is that the encodings for the orange and blue colors (which use "01" and "10" bit encodings) are determined randomly at each boot (i.e. sometimes they use "10" and "01" instead). Most CoCo games that use this mode start with a title screen that asks for the player to reset the CoCo until the screen objects are the correct color.

Mapping images to this color set is not as horrific as it may sound -- the results are reasonably tolerable. The presence of black and white in this color set helps a lot, especially for the stark scenery of a "space shooter" game or something similar. This is probably the single most popular graphics mode for CoCo games, at least for the commercial-grade ones.

There are also some "artifact" colors that use wider and mult-line bit patterns. These modes rely on the nature of a CRT picture tube and not on the nature of the video signal itself. As such, they really don't work on LCD screens and often don't work on "newer" CRT televisions either. In reality, this form of "artifact" colors is really more similar to dithering than to anything else. Given these facts and the relatively poor state of documentation for the expanded set of "artifact" colors, I won't go into any real detail about them here.

Color Graphics

The "color" graphics modes encode color values with two bits per pixel, or four pixels per byte. Depending on the value of the CSS pin, these color values select a color from either a Green/Yellow/Blue/Red palette or a Buff/Cyan/Magenta/Orange one. This encoding is available in 64x64, 128x64, 128x96, and 128x192 resolutions.

In these modes, all of the pixels encoded in a single byte must come from either one of those color sets or the other. It is possible to have both color sets used on the same line, but that requires the CPU to actively change the value on the CSS pin at the correct times while the given line is being drawn on the screen -- tough! A somewhat easier task would be to use different color sets in different horizontal slices of the screen, but that approach does not lend itself well to common playfield layouts. In practice, most usage of these modes simply picks one color set or the other and sticks with it for the entire screen. Expanded use of the CSS pin usually just isn't worth the cost in CPU cycles.

(Note: the only commercial CoCo game known to have used this "on the fly" technique of modifying the CSS pin is Dragonfire.)

Alphanumeric/Semi-Graphics

The VDG has a 64-character set of alphanumerics built into it. These display with a dark (but not quite black) background and a foreground that is either green or orange depending on the CSS pin value. One of the configuration pins can cause these characters to be displayed "inverted", with black foregrounds and green or orange backgrounds. The normal CoCo text screens use black characters on a green background.

The VDG also offers two "semi-graphics" modes. These modes offer lower resolutions (64x32 or 64x48), but with more available colors (at least for SG4). Unfortunately, the colors are specified for groups of pixels rather than for individuals ones.

The Semi-Graphics 4 (SG4) mode divides a character-sized block into 4 pieces (2x2), and allows each piece to be specified as either black or as a single color common to the other colored pieces of that block. All eight colors (Green/Yellow/Blue/Red/Buff/Cyan/Magenta/Orange) are available for each character-sized block in this mode.

The Semi-Graphics 6 (SG6) mode divides a character-sized block into 6 pieces (2x3), and also allows for the blocks to be either black or a common color. This mode offers a choice between the same two 4-color sets as in the "color" graphics modes, with the CSS pin used in the same way to choose between them as in those modes.

The alphanumeric mode only needs six data bits for describing each character, and the SG4 mode only needs seven of them. In the CoCo, these facts are exploited to allow for switching between alphanumerics and SG4 characters automatically based on the data in the video buffer. The high order data bit is fed into the VDG pin that selects between alphanumerics and semi-graphics modes. The next highest order bit is fed into the VDG pin that inverts the alphanumeric character display. This allows for semi-graphics, inverted alphanumeric, and non-inverted alphanumeric characters to share the same display without any heroics from the CPU!

The SG6 mode is handicapped by all this cleverness. The bit used to select semi-graphics mode would normally be a color selection bit for the SG6 characters. But now for SG6 to be active at all then that bit must be a "1" -- this effectively limits the color choices to one of two (or one of four by switching the CSS pin value). The resulting diminished usefulness of the SG6 mode is probably no great sacrifice. In most cases the 64x64 "color" graphics mode is probably about as attractive as the SG6 mode anyway, considering both visual quality and resource usage. In any case, what is done is done and we must live with a crippled SG6 (or just ignore it).

SAM+VDG Semi-Graphics

As documented in the datasheet for the 6883 SAM, the combination of the SAM and the VDG allows for the creation of three new graphics modes based on the SG4 encodings! In fact, it can be used for a few more modes as well -- but the SG4-based ones are the most useful. :-)

By itself, the VDG handles its own memory addressing during video buffer reads. In order to share access to display memory between the VDG and the CPU, the VDG has an input that will force it to relinquish the memory bus to the CPU. However, unfortunate timing of that signal can result in video display glitches as the VDG is starved for information about what to display. A big part of the SAM's job is to coordinate between the VDG and the CPU in order to prevent such glitches. As part of that job, the SAM handles the video addressing on behalf of the VDG and the VDG's memory addressing pins are (mostly) ignored.

The SAM can monitor some of the VDG's output pins (including one of the memory addressing pins) in order to keep track of what part of the screen the VDG is drawing at any given time. But the SAM cannot determine everything it needs to know like this. So, part of the information used to configure the VDG must be used to configure the SAM as well. This is where opportunity rears its head!

The VDG normally re-reads the screen buffer twelve times for every line of alphanumeric/semi-graphics characters -- once for every physical screen line of those characters. When you configure the SAM and the VDG identically, then the SAM replicates this policy. But if the SAM is configured for a bigger display buffer, the effect is for the SAM to re-read the screen buffer fewer times before advancing to the next line of character data. This can double, triple, or sextuple the number of "characters" on the screen, while simultaneously reducing the height of each "character" to half, a third, or a sixth of the original character size. Using this technique with the SG4 encoding produces three new modes known as SG8 (64x64), SG12 (64x96), and SG24 (64x192).  Just like SG4, each of these new modes allow for eight colors (and black) to be available on-screen at the same time!

Fahrfall's Graphics Mode

Perhaps ironically, the Color Computer is often criticized for its relative lack of on-screen colors and especially for the particular colors available. I can't do much about the latter, but I did want Fahrfall to demonstrate just how colorful the CoCo really can be. That narrowed the choice of video modes either to one of the SG4-based semi-graphics modes, or perhaps to one of the "color" graphics modes using well-timed CSS manipulations. The movement in the background of Fahrfall and the fact that the player object could be just about anywhere on the screen at any given time made the CSS manipulations seem impractical.

I also wanted to keep the game performance at an entertaining and playable level. Sure, everyone wants a nice "high resolution" display like the ones in the arcades. But the games in the arcades often had hardware assistance either for playing audio or for pushing video objects around the screen (or for both), whereas the CoCo only has the CPU to do those things. So the SG12 mode was chosen in hopes that its 96 lines would be more manageable than the 192 lines of an SG24 display.

From my experience with the CoCo3 Digital Video Player I learned that color resolution can be a good substitute for spatial resolution in graphics. Consequently, a 64x96x8 mode sounds like it is in the same ballpark as the 128x96x4 mode used in many CoCo games. The comments I have received about the Fahrfall videos posted so far seem to indicate that people think it looks alright. So, hopefully the SG12 mode is a good compromise between beauty and performance.

Phew!

Well, this one went longer than planned...I hope it was worth it! At least the CoCo hardware got a little more coverage, and I got to share my thought process for picking SG12 as the video mode for Fahrfall.

The weekend will be here soon -- wish me luck on finding some time to get a player object moving on the screen for Fahrfall... :-)

Reading The Joystick

Another little progress report...

Real life demands attention, particularly during the week.  So, I haven't been able to concentrate much on Fahrfall for a few days.  However, I did find some time to figure-out how to read the joystick -- that should be handy!

Analog Joysticks

The CoCo uses analog joysticks that return separate analog voltages for both X and Y axes of rotation.  The values of these voltages range from 0-5 Volts, with the value corresponding to how far in the left/right (or up/down) direction the joystick is pointing.  These voltages feed into one half of the CoCo's analog multiplexor.  From there they can be routed individually to one side of the CoCo's analog comparator.

The button on the joystick is a digital signal, and once it is read it needs no conversion.  But the analog values coming from the joystick need to be transformed into digital values in order to be useful to the computer.  The CoCo has no Analog-Digital Converter (ADC) hardware.  So, how is this handled?

Successive Approximation?

The other side of the CoCo's analog comparator is connected to the output of the CoCo's Digital-Analog Converter (DAC).  The output of the comparator feeds into one of the PIA ports.  So all the CoCo has to do is route the desired joystick axis to the comparator, cleverly manipulate the DAC values, check the comparator result, and interpret the results in order to generate an approximation of the joystick's position.  Simple, right?

At least one of the decades-old programming references I have for the CoCo actually recommends walking through all 64 possible DAC values in order to perform the analog-digital conversion.  I suspect that a binary search starting with the MSB of the DAC would be much more efficient (~6 iterations).  But I think my way is even better than that!

Get To The Point

Analog joysticks are fine for flight simulation, "precision" pointing, and maybe some other applications.  But most people seem to prefer digital joysticks for arcade-style games, since what you really want to indicate is direction rather than position.  I can't make the CoCo use digital joysticks, but I can make it treat the joysticks as if they are digital.

The algorithm that I am using divides each axis into three zones, one at each end with a "dead" zone in the middle.  This allows me to find all the information I need for each axis with only two comparator cycles.  For now I am using a 40/20/40% split for the zones.  This leaves a dead zone that roughly corresponds to the width of the "trim" adjustments on the self-centering "deluxe" joysticks Tandy offered for the CoCo back in the day.  This gives good sensitivity without much chance of leaving a joystick unadjustably off-center.

Show Me

I haven't made much progress on Fahrfall this week.  But I did put together a little demo to go with this post.  The demo just reads the joystick and sets flag bits for each direction and the button status.  The display portion of the code reads the flags and paints a corresponding red box on the screen for each bit set in the flags.  It isn't much, but it proves the point. :-)

Well, that's all for now!  Stay tuned for more info about the CoCo and further progress reports on Fahrfall!

Basic CoCo Architecture

This seems like a good opportunity to provide an overview of the CoCo's technical details.  Such an overview should be helpful in understanding some upcoming topics around the development of Fahrfall.

Chipset Overview

The design of the CoCo is based upon a reference design in the back of the datasheet for the Motorola MC6883.  This reference design is built around a handful of LSI chips from Motorola:

• 6809 (CPU)
• 6883 (SAM)
• 6847 (VDG)
• 6821 (PIA)

The CPU is one of the most powerful of its era.  The hardware includes two 8-bit accumulators A and B, which can be concatenated together and referenced as the D register.  A number of 16-bit accommodations in the instruction set make use of the D register, and it is convenient for data movement.  The 6809 also includes a hardware multiply instruction, for when that operation is necessary.  (Alas, there is no divide instruction!)  Finally, the 6809 was specifically built for running position independent code.  This gives it a wealth of branching and data indexing capabilities not present in most of its contemporaries.

The SAM (Synchronous Address Multiplexer) glues the rest of the system together.  This device controls access to the DRAM in the system, and provides the refresh signals for the DRAM as well.  The 6883 also does the address decoding for the rest of the base CoCo system, providing chip selects for the other on-board devices and a couple for the expansion slot as well.  The 6883 also controls the clock, allowing for a choice between two different clock speeds.  Finally, the SAM integrates with the VDG in order to enable the CPU and the VDG to share the DRAM without interfering with one another.  This final feature also allows for some extra videos modes not available with the VDG alone.

The VDG (Video Display Generator) is, of course, what puts the graphics on the screen.  The 6847 is a utilitarian chip, providing a modest variety of both text and graphics modes in a limited variety of colors.  "Semi-graphics" modes are available as well, with more simultaneous colors but less flexibility.  The modest feature list gets even more modest as one tries to take advantage of certain features -- higher resolutions are only available in either black-green or black-white combinations; the colorful graphics modes have to pick between two fixed four-color palettes; and the "semi-graphics" modes are very low resolution.  Still, the device can produce credible displays for the era.  Also, the SAM/VDG combination allows for some higher-resolution "semi-graphics" modes that are less of a compromise to use.

Two PIA (Peripheral Interface Adapter) chips round-out the set.  Each PIA provides two 8-bit digital I/O ports, as well as two 1-bit inputs and two other 1-bit I/O signals.  The PIAs are used to implement all of the other peripherals that are part of the CoCo, with the exception of the expansion port.

Other Peripherals

One of the most important devices remaining to be described is the 6-bit Digital to Analog Converter (DAC).  The DAC is used to output audio to the television and to transmit data to the cassette recorder interface.  It is also used in conjunction with an on-board comparator circuit to digitize values from the joysticks.  The input to the DAC comes from one of the PIA ports.

A two-channel analog multiplexor is part of the CoCo.  One side is used to select between three audio sources: the DAC; the cassette input; and the expansion port.  The other side is used to select between the two joysticks and each of their axes.  The joystick axes connect to the other input of the comparator mentioned above.  The selection for the multiplexor channels is done via two of the 1-bit outputs from the PIAs.

Two PIA ports are used to scan the keyboard.  The handful of remaining PIA bits are used to implement the cassette player input (including motor control!), the serial port (with the help of some level shifters), and a 1-bit sound option.  A couple of the bits used for the keyboard scan are reused to also monitor the buttons on the joysticks.  The remaining 1-bit inputs of the PIAs are used to enable interrupt generation from the VDG, the expansion port, and the serial port's Carrier Detect bit.

Is That All?

Well, this is running a bit long...I didn't even get to the expansion port!  Hopefully I didn't lose anyone.  I could probably go into more details, but anyone that really wants more details can probably find them on their own.  I suppose that I just wanted to provide a feel for how much the guys that put the CoCo together did to make the most of what they had available.

Anyway, in upcoming posts I hope to discuss things like what video mode I am using for Fahrfall, how to generate music and sound effects on the CoCo, how to read joysticks, etc.  Hopefully the background provided above makes those posts a bit more digestible.

More to come!

Generating The Platforms

Just a quick check-in with the weekend's progress...

Platform Generation

I took some time on Saturday to get some platforms onto the screen.  This turned-out to be simpler than I thought.  I started with just a single, full-width platform scrolling continuously from the bottom to the top and then repeating.  From there I progressed to using the LFSR data to randomize the platform pattern -- I'll talk about that a bit below.  Then I moved to having three independent platforms on the screen at a time.  I was so pleased with myself that I posted a video!

LFSR Data Anomalies

The LFSR is working great for my (pseudo-)random numbers.  But as I noted in the video, it was possible to get either empty platforms or full-width "sweeper" platforms.  Today I played around with correcting that.

The platform data is simply a bitmask, with each bit representing a corresponding portion of a platform's span.  I started checking for "all ones" values in order to prevent the "sweepers".  A full-width platform would be impossible to pass, resulting in "Game Over".  I played with it a bit, and settled on simply substituting a default platform data value for any "all ones" values I found.

The nature of an LFSR is such that you can't really get a completely zero value for the LFSR.  But my LFSR is 16-bits wide, and my platform data is only 8-bits wide.  At first I was taking only half of the LFSR value for my platform data, and half an LFSR can be zero.  I even observed an empty platform scroll up the screen in "real life" -- I should be a tester! :-)  Anyway, now I also check for an "all zeroes" value and substitute the default platform data value in that case as well.

Platform Distribution

The platform data was already as random as the LFSR could make it, but I wasn't totally happy with how the platforms were looking.  It seemed like there would be runs of too many gaps between platforms, or not enough, or whatnot -- all that could just be my imagination too.  Anyway, I decided to experiment a bit, particularly with XORing the LFSR data with...whatever.  Anyway, I settled on XORing the two halves of the LFSR data together, then applying the tests for "all ones" and "all zeroes" as described above.  I don't know for sure if this is any better than before, but it feels better in the seat of my pants!

Just A Little Swizzle...

I wasn't entirely happy with the way the scroll planes were moving.  They had been moving upward one position every 2, 4, 8, or 16 frames, depending on the plane.  The code for handling this was also looking a bit unwieldy as well, at least for the "every 16" case.  So, I refactored...

I changed from the 2-4-8-16 factors to factors of 2-4-6-8.  The introduction of the "every 6" case required an independent counter, since 6 isn't a power of 2 like the rest of them.  Anyway, I think the results looks a bit better overall -- less jerky and more quick.  It does seem to lose a bit of the feeling of depth, but I think it is still alright.  Plus, the code seems a lot cleaner too.

More To Come

I did that scroll plane swizzle after shooting the video above, so I suppose you will have to wait a bit to see it.  I imagine that the next progress report is just days away!

Also, I have a few topics that relate more to the background of the project rather than to the progress of the project itself.  For the benefit of the technically curious among us, I want to provide a bit more information about the CoCo, what tools I'm using, etc.  I'll try to meter them out, and continue to intersperse them with some progress reports.

Watch this space!

What's In A Name?

So, what's with the name "Fahrfall"?  I know you were wondering! :-)

Something About A Fall

The inspiration for Fahrfall is a game called DOWNFALL.  That is a cool name for a cool game!  But this is a different game, and a different game needs a different name!  Any name involving "Goes Down" is out for similar reasons -- see the Prologue entry of this blog if you need a reminder as to why.

Still, the premise of the game is falling.  In fact, I originally used "falling" as a working title.  But "falling" just didn't seem to have the right ring to it.

That Sure Is A Long Fall

I brainstormed for a while for a theme, and kept coming back to ideas about falling a long way.  I started to settle on "farfall", which seemed like a reasonable choice.  I Googled a bit, and found enough references to suggest that "farfall" has a certain lack of uniqueness.  In any case, it just wasn't turning me on.

Meine Deutsche Ist Nicht Gut

At some point, it occured to me that "far" sounds a bit like the German "fahr".  A vague memory from an old Volkswagen commercial suggested to me that "fahr" might relate to driving, and a hunch suggested to me that "fall" might have a similar meaning in German as it does in English.  German is notorious for its compound words, so I thought this might be a way to make something with at least a tenuous connection to a reasonable meaning but that retains some uniqueness.

I Googled a bit for "fahrfall" and some likely(?) German variations like "fahrenfall", "fahrfallen", "fahrenfallen", etc.  I ran into a few references, but nothing that seemed to have a consistent meaning -- it seemed like "fahrfall" might be used a bit like slang, with various links to roads, driving, running, falling, etc.  I pinged some native Germans and they more-or-less agreed with my interpretation -- one called it a "Denglish" word, which I suppose is the German equivalent to "Spanglish". :-)

A Name Is Born

So, "Fahrfall" doesn't really mean anything.  Yet, it invokes a relationship to "driving" and "falling" (and maybe a few other things).  Since the premise of the game is to control (i.e. drive) a fall, the name seems appropriate to me.

Improving The Flame Effect

I originally added the flame effect just to fill the middle space at the top of the screen, and to provide a visual reminder that you can't let the player scroll off the top.  At first it was just a static, irregular image -- first all in red, then in a motley red and orange.

Flicker Or Flash?

I decided I wanted the flames to "flicker".  So I added code in the game loop to use an XOR operation to flip the red bits to orange and vice versa.  At first this was annoyingly fast, so I slowed it down a bit by skipping a set number of frames between each flip.  The result was OK, but very regular -- more like a flash than a flicker.  The colors seemed a bit wrong too.

In the news recently have been some reports of arson out in California.  Obviously I feel terrible for the losses of those involved, but the news reports did give me some really good views of raging flames!  I realized that I needed to add some yellow at the core of the flames, and that the flicker effect needed to be more random.

LFSR PRNG, EE-I-EE-I-O!

Games tend to need "random" numbers anyway for a variety of uses.  I knew I would need some sort of (pseudo-)random number generator (PRNG) eventually, so I might as well implement one now.  I decided that a linear feedback shift register (LFSR) would be a good way to go.  An LFSR is relatively simple to implement, reasonably cheap to execute, and can provide convincingly "random" sequences of numbers.

I settled on a a 16-bit LFSR, since that size is reasonably convenient to handle with the 6809's resources.  I used the maximal-length polynomial for 16-bit LFSRs from the table in the LFSR Wikipedia article.  For a random seed I used the Extended Color BASIC TIMVAL variable, which is a free running software counter used by the CoCo's ROM for timing purposes.  I sprinkled-in some assembly code with a few logic operations and I was all set!  For now I am bumping the LFSR after every frame, but I reckon that I might have to hit it more often before this is all over.

Flame On!

Now armed with (pseudo-)random numbers, I could make the flames flicker more realistically.  Instead of flipping colors on a regular basis, I now use the LFSR data to randomize the time between color flips.  Using what I learned from the arson reports on the news, I added some yellow bits to the flame graphics and arranged the red and orange bits with the red on the outside parts and the orange in the middle.  Finally, I made sure that the yellow bits and some of the orange bits were exempted from the flickering.  So now the colors go from yellow/orange/red to yellow/orange and back on an irregular basis.  The overall effect looks pretty good "live", although the video cameras I've tried so far don't seem to pick it up very well.

I've spent more time on these flames than I ever intended to spend.  But, I do think they look pretty good.  I'm not sure if it shows-up very well in the video, so you might just have to take my word for it.  FWIW, I also changed the color selection algorithm for the scroll effects to something that is a bit cheaper to execute.  Anyway, I'll include a video clip just to show where I'm at...an actual game is still to come!