Just to be sure everything is OK, at the end of DSP_Reset, there's
save_cycles = 0;
We must be sure that this value is not too high (I don't know why ;),
or the DSP may execute a lot of instructions after restoring the
snapshot (this value is peharps saved into the snapshot too)
In dsp_core_reset, there's a call to dsp56k_init_cpu(void)
void dsp56k_init_cpu(void)
{
dsp56k_disasm_init();
isDsp_in_disasm_mode = false;
start_time = SDL_GetTicks();
num_inst = 0;
}
Which inits a few things, the most import is the disasm_init pointer
which initiates the disasembler pointer to dsp_core if I remenber well
(for DSP traces and disasm).
This may crash hatari if we try to debug DSP code after a snapshot
reload and this variable is not set, I haven't verified.
Laurent
Le 03/01/2015 18:38, Nicolas Pomarède a écrit :
Le 03/01/2015 17:23, Nicolas Pomarède a écrit :
So, latest changes prevented the crash, but it was not correct, I will
change it do not call DSP_Init after the snapshot is loaded.
This seems to be OK now.
- DSP_Init is only called at start and doesn't modify bDspEnabled,
it only inits the DSP (DSP_Init() is now called in all mode, but we
don't want to enable it for STF for example)
- I added DSP_Enable / DSP_Disable to really enable/disable DSP
emulation. These functions should be called when changing config
instead of calling DSP_Init/DSP_UnInit.
- I also remove the call to DSP_Reset when restoring the snapshot ;
from what I can see it reset some variables in dsp_core, but as
dsp_core is loaded right after, the reset seems useless.
Tested with GemPlay, I can now reload a snapshot and still use the
DSP and its program (but maybe some corner cases are remaining)
Nicolas