|Re: [hatari-devel] WinUAE core freeze with ST emulation, solved but another question about gemdos drive.|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On torstai 31 toukokuu 2012, Thomas Huth wrote:
> diff -r f8b7da6c61de src/change.c
> --- a/src/change.c Thu May 31 23:00:07 2012 +0300
> +++ b/src/change.c Thu May 31 23:14:19 2012 +0300
> @@ -119,13 +119,17 @@
> /* Did change CPU prefetch mode? */
> - if (changed->System.bCompatibleCpu != current->System.bCompatibleCpu)
> + if (changed->System.bPrefetchCpu != current->System.bPrefetchCpu)
> return true;
> That should not be necessary. One should be able to change between the
> prefetch/non-prefetch and cycle-exact/non-cycle-exact modes without
> reset. If that does not work yet, you should rather fix the WinUAE core
> accordingly instead of forcing a reset here.
That came from Laurent.
> Also, I don't like the idea of renaming that option from "compatible
> cpu" to "prefetch cpu" because of
> a) it's also named "cpu_compatible" in the WinUAE core
> b) it's not only about enabling prefetch in the CPU core, but also some
> other things if I remember clearly (e.g. address error emulation).
> So could you please keep the old name?
The reason why I added it was that at least earlier, unlike with old UAE
core, it needed to be disabled for ST/E emulation to boot under WinUAE.
I.e. it conflicted with old UAE settings.
I probably should run TOS tester again to see whether ST booting
works now properly without disabling it.
If it does, I guess then everything else except setting Falcon
as default will be redundant from that patch...