[hatari-devel] Hatari options?

[Nicolas Pomarède]

Le 01/03/2011 22:51, Eero Tamminen a écrit :
> Hi,
>
> On tiistai 01 maaliskuu 2011, Nicolas Pomarède wrote:
>> Le 01/03/2011 20:56, Eero Tamminen a écrit :
>>> Attached patch would do that + put Laurent's additional WinAUE options
>>> under separate heading + re-order some other things more logically.
>>
>> I agree with adding most options you put, except :
>> 	--cpu-exact
>> 	--addr24  (typo : you put 42-bit mode in the man)
>
> The names of the options are from Laurent's earlier WinUAE changes,
> in the patch I just moved then under their own heading in options output
> + fixed their descriptions to conform better with other options
> descriptions.
>
> These options have been in Hatari code since last November when Laurent
> added WinAUE code.  :-)

Yes, I agree that WinUae's code has variables for these behaviours, but 
I think it's too soon to decide how to name them on the command line.


>
>> With WinUAE, there're many more modes than just cpu-exact : better
>> prefetch, better exceptions, better cycle for micro code, so adding a
>> bool option will not be enough.
>>
>> Also we already have a "--compatible" option ; I think it would not be
>> clear for the user what is the effect of "exact" compared to
>> "compatible" (in theory, if the cpu emulation is "compatible" with real
>> cpu, then it should be "exact").
>
> I was thinking that "--cycle-exact" would have been better option
> name, at least based on its description. :-)
>
> I've understood that the  (by default enabled) "--compatible" option is
> supposed also to make the old UAE core also (more) cycle exact.
> What that option actually does with the WinAUE core?

AFAIR, it does better prefetch accuracy and better cycle counting. But 
WinUAE has another more advanced mode (cycle exact) where each 68000 
instruction is split in 2 or 4 cycles "sub instruction" to update all 
hardware components every 2 or 4 cycles (whereas today we update 
hardware only at the end of the whole 68000 instruction).

I need to dig into the code some day to refresh my memory and make a 
list of all possible modes with their uae's equivalents.

>
>> I'd rather have a new parameter "--cpu-emulation" for example that could
>> take several values : simple, cycle-precise, ...
>
> So these prefetch etc settings aren't independent options, but dependent
> on each other?

No, I meant there can be different values for different level of 
precision, but only one at a time (other possible value could be "jit")


Nicolas