[hatari-devel] Hatari options?

[laurent.sallafranque at free.fr]

Hi,

I think there's are some things to fix before the options :


First, the GUI :

- I think it shouldn't be possible to select atari ST and still have DSP options
selectable (the same for many parameters, like memory, blitter, ...).

- choosing a computer should set and disable some parameters automatically +
should disable some choice (ST and DSP or 14 Meg memory for example).

- from the new core, MMU seems to be only usable with 68040(I'll try to let it
run with a 68030 to see if this can work).

- idem, I've commented an option in newcpu.c (they disabled the possibility to
use better emulation with 24 bit memory).

We need to stabilize completly the new core, see how we use it, and next, adapt
the GUI and the option line.


Second, the MMU :

- before my hollidays, I did some changes to Hatari concerning MMU. It worked
better, but not well. When I launched raimbow2 multimedia (it uses MMU), I had a
illegal instruction on 4e7a (but this instruction is known in cpu31.c)

I'll have to trace and debug this to let the MMU work (maybe the try/catch is
guilty)


Third, the "cpu change on the fly bug) :

With the new core, if I select in the GUI that I want to swap from a 68030 to a
68040+MMU, the new CPU isn't taken into account.
In this case, I was running in _run_2p and I whould have swapped to run_040mmu

I remenber I had removed a parameter in the main loop of all the _run functions
in newcpu.c (something like SPECIAL_MODE or SPECIAL_FLAG).
With it, hatari never started. But I think my patch was wrong, it should be
reintegrated and try to see from where the real problem was. (I'll check this
next week).


Fourth : Videl :

I'll have a look at it after having fixed the precedent problems.

Regards

Laurent



Selon Eero Tamminen <eerot at users.berlios.de>:

> Hi,
>
> On keskiviikko 02 maaliskuu 2011, Nicolas Pomarède wrote:
> > I don't like the idea of changing existing options ;
>
> Ok, I'll leave the option names as-is and don't add WinAUE options to manual
> page.  However, the question I had was about the options grouping though.
>
> I was thinking that WinAUE specific options could be under their own
> heading, at least until it's more clear what they are and is the next
> release going to be using just WinAUE CPU core or also old UAE one.
>
> If they aren't under separate heading:
> - the MMU option should go under CPU as MMU is part of that.
> - FPU could be under either CPU or System as in 040 FPU is part of the CPU,
>   but on earlier CPU models it's a separate chip.
> - If addressing mode setting is needed, it could be under System I guess.
>
> (After that System section would have quite a lot of options, but I think
> keymap option would belong better under generic options.)
>
>
> Btw. The reason why starting editing WinAUE options was that they were
> slightly broken.  They specified "bool" instead of "<bool>" (i.e. error
> handling for non- bool input values wouldn't work properly) and every option
> had explanation for what are the possible values for a bool option, although
> that's explained at the end of the Hatari usage output. :-)
>
>
> 	- Eero
>
> PS. Has anybody tested the new --desktop (Falcon/TT specific) option yet?
>
> If your monitor / LCD is very slow at the resolution switches, it should
> give more pleasant Falcon experience with demos that change the resolution
> often.  I would just like to know does it work properly for everyone or has
> somebody encountered the problem I encountered once[1].  If yes, does that
> happen also for OSX or Windows...?
>
> [1] Black screen where only mouse worked fine despite killing Hatari from
> another console.  Getting rid of that issue requires X server & X session
> restart.
>
> It seems like bug in my Linux desktop/X/Intel gfx driver. App that has been
> killed, that doesn't change resolution nor use 3D (which would bypasses X),
> shouldn't be able to do something like that.
>