Chapter 15- September 28, 2014
GIME chip bug
Implementing the scroll was easy and would have worked on my first compile if it wasn't for some strange behaviour I noticed with scanline number 225 that had me baffled for awhile.
I am using the GIME chip's 320x225 scanline mode and I have enabled the wide 256 byte per line mode to allow for hardware horizontal scrolling. Normally a 320x200 screen occupies 160 bytes per scanline but when the Horizontal Virtual Enable (HVEN - Bit 7 of $FF9F) is activated, this changes into a 256 byte wide display although only 160 bytes are still displayed. This gives the option to scroll along this 256 byte wide space.
This mode occupies exactly 7 x 8K MMU blocks plus 1 extra line taken from the top of the 8th MMU block in the sequence.
To clarify, each 8K byte MMU block makes up 32 scanlines (displaying 160 bytes from 256 bytes). 32 scanlines muliplied by 256 equals 8192.
32 lines multiplied by 7 MMU blocks equals 224... so one would assume the last scanline (225) is taken from the 8th MMU block.
Looking at the left screenshot of my title page above, notice the white line at the bottom of the title page? This line was originally colored black so as not to be visible since my checkerboard scroll was set to work with 7 MMU blocks. I have highlighted it in white in the screenshot above. Everything worked fine with the checkerboard pattern scrolling as expected. But when I started the game then exited back to the title page, there was a black scanline a few scanlines down from the top of the screen.
I couldn't work out what was writing to this location. I checked my MMU configuration, block configuration, even did tests by gradually deleting blocks of code to close in on where it was writing this line on my screen. Nothing!
I decided to color this last scanline from black to white to make it more clearly identifiable and sure enough, the top copy of the line also changed color. I then started getting suspicious and decided to make scanline 225 a different color every time I re-entered the title page from the game (a game abort) and I found that this top scanline was always printed with the previous color of scanline 225.
It rattled me further since each time I re-entered the title page, I would actually erase the area of memory with a predefined byte yet somehow it was mirroring the erasure of that bottom scanline.
I decided to try shifting my start of screen to begin 1 scanline earlier. This means that the extra scanline is now the top scanline with the remaining 224 scanlines fitting neatly into the following 7 MMU blocks. Problem solved!
I can only assume that by having this extra scanline as the last scanline on the screen causes some confusion within the GIME counters. Maybe the video mode should have been designed for 224 scanlines then it would have fitted nicely into 7 MMU blocks rather than having this overhanging single scanline. Another bug in the GIME design?
It's important to note that my Color Computer 3 has the '87 revision GIME. I didn't test this with the '86 GIME.
I don't see this bug as being anything useful but it is important to document it so that anyone else creating software that uses 225 scanline mode is aware of this problem and knows how to get around it.
An itch that wouldn't go away!
Ever since I created the fade transition to switch from the title page to actual game screen, I've had an itch that I couldn't get rid of. I was not 100% happy with this transition. The problem is that the Color Computer 3 only has a 2 bit RGB color resolution and a fade from full intensity to zero intensity was only four steps. This was either too quick or.. if I slowed it down... too rough. I never felt it had the desired effect. Eventually it got the better of me and I decided to do something about it.
Most people would say I'm being petty and that the fade effect was good enough so why change it? But that goes against my primary directive for this project.
I am creating this game out of my personal desire to make the best game I can. My 'piece de resistance' or masterpiece. I am not under any schedule to release the game by any deadline, it's simply a personal long term project.
So I removed the fade routine completely and in it's place goes a smooth scroll routine. If you recall, I have created a smooth scrolling checkerboard pattern as a backdrop to my title page text. This is to give an Amiga'like dual plane scroll effect.
Now, when the player presses any key to start the game, this title page text smoothly scrolls down and off the screen and a new piece of text scrolls in from the top saying "Get ready!". This happens while the checkerboard pattern is still scrolling smoothly in the opposite direction. I think it looks better and has more wow factor than the previous fade effect.
Back on course
With the title page now complete to my satisfaction, I have begun the mammoth task of discarding my current vector based landscape drawing routine and begun work on a new tile based system.
The disadvantages will be that it is slower than the vector system but the big advantage is that it will allow for more detailed and impressive landscape visuals. This may take some time to perfect but I will try post a page of my progress.
Step one is to define a new mapping system and create the landscape editor to suit. Stay tuned!
Copyright 2013 by Nickolas Marentes