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.