Re: [hatari-devel] WinUAE core freeze with ST emulation, solved but another question about gemdos drive.

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On keskiviikko 18 tammikuu 2012, Laurent Sallafranque wrote:
> I've uploaded the patch which fix the problem.
> 
> Maybe I can use MODECHANGE in check_prefs_changed_cpu() instead of
> SPCFLAG_BRK, and adapt m68k_run.
> Like this, we would have SPCFLAG_BRK in M68000_Reset and I could
> simplify the code (I would also have to adapt m68k_go)
> 
> This would be closer to the old cpu but it changes WINUAE cpu code.
> Thomas, it's a you want.
> 
> For the Gemdos part, I've had a quick look.
> I didn't know this part of the code :)
> 
> I think you're right: when there's a change of cpu, newcpu calls
> build_cpufunctbl() which reinitialise the opcodes table.
> There must be an init to call after, but I don't know well the gemdos
> code.

The opcodes are set by the Cartridge code that puts the asm code into
ST RAM and modifies the opcode table in Cart_ResetImage(), which is
called by Reset_ST() on cold resets.


> What is strange is that when I return to the CPU I booted on, I get back
> the gemdos drive (I thought that calling build_cpufunctbl() would erase
> the GEMDOS "opcode").
> 
> That's not a big problem as the change of CPU was, but I think it would
> be nice to have it fixed too.


	- Eero