Sprite Loading format

I do see the problem, course I manged to fix the main broke one, and break 6 others in the process. Does prove for a fact that it is a problem, if not THE problem. The table at C2 might also become an issue, but getting to it has to come first.

That solves the mystery, just a matter of coming up with the propper solution.

Thanks!

---

I can get some of it to work, but it looks to be holding some garbage over after the first character slot or three.

Since I'm using Eggers' Expanded Palettes this peticular code isn't where it normally should be but is mostly unchanged in that spot.
Starts at line #89 in his ASM file.

Code:

C1/3D56:
LDA $14
ASL A
CLC
ADC $14
TAX

LDA #$C2
STA $16
PHB
LDA #$7F
PLB
LDA>$410002,X
STA $12
REP #$20

That probably isn't much help but anyway, the problem is when it does the ADC $14 the created offset goes beyond 8-bit handling. I tried to put it in 16-bit for those calculations (just after the LDA $14) and it will crash with just that. Adding a SEP#$20 after the TAX then will keep it from crashing and keep the proper values in X for awhile, by the thrid or fourth character slot (repeating this line of code) it will load... junk at the ADC $14. Depending on how I arrange the character to load, sometimes it will have junk on the third pass (resulting in a bad offset and glitched sprite) and run clean on the fourth pass. Rearrange the same characters and it will produce a junk value on the fourth pass. All values/math seem to be correct until it gets to the ADC $14 (even on the passes that glitch).

I keep looking to see if it would be possible to move that calculation down below where it normally does the REP #$20 but every time I think of a way I find an obvious reason it won't work.

Not sure where the "junk" value is coming from, or why it isn't consistantly showing up on the same pass every time, and not sure how to get around it.

On a related subject: How do you tell a compiler to use a C9 instead of a C5 for a CMP?