User Defined Gibberish

I've adjusted BSOD so that it uses CHARPLOT instead of STROUT, which took about an hour to do, and it's working fine again - so I'm finally free of that particular ROM routine and its' little temper tantrum caused by my Zero Page usage. Which meant I could return to the code to draw the main gameplay screen, which is pretty straight-forward. It's at this point that things start to get interesting, because the game now switches to a UDG (User Defined Graphics) characterset.

I yanked the chunk of binary data for the UDGs from the original game (which are stashed above the BASIC code at $1C00) and simply 'include' that as a block of data at the same place in the Assembler code - my current high-water-mark is at around $1400 or so, which means I have lots of room before I might start to encroach on that memory area. Since the original game doesn't climb that high, I have no significant worries that the 6502 code will get anywhere near it either. Which makes the problem I'm tackling all the more puzzling.

The character data looks fine in CharPad, a nifty little Windows utility written for designing maps, sprites and UDGs for the C64, and which handles VIC-20 UDGs just as neatly. But oddly, the first six characters - @, A, B, C, D and E - have some minor corruption when I display them in the game. Everything after that is exactly as CharPad shows them, but those first six (48 bytes) are slightly, but not entirely, damaged.

My suspicion is that something somewhere is splatting some random values over those memory locations - but the game is barely doing anything yet, and there just doesn't appear to be anything going remotely near that block of data. So I'm going to write a little test program to just pull the characterset in and display it without any other code to possibly injure it, and see what it looks like. If I'm right, and there's something in the Meanies code that's misbehaving, those six characters will look OK.

Of course, if that's the case, I'll have to do some careful tracing to see what is going wrong in the game, as I really am pretty confident that there just isn't anything that I'm doing that could cause the problem. If it is the game code, it must be something to do with the way the BASIC stub line is being constructed that is causing some bizarre side-effect. On the other hand, if the characters are still corrupted even in my test code, that means that DASM is doing something odd when it includes the data at assembly time - and that could be a really nasty one to resolve.

I'm hoping to run the test code in the next day or so to see what light it sheds on the problem. It's a tricky one...