Bug#727781: zsnes: Fatal error when loading state (DSP-1 ROM)

[Etienne Millon]

Just an update.

The copying code makes some assumptions about the object code that
don't hold true with a "modern compiler" (it's hard to know for how
long it's been broken, though).

For example consider the following line:

> copy_func(&buffer, &Op02FX, 11*4+3*4+28*8+128);

The intent is probably to copy global variables as a block. The 11
first words refer to the following variables defined in zstate.c:
(2 bytes for each variable and 2 bytes of padding)

> short Op02FX;
> short Op02FY;
> short Op02FZ;
> short Op02LFE;
> short Op02LES;
> short Op02AAS;
> short Op02AZS;
> short Op02VOF;
> short Op02VVA;
> short Op02CX;
> short Op02CY;

(I don't really know what the 3*4+28*8 refer to, but there seem to be
128 bytes of padding after each block)

However, the memory layout is different than what's in the file:

> 0x890b208 <Op02FX>:     0
> 0x890b20a <Op14Zr>:     0
> 0x890b20c <CosAzs>:     0
> 0x890b20e <Op03F>:      0
> 0x890b210 <Op06H>:      0
> 0x890b212 <Op28R>:      0
> 0x890b214 <Op06X>:      0
> 0x890b216 <SinAas>:     0
> 0x890b218 <Op23Z>:      0

(BTW if someone knows how to print the above global layout in an
automated way, I'm interested. The above is just done by hand with
gdb)

The solution of copying variable by variable does surprisingly not
work, presumably because some data originally copied through those
bytes of padding (accessed Op02FX, Op0AVS and Op06X) has a different
layout.

However, keeping this hack for only Op02FX allows loading to work,
at least in my tests. But some state may be missed.

The "good" solution would be to refactor the code to use a global
struct for DSP1 state but this is a bit of work. Interestingly enough,
dsp1proc.asm internally uses a 16 word DSP1VARS "structure" that may
be copied instead.

-- 
Etienne Millon