Re: [hatari-devel] Re: Hatari Debugger & GUI

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 15/05/2018 à 00:19, Eero Tamminen a écrit :

> > 3. I'd like to see the current ray position
> > Let's say 1 is implemented. Having the option to see a little (red or 
> > whatever is necessary to see it) dot at the current ray position would 
> > be swell. I'll have to check if Hatari already has current line length 
> > in cycles somewhere, but if it has, I could implement sth like that.
>
> Nicolas might be interested also about that.
>
>
> > Q: Is there anything you can think of that would (technically) prevent 
> > such an option ?
>
> No.
>
>
> > Q: Does sth like Mr Nis E-Clock-sync via 60Hz lines affect the mapping 
> > of the current cycle=>SDL surface pixel or can I rely on current line 
> > count and line start Hatari provides?
>
> Probably better to ask Nicolas about that.

Hi

There's already sthg like under Steem : when debugger is invoked, a red 
mark is drawn at the position where current video pos is supposed to be.

But under Hatari, the rendering is deferred until the current frame is 
complete. Also each line is only drawn the the end of the corresponding 
hbl, any intermediate change won't be updated on screen.

This means that it's probably not possible to do the above red mark with 
current rendering code (and this code is too low level to be changed 
just for that).
For example, if debugger stops at one point, then you change some 
values/registers, then you restart execution for 60 cycles for example, 
you won't see any difference on screen.

Regarding the number of cycles per line, it's updated on every hbl ; for 
example you can see the cycles values printed when using "--trace cpu_all" :

cpu video_cyc=  1220 196@  2

2 will be the current hbl number
196 will be cycle position in current hbl number (=2)

Those values will take into account any preceeding 50/60 hz switch that 
could alter number of cycles per line.

Nicolas