SpritesMind.Net

Is there something special about anything in this block of ram space???
Before going further, I'll say that I already found a workaround by writing to 0x00FF0045E. But when trying to load a long array of bytes seemingly anywhere from 0x00FF03F8 to 0x00FF045C as a starting address I get an odd crash. It's odd because the entire array copies over successfully, and the program continues like normal for maybe a total of 10 vblanks. Then it crashes. Also worth noting, is that this array is only copied over before the main loop. I checked all of my globals and ram map and everything is in the clear there. So what could possibly cause this strange problem? I hate wasting ram space. I'm probably going to need as much as I can get for the tracker.

I'm so confused...

The only thing I can think of on my end is that I overwrote something important in a register somewhere, but I'm being extra careful on that one. And since simply changing the global that dictates where that array goes fixed the crashing problem, I'd venture to say that I didn't in fact overwrite an important value in a register. Is this some kind of a Genesis quirk?

Also that entire block of ram space is nothing but zeros... So I'm very, very confused as to why writing there would cause this crash.

All RAM is ordinary.
Try to debug in emulator you like, I like my mod of gens rerecording.

find bug in your code yourself.

I actually think I may have figured out the problem. Bugs can be tricky to find!

Watch out for address errors. Those are the bugs I run into the most!

powerofrecall wrote:Watch out for address errors. Those are the bugs I run into the most!

Tell me about it. This one was really tricky to find, I actually ran into the problem code by mistake (luckily).

I ran into another issue today, I was tempted to ask for help but I stuck to it this time. I'm not going to learn much by having everyone do things for me. But for the people that have helped, I ought to add a special thanks section in the "about" section of the tracker.

Count SymphoniC wrote:

powerofrecall wrote:Watch out for address errors. Those are the bugs I run into the most!

Tell me about it. This one was really tricky to find, I actually ran into the problem code by mistake (luckily).

I ran into another issue today, I was tempted to ask for help but I stuck to it this time. I'm not going to learn much by having everyone do things for me. But for the people that have helped, I ought to add a special thanks section in the "about" section of the tracker.

We'd still be interested in hearing the problems you had and how you solved them

This board isn't busy enough as is, so if you come across something and solve it, I agree--it's worth posting about! Sometimes people can learn from others' mistakes, too.

Well the issue I had and fixed in relation to this topic, was actually several. Mostly with my tile drawing loops. One of them was harmless but was drawing garbage to Plane A underneath the bottom of the screen, fixing my loop counter fixed that. Same thing with the loop that draws the FM1-PSG4 columns on the song screen. It was drawing extra columns that were reading table/array data that didn't exist, because the array never went that far. Of course this one was tricky to find because 0x00 shows up as a transparent tile, but when I changed the offset for my font then everything became clear. There might have been more but fixing these lead to the fix my memory crash. Which I can't remember exactly what did it, I spend too much time doing this stuff.

The snag I ran into yesterday which is unrelated was causing incorrect loading and drawing of my Chain data array. See the starting address for this array is actually dynamic, because what part of the array we're drawing on the screen actually depends on what value in which slot we used on the Song screen. I had to come up with what seemed like some crazy functions to make it happen. Because the array stores the row ID in word, and the value in word. The value is directly written for use with the font to display useful numbers. So when you see 3A on the screen, the value in code is actually 13, 21 in hex. So I had to come up with an algorithm to subtract ten from each byte of the value, to turn it into a normal number, or if it's a hex letter, subtract 17 to turn it into a normal hex letter. Then I had to rotate some bits and combine the result into one byte. That byte is then multiplied by 8, which combined with the starting address of the Chain table array gives us our dynamic starting address for which part of the array needs to be loaded. It was trying to LEA that address that failed, because I was loading a pointer to a pointer, where my snag was. But it turns out that I forgot one simple part to my code to make it all work. So although I changed LEA into something like:
.... it may very well be that I was doing it wrong before we even get to this point. Because the address was changing whenever the cursor moved. Which was not good, I needed that address to only be loaded when we were switching from the Song screen to the Chain editor. Some simple repositioning of code fixed that. Sometimes I forget that all this code isn't happening all at once, but is in fact being read by the cpu line by line at a high rate of speed.... WHEW!

This is why I don't explain things, I get very long winded sometimes...