Re: [hatari-devel] PhotoChrome v6.2-pre

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 02/11/2015 17:56, Anders Eriksson a écrit :

> You are right in your assumptions that I've not seen these demos with
> full borders visible on a real machine. I've used Hatari for development
> and bug-tested on Atari without using the PAL frame grabber.

never trust Hatari :-p

> > - sh10 invitation : the DHS logo at the end looks good, the last 4
> > pixels are made with color 0, but this seems ok as this part doesn't
> > use the 224 byte line but a 230 line from what I can see.
>
> The overscan is without stabilizer, so I've assumed it's 224 bytes. The
> screenpointer is set every line so the width could actually be wider
> without it being noticeable apart from the left border. Again I don't
> have a PAL dump to check the far borders.
>
> Here's a line of code from the overscan:
>
> http://pastebin.com/umqjSnX0

In fact, the hi/lo switch to remove left border is done at the position 
that is used on STF to do a 230 byte line, not at the position used on 
STE to do a 224 byte line. This is why Hatari consider it's a 230 byte 
line and shift the whole line 4 pixels to the left, showing 4 color-0 
pixel at the end of the line (instead of the 8 pixel shift for 224 byte 
line).

But as you say, since video address is set on each line, the stabilizer 
is not needed.

In that case where there's no stabilizer, I don't know if a real STE 
will show 4 real pixels at the end, or 4 color-0 pixels.


> > Let me know if some errors remain in some other demos.
>
> If there's an OS X build some day, I'll have a look at more demos.
> Great work!

If he has spare time, I guess Troed could provide a build with recent 
changes (it would be great to have only a build with the winuae cpu, so 
OSX people could also check that there's no regression with the new 
68000 cycle exact mode)

Nicolas