Chapter 17 - November 03, 2014

The new Map Editor

The shift from a vector based map system to the new tile based system has meant a new Map Editor is required.

I could use one of the many modern tools available on the internet utilizing my PC and then transferring the generated data to the CoCo but this goes against the spirit of what I am trying to do. My scope right from the start was to create this program the way I did back in the late 80's utilizing the CoCo3 for much of the development and using other resources that were also available back in the day.

"The Journey is the Reward"

Many would view this as crazy but this project has always been about the nostalgia of programming the CoCo and trying to achieve the best game I am capable within that framework (and within my available spare time!). There is little monetary incentive nor is there any urgency to release it. Documenting the journey via this blog and allowing people to see the creative and technical work involved to create a commercial grade game is my primary focus.

For the Map Editor, I once again have chosen to create it using BASIC. It's an easy to use and versatile programming language. It has it's quirks and problems but a good programmer works within these obstacles and understands how to work around it's limitations.

The first limitation I discovered was that I needed a vertical screen height greater than 192 lines.

The scrolling area of my game utilizes five 8K MMU memory blocks (with another non-scrolling 8K block above and another non-scrolling 8K block below). Each block occupies 32 lines of 256 bytes (Horizontal Virtual Enabled) which adds up to a total of 160 lines (32 lines x 5 blocks).

I wanted to have a clear view of the scrollable region displayed as a160 byte (320 pixels) wide page with the ability to page scroll to see the entire planned 80 pages of map. That left 32 lines free for displaying my tile palette. My tiles occupy 1 x 8K MMU block that stores 60 tiles of 16 x 16 pixels each. That's 3 rows of 20 tiles which amounts to 48 lines.

Warning bells!

48 lines?! That means I can only fit 2 rows of tiles with the 32 available lines! What am I going to do?

I had two solutions.

One was to reduce the map viewable width and put a vertical row of tiles there to the right of the map area. This would work but means narrowing my map viewing window. Not a problem but I thought I'd try another idea first.

My second idea was to enlarge BASIC's vertical resolution. We know that the CoCo3 is capable of displaying up to 225 lines, I use this in my game. 225 lines utilizes more of the screen area making the display image taller and square'er and the black border regions at the top and bottom of the screen are smaller and match the borders on the left and right side of the screen.

I recall reading that there were some POKE's available that would force BASIC to use more lines and after digging through my literature, found those magic POKE's. Unfortunately, they only extended the screen to 200 lines which still falls short for displaying 3 rows of 16 x 16 tiles. I needed at least 208 lines.

I summon the great CoCo wizard!

This is when I contacted the great wizard of CoCo solutions. If there was someone who possessed the gift of divine debugging and could call upon his magical powers to reveal a solution, it was Robert Gault!

Robert worked out how to coax the CoCo3 to use all 225 lines and found modifications to make most of the graphics command use this resolution, in particular the HGET and HPUT commands which I needed for this program.

The resultant POKE's are listed below. They are not quite perfect. Almost everytime I first RUN my program, it will stop with an error but RUNning a second time always seems to start correctly. The problem stems from the HPUT anmd HGET buffers which required relocation. Seems like something still doesn't initialize correctly on first RUN but sorts itself out to start correctly on the next RUN.

Maybe someone can explore these POKE's and optimize them further? I certainly had no trouble running my program after the initial error.


;HSCREEN2 modified for 320x225x16


;Extend TASK1 for screen

POKE &HE6C0,112

;New vertical midpoint

POKE &HE7BA,225:POKE &HE7BE,225-1
POKE &HEB75,255-1:POKE &HEF8F,28-1
POKE &HF526,255-1

;New maximum Y values


;New HCLR by toggling TASK1


;Switch HGET/HPUT buffer to block 55


So now I had 225 lines, 17 more than what I needed so I decided to use the additional lines as a status and command display line at the bottom of the screen.

The fruits of my labour

The results are impressive. I wish Tandy had written the BASIC in the CoCo3 to use this resolution or at least included modes to switch between 192 and 225 lines. It didn't require many changes and all of BASIC's graphics routines can adapt to using it quite well. Our CoCo3 would then have been spec'd as a 320/640 x 225 system making it higher than most comparable 8 bit computers of the time. Then again, booting to an 80 column screen would have been nice too, making the CoCo3 actually appear to be a more powerful system than its 32x16 column "green screen" would suggest and clearly distinguish it as not being just a perked up CoCo2 to the average onlooker. Even OS-9 could have used this higher density screen but I guess Tandy were trying to maintain a level of CoCo 1/2 compatibility and similarity so stuck to the 192 line standard.




The screen on the left shows the 20 x 10 tile map display taking up most of the top area of the screen. Below it (under the white dividing line) is a 20 x 3 tile display of the assigned tiles. Note that I have not drawn all the tiles yet with the undrawn areas shown as a blue checkerboard pattern.

Below that again is the status and command line with the command prompt on the left and the page number display on the right. I plan to have at least 80 pages  of scrolling landscape, maybe even more depending on how the data compression works. The keyboard commands for the command prompt are as follows:

















The map data that is generated is stored in an uncompressed format for easy editing. I have allocated 2 x 8K MMU blocks to store this which translates to 80 pages (40 per block). In my game I am allocating only 1 x 8K MMU block so I needed to define a compression format to get all 80 screens to fit into the single block. The right hand image above shows the compression command in operation. After pressing the 'C' command for Compress MapData, the program reads the uncompressed data and creates the compressed equivalent on the display.


In my example above, I have only created 3 of the 80 screens and you can see some random looking data at the top of the screen. This is the compressed data. Once finished, you are displayed the compression stats below. You can see that the uncompressed size of the 3 screens take up 440 bytes while the compressed data of those 3 screens occupy 204 bytes.


That's just under half, proving that my compression is working and that I will achieve the desired 80 page goal and possibly exceed it.

Coming up next

I will not be creating all the 80 screens or defining the remaining tiles just yet. The purpose of getting the Map Editor up and running now was to finalise the design of the compression format and define a few tiles and screens that I can use when I write the actual game code for the scrolling landscape.

With some data now created, it's time to move on to the code!



Copyright 2013 by Nickolas Marentes