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... :-)
Good Job John
ReplyDeleteHow many cycles do you have free between what you are doing to keep the colors going? Is there enough to make the blocks "slide" or is the overhead of all the VDG switching stuff too much?
ReplyDeleteThere are a few cycles available during each line, but any new operations would have to be very thinly sliced to be in there. I am doing the block movement after the end of the visible screen.
ReplyDeleteMaking them slide could be done by moving the blocks a little bit (e.g. one line) at a time. I think there is enough time to do that, but I'm not sure it is worth the programmer time to do that -- I kinda like the instant jump. :-) I might look into doing it that way when I get a bit farther along with the rest of it...
Was thinking a bit more, and the above was only considering moving up and down. Moving sideways would be a bit trickier, since crossing certain borders could require a choice between conflicting CSS values. Again, it could be done -- but I'm not sure that it is worth the time to do it when it wouldn't obviously look any better and would just take longer to make a move during the game.
DeleteThat sounds pretty awesome!
ReplyDelete