Notice on differences between emulator colors for 32x

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Post Reply
ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Notice on differences between emulator colors for 32x

Post by ammianus » Sun Jun 10, 2012 3:40 pm

I've been struggling with this bug for a while in my code and finally figured out how to resolve it, maybe it will be useful for the next person who comes across it.

My 32X game is using 8bpp (aka 256 color, aka packed pixel mode). I am generating the images used in my game, as well as a common color palette using sixpack utility. The game displays the colors correctly in K-Fusion 3.64 emulator but has completely off colors in any of the Gens mods (Gens/GS r7). I couldn't figure out why the difference for the same exact data and code.

Example here is the binary data of my generated palette file (carcasssonne.pal)
Image
And here is the first 10 colors loaded into the CRAM in both emulators respectively. Fusion on the left.
Image

I couldn't figure out why the data in Gens appeared to be off by a word, which caused all the colors in the CRAM to be incorrect.

Turns out the palette data was not word aligned.

In my .map file I can see that this is the address of my palette pointer was this
0x000000000200af17

Adding an .align in my map file before the palette .globl solved it for me e.g.

Code: Select all

.align 2
_palettec:
.incbin "carcasssonne.pal"
_palettec_end:
This results in the address of 0x000000000200af18 and the colors load correctly

Now I am starting to suspect what other data might need to be word aligned for Gens to work correctly.

I guess is Gens closer to hardware in this respect? One thing to keep in mind if using Fusion.

FYI the code to load the above palette data was:

Code: Select all

void loadPalette(const vu16 *paletteStart, const vu16 *paletteEnd, const int paletteOffset)
{
	int numColors;
	int i;
	vu16 *cram16 = &MARS_CRAM;
	vu16 *pal16 = (vu16*) paletteStart;
	
	numColors = ((paletteEnd)-(paletteStart));
	for (i = paletteOffset; i < numColors+paletteOffset; i++)
	{
		cram16[i] = pal16[i-paletteOffset] & 0x7FFF;
	}
}

TapamN
Interested
Posts: 15
Joined: Mon Apr 25, 2011 1:05 am

Post by TapamN » Sun Jun 10, 2012 5:41 pm

Doing unaligned accesses would have crashed on real hardware. The fact that both got to displaying anything means neither are accurate.

It would probably be a good idea for someone to make a version of Gens for development that traps unaligned accesses.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Jun 10, 2012 5:41 pm

This is why I test on real hardware... you'd have found the problem quick as it would have blown up - the SH2 cannot read/write words to odd addresses. Emulators ignore such things for better speed, assuming the program will be correct. So testing on emulators doesn't always tell you all you need to know about how your program is working.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sun Jun 10, 2012 8:22 pm

Chilly Willy wrote:This is why I test on real hardware... you'd have found the problem quick as it would have blown up - the SH2 cannot read/write words to odd addresses. Emulators ignore such things for better speed, assuming the program will be correct. So testing on emulators doesn't always tell you all you need to know about how your program is working.
I still don't have a cart to test on my 32x that is sitting in my basement, will be nice to have eventually.

In this case, any time we use the .globl in a .s file, to include some binary data we should automatically put .align before it? I think some of the example code I started with didn't have that.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Jun 10, 2012 11:07 pm

If you're not sure of the alignment, always align the PC before code or data that consists of words and/or longs.

Post Reply