Re: [hatari-devel] TT mono mode Timer-C problem

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 17/12/2011 11:29, Laurent Sallafranque wrote:
> Hi,
>
> That's a big question I have also in mind since a few weeks, but as for
> now the priority is on the ST demos debugging, I didn't want to bother.
>
> I don't like the fact to divide cycles by 2 or 4 to change the CPU
> speed, as timers are impacted.
> It may explain the difficulty to synch well the crossbar in all cpu
> spped modes and same for the DSP.
>
> I would enjoy to have a normal cycles CPU with correct cycles in all
> case and VBL timings changing according to the real number.
> The timers would be "static" 500 Khz, 25 Mhz, 32 Mhz, ...
>
> Let's see this after the 1.6

Hello

except this is very difficult to do ; there's no magic involved in a 
real ST, if you change the cpu freq (by changing the analog cristal used 
to get the master 32 Mhz freq), many things won't work anymore :
 - video will not work, because the vbl/hbl timings are coming from the 
master clock
 - ym2149 will sound wrong for the same reason
 - fdc won't work correctly (the 8 Mhz freq is derived from the master 
32 MHz freq)
 - mfp will still work, because it uses another cristal -> that's what 
I need to change to keep correct mfp timings

So, as a real ST "chooses" one of its components to be the master freq 
for all other clocks and then divide by 2, 4, 8, etc. to get "sub" 
clocks, we need to do the same in the emulation.

Emulating a real bus would require to emulate a 32 MHz component, it 
would be really costy in term of performance. So, the choice made in 
many (all ?) emulators is to use the cpu freq as the main freq.

Theorically, there should be no noticeable error when doing so, it's 
perfectly possible to emulate all other components that are an integer 
multiple of the cpu freq (mfp for example doesn't fall in this category, 
it has its own external cristal). If there're error, then it's due to 
error in the emulation itself, not in the choice of the cpu as the main 
freq.

The way we do it in Hatari is correct, it's just that some abstraction 
layers to transform one freq into another and keep correct ratio when 
changing cpu speed were never really put in place, because they mostly 
concern falcon emulation and focus was on STF/STE emulation.


> Nicolas, I don't think I'll have to change more things before the 1.6,
> so, you can release as it is for the falcon part for now.
> (There's still too much work on the 68030 cycles to expect something in
> the next week).

OK, I'd like to complete a few things, but I might have some spare time 
in 7-10 days to do a release.

bye

Nicolas