BASIC-ly Done

Only another month until CoCoFEST!  It sounds like this will be an extra good one...see you there?  It will be a great chance for you to play Sluzzle... :-)

Lock 'N Load

When last we left Sluzzle, we were sorely in need of a loader to coordinate loading both the game binary itself and the pictures that are the object of the game.  All of that could be added to the Sluzzle binary itself, but the built-in Disk Extended Color BASIC was just itching to help out!

Just like a shell script wrapper around a finicky Unix binary, DECB provides a number of facilities that make it attractive for writing a loader program.  While the built-in options for flow control, text processing, and (especially) disk access are not necessarily great performers, they are relatively easy to use.  Plus, using them avoids dedicating time to developing such code.

The DECB loader for Sluzzle performs reasonably well and was easy to implement.  The BASIC console and disk I/O routines were much easier to use and adapt than writing the assembly language equivalents would have been to do.  Dealing with line numbers still sucks, but some minimal planning and allocation of line number ranges to specific parts of the program makes things manageable.  The Toolshed utilities also helped by letting me edit the BASIC sources on a modern PC rather than on the CoCo's keyboard.

Take Control

I added a new feature to Sluzzle -- a help screen!  That might be helpful for  people new to Sluzzle that aren't sure what controls to use.  The help screen is implemented by switching the video mode and the screen address back to the text screen used by BASIC, which will show whatever was left on the screen just before starting Sluzzle.  The loader was extended to write the control guide data before executing the Sluzzle binary.  Typing '?' while Sluzzle is active will reveal the help screen -- too bad I didn't include that in the video... :-(

PLAY Along

One final touch that is barely discernible in the video is the addition of a few music queues.  Starting, winning, and losing the game are all punctuated with some appropriate musical notes.  These are implemented using the PLAY command, which Color BASIC has in common with GW-BASIC (also from Microsoft).  The PLAY command processes a type of music macro language that is also similar to the Ring Tone Text Transfer Language once used on Nokia phones.  This is another way in which using the built-in BASIC is a lot more efficient with programmer time than writing that feature from scratch would be.

With Sluzzle complete, I have released a git tree with the Sluzzle source.  I have also released some downloadable binaries for those that aren't interested in DIY.  I hope you enjoy it as much as I do.

I don't know what will come next here.  I may want to branch out to some other machines that use the 6847?  Or maybe there will be some new ways to exploit the VDG on the CoCo?  It is hard to tell...but as always, stay tuned!

Scramble, Unscramble, and Win

I'm still working hard to get Sluzzle ready for the CoCo Coding Contest review.  I may have to throw-out a few features, but it will still be fun to play.  I keep spending a little too much time "testing" to make sure it is still working -- it must be fun! :-)

Shuffle Like You Mean It

The whole point of a sliding puzzle game is to move the tiles back into their correct order.  That wouldn't be much fun if they weren't scrambled-up in the first place!  So with the basic mechanic of moving the tiles already working, the next order of business was to figure-out how to shuffle the tiles for a new game.

The shuffling routine needed a source of (pseudo-)random numbers.  The old LFSR workhorse rode to the rescue on this one.  In Fahrfall I used a 16-bit LFSR, but this time I am using an 8-bit one.  The 255 value wrap range seemed sufficiently larger than the 4 directional choices used for moving puzzle pieces -- no point in shifting 16 bits when 8 bits can do the job.

I was disappointed with my original shuffling algorithm.  It basically just got the next LFSR value, masked off unneeded bits, and then moved in that direction.  The problem was that this didn't seem to shuffle the board very much without really large numbers of moves.  All those extra moves introduced noticeable startup delay while shuffling the board.  I added code to the shuffling routine that refuses to make a move that undoes the previous move.  This allowed for satisfactory shuffles in just a few dozen moves!

Give Me A Hint

Since some pictures may be less familiar than others (and since people have faulty memories), I thought that it would be nice to provide a way to see the unscrambled picture without having to quit (or solve) a game.  I implemented the unscramble as a selection sort, using the blank square as a scratch space for swapping blocks.  This resolved the unscramble issue without any major issue.

The re-scrambling of the blocks seems like it should have been easy as well, since it is essentially just another sort using the block order saved from before the unscramble.  For some reason, it took me at least twice as long to implement the rescramble as it took to implement the unscramble.  I think that I was confusing myself between the numbered tags I used for tracking the block locations and the numbers I used for identifying the locations themselves.  Anyway, it goes to show you that even someone familiar with assembly language and coding in general can get stymied once in a while -- or, maybe I'm just getting old!  At least my CoCo is eternally youthful...

Is It Over?

There is little point in playing a game on a computer unless the computer can tell you when the game is over.  Implementing this was fairly easy.  As I hinted above, I maintain a map of which block is currently in each location.  After every move, I walk the map to check if the number of each block matches the number for the position it is in.  If they all match, the picture is unscrambled and the game is over  -- you win!  But really, playing is its own reward...

So, the basic game mechanics are in place.  The next major step I see is to implement a Color BASIC loader that lets you select which image you want to unscramble and then loads the image and the actual game binary.  After that, maybe there will be a little more time for a few more embellishments.

Wanna see it?  Then stay tuned...

Introducing Sluzzle

Back in early February, I mentioned that I would be using some of the work documented in this blog as the basis for a "sliding puzzle" game.  Time marches on, so I had better get moving if I am going to have a game ready in time for the review!

CoCo Coding Contest

The contest is sponsored by Aaron Wolfe, under the auspices of his CoCoCoding web site.  It seems like a great way to generate some extra excitement in the CoCo community, and to promote the Chicago-area CoCoFEST!  It looks like there are a number of competing projects, and hopefully Aaron has some people lined-up to help with the judging...?  The reviews are supposed to start in just 10 days...yikes!

Self-Modifying Code

The 44-color graphics mode described previously in this blog is built upon the 8-color graphics mode described here before that.  These modes depend on precisely timed changes to the CSS input to the VDG.  Cycles are so tight that every line on the screen needs its own corresponding set of instructions in the code.  There is not even any time for conditional branching!

The code in the vdgtricks.git repository handles this by generating custom assembly language programs for each image.  The image conversion tool not only converts the image data to an appropriate format for the CoCo, but it also generates the matching code for setting the CSS bit on the VDG at the appropriate times while the image is drawn on the screen.  That works great, but it isn't very flexible.  Since I wanted to support selectable images for Sluzzle, there needed to be another option.

The code for each line of an image is comprised of the same basic set of operations, except that STA and STB instructions are used for clearing or setting the CSS bit for each segment of a given line.  The first STA or STB instruction in each line is the same distance in memory from the first STA or STB instruction of the next line, and each STA or STB instruction within a line is a fixed distance from the first one for that line.  This knowledge allows for writing a program that can rewrite itself as appropriate for a given image.

I modified the image conversion tool so that instead of generating custom code for each image, a data structure is generated that represents the proper CSS setting for each segment of every line.  This data is appended to the image data, and the viewer program interprets it as the program initializes itself.  As the data is interpreted, the proper sequence of STA and STB instructions is inserted into the display portion of the code to match the image data.

Prototype

Sluzzle is a "sliding puzzle" or "15 puzzle" style of game.  Such a game involves dividing an image into a number of blocks (including one empty block), and moving the blocks around to put them into the correct order.  I wrote some code that could blank a block on screen and more code that could copy the contents of one block to another, including both the graphics data and the corresponding code instructions.  This code is working now, but the game is far from complete.

Over the next several days I expect to add code to scramble images for a new game, and to unscramble the images temporarily to provide a hint to players.  I also intend to add the ability to choose from a variety of background images.  I hope to add a few more embellishments as well, like some sort of timer or other scorekeeper and maybe a few sound effects.  If things really go well then maybe I can add some music?  Dunno if that is likely or not...  I'm pretty sure there won't be any auto-solver -- just too much code and not enough time!

Anyway, enough for now...  I'll try to milk this for another entry or two between now and then!  Of course, to see that you will have to stay tuned... :-)

Curiouser and Curiouser

I found a PAL CoCo owner, Simon Jonassen, that took an interest in seeing my 44-color picture viewer running live on his machine.  Contrary to earlier reports of PAL Dragon 64 machines happily running the same code as my NTSC CoCo, his PAL CoCo was not so happy...

Time After Time

At first, I wasn't sure what to make of Simon's reported problems.  Between the confusion created by the working Dragon 64 machines and the difficulties of working from a picture of a TV set, I wasn't sure what was happening.  Fortunately, Simon was able to poke at the code and to determine that adding the extra 50 lines per frame was enough to stabilize the image (as I had initially speculated).  Unfortunately, that wasn't enough to make things right either...

Expect Delays

It turns-out that the delay time between the horizontal sync interrupt and the beginning of the next visible line is also different on the PAL CoCo machines.  I don't know if that is caused by differences in the PAL video signal, if it is caused by the circuitry added around the VDG to make it PAL-compatible, or if there is some other reason why this happens.  In any case, adjusting the cycle-counted code to account for this difference is sufficient to make things work.

Note that the Dragon 32 is still an open question.  At least one link suggests  that it works similarly to the PAL CoCo.  Even if so, it is unclear whether or not the same horizontal timing applies.

On One Condition

Accommodating the PAL timing required some slight refactoring of the code, forcing the CSS value for the beginning of the line to be set after the end of the next line but before the SYNC instruction that waits for the horizontal sync signal.  Luckily this works fine for the NTSC code as well, with a few timing-related alterations.  I was able to simply add a conditional check to the source code, allowing a simple build option to control whether NTSC- or PAL-compatible code is built.  I have pushed this code as an update to the git repository for this project.

I have also released updated code binaries for download.  The new NTSC-compatible code is available at the same location as before, and the new PAL-compatible code is available in the PAL subdirectory there as well.

I am now investigating the acquisition of a PAL CoCo and a Dragon 32.  Hopefully that will allow me to answer any remaining timing questions, or any new ones that arise.  But between now and then, I really need to get to work on the sliding puzzle game for the CoCo Coding Contest -- stay tuned!

More Results

Hey...just a guick update with a couple of links...

PALpable Interest

I found some helpful Dragon folks that were interested in this project.  One of them ran the code on his PAL Dragon and posted the results on this thread.  Surprisingly enough, the code seems to more-or-less work "as is".

I know that the PAL CoCo's and Dragons use the same (NTSC-only) 6847 VDG chip as the NTSC machines.  They have added circuitry that basically puts the VDG to sleep while extra lines are added to drive the PAL display.  I had presumed that those extra horizontal lines would be visible to the software, but apparently that isn't true.

I guess the lack of visibility for those extra lines is good news for this project.  OTOH, I had thought that the horizontal sync signal could be a good timing source for sound/music playback.  Now I would guess that those extra "invisible" lines would break any code using the horizontal sync signal for music playback.  So, if I ever want to support PAL machines in some future music-enhanced version of Fahrfall then I will have to find another way to make it work...

Show Me, Show Me, Show Me!

I posted a few more examples of pics displayed using the 44-color technique on my CoCo.  They are available in an album on my Facebook page.  Have a look!

Back At It

Hey...anyone still there?  Oh, yeah?  Awesome...

CoCo Coding Contest

There is a coding contest in progress for CoCo enthusiasts, with the winner to be picked at this year's CoCoFEST! in Chicagoland.  You know that I can't sit that out!  But what to do?

After a little thought, I decided to use my 44-color display mode as the basis for a sliding puzzle game.  I doubt if that will be the most amazing CoCo game ever, but at least it should earn me a ribbon for participation... :-)

Prep and Clean-up

I left the code for this project a bit undone last Summer.  It would load in my local environment, where I use a monitor program over a serial port.  But it wouldn't load under a normal Color BASIC-based environment on the CoCo or Dragon.  I took a little time today to relocate the code and generate the necessary images for loading the code in such an environment.

http://www.tuxdriver.com/download/vdgtricks/

Want to PAL around?

The code for my 44-color display mode counts display lines in order to coordinate VDG register changes with which lines are currently being displayed.  This counting requires the code to know how many lines are displayed in each frame, and that number is different between NTSC and PAL video modes.  I only have NTSC CoCo machines, including my Tano Dragon.  So, I don't have any way to test PAL-aware code.

If you are using PAL hardware and you are interested in seeing my 44-color mode in action, then maybe you can help me?  It should be as easy as increasing the number of non-displayed lines to count, but that number might need to be tweaked a bit depending upon exact cycle counts and such.  If you want to help me figure that out, then let me know!

For everyone else, watch this space while I roll-out my 44-color sliding puzzle game!