Core Dump - Work In Progress
February 16, 1998 : A day of debugging
I had some frustrating moments last week as things started to break down. I had just been happily coding away at the "difficulty settings" program. And then I threw a grenade.
Nothing special about throwing a grenade. It had been working perfectly from day one. So why try them now? Well, for the opening stage I had to redraw them, and I wanted to check how the new grenade looked.
Either the next frame was taking an hour to construct (while ignoring the music routines), or my MSX had crashed horribly. Hmmms. Let me try this again. Reboot the computer. Restart. Throw a grenade.
Well that narrows it down to the red circle explosion. But I haven't changed that code for months, so it must be caused by something else in turn. I have added hundreds of lines of code since last time I threw a grenade, so I have to be careful. Think, Cas, think!
Back to the red-circle explosion. No errors. Well, for safety, I'll just change this bit of code and that bit...
No errors. Good. So now I can run it, phew, let's hope that error has mysteriously gone (although I haven't changed anything, really). Cross my fingers....
Wait a minute!!scroll.com is supposed to go from 8000 to AFFF, not up to B180! At B000, some sprite maps start. Shock horror! Check the source code... indeed, the red-circle explosion code is the last in the file. When the sprite map is loaded (later on), the explosion code is overwritten.
Well that solves it. The code has become too big. It can't fit here. That caused the error. Usually, I check the length (that is why those "*l+" commands are there at the end) but most of the time I don't really look at the number. Not that this is a real problem. At the moment, there is still some memory left (about 8kB), and I can shift routines around through the mapper pages (at the cost of some speed).
You can imagine, days like these make you 10 years older. And then I have to say, I've been getting better at it through the years. In the days of Vectron and ARC, I had practically more errors than working code. At this point, errors are quite rare. But when they turn up... I can tell you, it gets my pulse racing.
Quite often errors (or BUGS, as they are also known) are caused my this kind of stupid tricks. Or sometimes you mistype ("or" instead of "xor" caused the password-recognition error in Black Cyclon..) or sometimes you're just not careful enough. Coding a big program means that many things influence all parts of the program.
So, when you start programming real stuff, a custom interrupt routine is often the main source of bugs, because an interrupt routine can influence almost any piece of code...