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

[Anders Eriksson <ae@xxxxxx>]

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/