Short update

Posted by Kiwi, 30 March 2011 · 100 views

I got 4 rooms drawn and one need to made and I need to make more unique tiles for that last room of the puzzle. The 128 tiles pattern table has about 45 tiles left to be drawn. I load the pattern table right after the text pattern at address 0x0400 so the text pattern set won't be overwritten. 3 room tables(yet one room need to be entered) are entered and displayable to test what they look like on the TV screen(due to the colors.).

It appears that the 0xcf that leaked into the RAM is no longer happening, I had one multiplication in this game I have missed. Now majority of the fill_vram() tiling method has been converted to putframe() format. The one left alone were the 6 fill_vram(0x19xx,0xDD,9) statement method tiling. I'm still paranoia about the reset loop, but hopefully it will get to the end of the game before that happens.

Going to get some sleep since I got work in the morning.

bfg.gamepassion
Apr 1 2011 5:48 AM

Don't understand your reset loop problem ... I've never seen this bug in any of my 3 games during coding. (And God know that i've seen many bug

)

Report

Kiwi
Apr 2 2011 3:11 PM

I programmed the game to the point where it would load the logo screen and then reboot at the title screen. I posted a thread on the programming forums about this. They stated if the the RAM get full, the game resets. It took me awhile to attempt to fix that problem after I saw your NMI issue post on the programming forum, which help me figured out what may have caused it. There was a memory leaking and filling up the RAM when I only assigned a few variable to it. There's a blog post with a picture of the debug where there value CF would insert itself at boot up. There's a lot of graphics in this game and they are constant on cartridge.

Newcoleco mentioned about the multiplication and 8-bit system tend to not like doing multiplication since it would run out of cycle if the multication is too big. Multication got elimated since it was used to producally tile graphics. Newcoleco also mentioned put_frame() routine in his post as well. It blew my mind(I am over using that word ><) that I could have used that routine and try to tile the graphic box with fill_vram() function. I would producally tile the graphics. I changed most of the scene to use put_frame(), and the ROM size decrease a lot. I add a void fill_zero{}; to fill up the bottom of the cartridge with 00 instead of FF, thinking that may help a bit. Variable filesize may have confuse the Colecovision since it is looking for 16KB, 24KB, and 32KB cart size.

Now the game feels like it is disable_NMI() since it is a lot quicker. Make me think it'll reset loop again. It's a wierd bug and I'm adding stuff to the game now to make it to the end and hopefully it'll reach the 32KB limit with enough content for the player to enjoy.