Overview Core Dump - Work In Progress Episode 57 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. shwwwww....ieeeee...brrg-CRASH- Uh oh. 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. shwwwww....ieeeee...brrg-CRASH- Not good. Ok. Analysis. The program crashes when the grenade hits the ground. Grenade hitting ground causes a "red circle" explosion. Red Circle explosion is used by more weapons. Okay. The next logical step is to see if other "red circle" type weapons cause the computer to crash as well. Reboot. Restart. Put down a plastic explosive. Press fire.... -CRASH- 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! I changed the insert-/delete object routines drastically. These are used by the red circle explosions. I can't think of anything else relevant to the red-circle routine that has changed. It is an isolated piece of code. If a routine is so screwed up that it destroys some other code by changing RAM that it's not supposed to change,... I will be in big trouble. Really. It could be anything then. Then I will find that out later, because it is easier to exclude the insert/delete routines first. Assumption: I am a good programmer. If some other part of the program destroys the red circle explosion routine, then that's quite stupid, and I would not be a good programmer. Therefore, the red circle explosion is not destroyed by some other part of the program. After skimming through the new insert-/delete object routines for over an hour, I couldn't find anything wrong. Darn! What the blazes is going on here?? Back to the red-circle explosion. No errors. Well, for safety, I'll just change this bit of code and that bit... GEN80 bla bla Copyright .... Source file: scroll.gen *warning* ORGs used: 1 *l+ B180 after equ $ *l- 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... Well I survived this bit. Let's hope it doesn't happen again, because it's not good for my health. Go on... Read the previous entry