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

[ Thread Index | Date Index | More Archives ]

Le 16/10/2015 21:35, Anders Eriksson a écrit :

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:

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.


thanks for your test program, that's very handy, as we say, an image is worth a thousand words :)

It's also similar to some test programs I wrote to check color/pixels alignement with different overscan modes, but I didn't write a test program yet to observe pixels near the borders' limit.

I confirm your results :
- the 4 px (230) or 8 px (224) shift to the left was expected to be correct, as I measured it with one of my test program on real STF/STE.

- the 4 px / 8 px on the right are not hardcoded, but they're a direct result of shifting to the left without "entering" new pixels to the right.

- as you see hatari displays 4 more visible pixels than STF on the right, that's because the stabilizer is not emulated. If it were, the hi switch would indeed turn more pixels to black (more or less, it's the result of decoding bitplanes in monochrome during a few cycles). Hard to fix at the moment.

- for ste 224 bytes, your image shows there should be no truncation, this means that when shifting 8 px to the left for alignement, I should fill the rightmost pixels with bitplanes' content instead of leaving color 0. This should be possible to fix.

- good news that ste 224 bytes displays color 0 in the 8 left most pixels, that's one things less to fix :) In the case of photochrome this means that those colors' changes would be visible too on a CRT monitor, depending on how the screen is stretched horizontally, so maybe that's something to fix in photochrome.

- regarding changing color before line 33, this is a hardcoded limit at the moment, this should be improved.

- regarding the 2 extra lines in the bottom, I think the famous overscan articles by Alien/ST CNX mentioned some STs had those 2 extra lines, but it seems it's not the most common case. Or maybe those 2 lines can really be displayed, but most people had a CRT monitor that didn't show them, so no one bothered to put usable pixels there ? I need to check this on my STF, as it's a model that works with all demos, its timings can often be trusted.

I'm adding all this on my TODO list, but don't expect changes too soon, I'm busy with the CPU core at the moment ;)


Mail converted by MHonArc 2.6.19+