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

On 16 October 2015 at 20:35, Anders Eriksson <ae@xxxxxx> wrote:

Hello, this is a topic that can give anyone grey hair :)

So just to end all doubts, I did a little test program that tries to show a 448*249 image using two methods;

1. Normal 230-byte ST overscan with stabilizer at the end
2. Faster 224-byte STe overscan without stabilizer

Here are the files: http://files.dhs.nu/files_coding/fullsize/

I've made screenshots from Hatari and made PAL dumps from my STe through a DV recorder (JVC GRD30) via composite cable (blurry image!).

The image in the test have 16*16 squares with the background colour visible through it. The background colour is set as following:

1. Black from vbl
2. Purple from Timer-A trigger
3. Grey after hardsync
4. Yellow after overscan display (never visible)

ST 230-byte overscan
--------------------

Real STe-machine:

a) The image is shifted four pixels left which kills off the leftmost four pixels of the image. Good to remember for anyone doing ST fullscreen pictures: add 4 pixels empty at the left.

b) About 8 pixels at the right are killed due to the stabilizer, leaving 408 usable pixels per line.

c) The number of scanlines of ST graphics visible seems to be 272 lines plus syncline, so 273 total. Lots of scanlines above that are visible, but no way to put graphics except plasma and rasters.

Hatari 1.9.0:

a) Image is shifted 4 px to the left, correctly.

b) About 4px at the right border are killed due to the stabilizer, leaving 412 usable pixels per line. I have a feeling these 4 pixels are a hardcoded thing due to the 4px left shift?

c) The number of scanlines are 275 plus syncline. Nothing visible above syncline, my hatari screenshots have the black top border added for easier comparison to the real machine.

STe 224-byte overscan
---------------------

Real STe-machine:

a) Image is shifted 8px to the right. The empty pixels at the left are NOT "dead" pixels, the background colour works there.

b) No truncation at the right border as there's no stabilizer, generating a 408 pixels line.

c) See 230-byte example

Hatari 1.9.0:

a) Image is shifted correctly, background colour is working in the remaining 8px left border. All good.

b) Right border is clipped 8px as well. This is not correct.

c) See 230-byte example.

Ok, sorry for the lengthy mail, some conclusions and thoughts:

1. Hatari shouldn't cut out the 4 pixels at the right border in 230 byte overscans, better have real "blackout" pixel emulation later.

2. Hatari should definitly never cut out anything in the right border on STe 224-byte overscans.

3. It would be quite neat to be able to see all 288 PAL-lines in Hatari (as an option?) there might be plasma/raster screens using these lines. Also a 320*200 screen would look better centered as well.

4. Number of scanlines, this is weird. Maybe the DV device captures too early in the VBL and gets a couple of lines too many at the top, and a couple too few at the bottom? I remember back in the day (early 90's) we used all kinds of strange monitors to determine the visible lines and we ended up with 274 visible lines, including syncline. So I'm one short here :)

5. To be on the safe side when doing fullscreen pics; keep it 400*272, or maybe smarter 270 height (hint; *4 = 1080..). By keeping it 400px it can also be centered properly.

6. Hatari is still amazingly accurate, these are really final small details that nobody would see with normal monitor settings.

It would be nice to see Troeds magic monitor showing more space than my DV capture did :) The programs, sourcecode, picture and picture converter are in the archive linked to above.

--
Anders Eriksson
ae@xxxxxx http://www.dhs.nu/
ae@xxxxxxxxx http://www.atari.org/