Exact ST video timings?

[MasterOfGizmo]

I am trying to figure out the exact video timing of an ST. Values like: How many pixels is a physical line wide? How many pixels are the borders wide? Are left and right the same width? How long (in pixels) are exactly the blank and sync phases? How many physical lines (incl borders, blank and sync pahses) do the different video modes have?

This is needed since e.g. some ST games like goldrunner rely on a very precise vertical timing.

[Cyprian]

60Hz:
262 lines per frame
508 cycles per scan line

50Hz
313 lines per frame
512 cycles per scan line

that matter is not so trivial therefore I would suggest you to did in Coding subforum: http://www.atari-forum.com/viewforum.php?f=16
e.g. this very interesting thread: http://www.atari-forum.com/viewtopic.php?f=16&t=24855
on page 15, you can find timing diagrams done by Dio

[MasterOfGizmo]

60Hz:
262 lines per frame
508 cycles per scan line

50Hz
313 lines per frame
512 cycles per scan line

that matter is not so trivial therefore I would suggest you to did in Coding subforum: http://www.atari-forum.com/viewforum.php?f=16
e.g. this very interesting thread: http://www.atari-forum.com/viewtopic.php?f=16&t=24855
on page 15, you can find timing diagrams done by Dio

Nice thread, but lacks a lot of the real physical information. But maybe asking there will help. Also looking into emulator source code may answer some questions.

In my implementation i have the extra hurdle of the scan doubler built into my shifter and the width of my scan doubled video modes needs to be a multiple of 16 which 1016 isn't (1016 instead of 508 because mid rez timing also needs to be supported). But the fact that the atari timing "inside" the scan doubler is further halfed should allow this ... i need to think about this ...

Also i still have to finde the values for border widths and blank and sync widths.

Another info i am missing is the exact time a vbi/hbi is generated. At the begin or the end of the sync pulse?

[MasterOfGizmo]

50Hz
313 lines per frame
512 cycles per scan line

Where did you get that numbers from? Do both fields really have the same number of lines? Since 32Mhz/2/1024/312.5 is _exactly_ 50Hz i'd assume that it's alternating 313/312 lines.

Which in turn would mean that my current scanline emulation which just dims the second of a scan doubled line could be made more realistic by toggling the dimming between the first and the second line every frame resulting in some 25Hz flickering.

[Cyprian]

from my memory

both fields are exact, 313 lines for "50Hz" mode and and 262 for "60Hz" mode per frame


you can check video timing figures in Hatari or Steem sources. Both emulators are really close to real hardware.
http://code.google.com/p/steem-engine/s ... svn68&r=68

[AtariZoll]

32MHz is not exactly 32MHz in Ataris. And it varies - PAL and NTSC is slightly different.
So, yes, it is 313 lines, 50 x in sec by PAL. Not exactly by TV standards, but works well on analogue TVs, and not always well on modern ones.

I don't think that exact time of left and right border is relevant, since it is analogue technique. You can get answers by using some logic analyzer. Don't think that any (SW) emulator needs exact times of sync pulses Maybe someone did it, but I really don't know about ..

Vblank is term used in TV techn., and it is longer than vertical sync pulse. Same stays for hor. one. However, by Atari, it is (better said vertical blank interrupt, done by Glue) likely generated exactly at start of sync pulse. Again, don't remember any accurate measuring. But for sure, it can not be at end of sync pulse - it has no sense.

Btw. only in Falcon sampling of video base is done correctly (in right moment - at end of Vblank, and not at start) , but it is interesting for SW coders mostly.

[troed]

Nice thread, but lacks a lot of the real physical information.

Also i still have to finde the values for border widths and blank and sync widths.

Another info i am missing is the exact time a vbi/hbi is generated. At the begin or the end of the sync pulse?

I think all that is available in the thread, although spread out over several different posts. I mapped all the sync/blank pulses to the exact cycles and there's also unprecedented info as to how the real hardware can differ between wakeup modes which will produce real differences as to where on the physical screen the pixels will start displaying.

I'm sure you can use a lot of it, but in some areas it's "being discovered right now". No emulator is even near being able to simulate things to the exact timing as described there.

(The state machines I started describing are probably a lot more suitable for an FPGA implementation than the current PC emulators)

[Dio]

Where did you get that numbers from? Do both fields really have the same number of lines? Since 32Mhz/2/1024/312.5 is _exactly_ 50Hz i'd assume that it's alternating 313/312 lines.

Which in turn would mean that my current scanline emulation which just dims the second of a scan doubled line could be made more realistic by toggling the dimming between the first and the second line every frame resulting in some 25Hz flickering.

No, all the old computers used genuine 50Hz frames rather than 25Hz interlaced modes. I actually found this on a real ST back in the day by flickering a double resolution image at 50Hz and could show it was indistinguishable between frames ABABAB and BABABA implying it was impossible to exploit interlace.

CRT TVs are analogue devices and pretty tolerant of gammy signals. Even discounting the 50Hz frame effect (which also implicitly states that either the H or V timing must be slightly out, since the standards are designed for 312.5 and 262.5 lines) computers generate sync which is usually very dubiously conformant with the actual standards.

Modern digital LCDs aren't, hence why you tend to see artifacts such as 1-pixel offsets and frame to frame smoothing since it doesn't understand the concept of a noninterlaced input signal.

[exxos]

While half on the subject, Does anyone know why when using the ST on a new HD TV, it works on scart, but at random times the image moves to the left and back again in about a second. Sometimes it does it every couple of mins, other times couple times a hour. Overall the image is good, but the image problem is the same on 3 ST's I have tried

[AtariZoll]

It is exactly because of non-standard video supplied by Atari. And on some LCD TV/monitors there is constant vertical shaking, what makes it unwatchable. Problem is visible even with some TV cards in PC.

[exxos]

The vertical is actually fine, Horizontal just jumps, its like the left border vanishes and the image is flush with the side of the TV screen, but it only does that at random times.

[troed]

The vertical is actually fine, Horizontal just jumps, its like the left border vanishes and the image is flush with the side of the TV screen, but it only does that at random times.

That sounds like automatic widescreen detection, where it tries to zoom the image to fill the available screen estate. If you have a mode called "just scan" or something similar it's preferred.

[exxos]

The vertical is actually fine, Horizontal just jumps, its like the left border vanishes and the image is flush with the side of the TV screen, but it only does that at random times.

That sounds like automatic widescreen detection, where it tries to zoom the image to fill the available screen estate. If you have a mode called "just scan" or something similar it's preferred.

Its not a zoom though, the image simply jumps to the left, its still the same size. its probably just the TV IDK..

[MasterOfGizmo]

I think all that is available in the thread, although spread out over several different posts.

Ah, sorry. Indeed, lots of great info there ... but everything but easy to understand for mortals.

What i have so far:

PAL 50 HZ hor total = 512, vert total = 313
NTSC 60 HZ hor total = 508, vert total = 263
MONO 72HZ hor total = 896, vert total = 501 (some sources say 500)

I have modified my verilog shifter to be able to reproduce these. Still there are things i haven't found yet and which i'd like to document not only for the MIST board but also for other VHDL/Verilog implementations.

E.g. the video.h from steem says border display starts in line 34 and data display starts in line 63. But it's still unclear to me where the counters start. At the end of sync? At the begin of sync?

What i am still searching for is:

How wide are the borders (top/botton/left and right)?
How long are the blank (hor and vert front and back porches) and sync phases?
At what time is hbi generated? (i assume at the begin of hsync)
At what time is timer b triggered? (i assume at the end of last memory fetch, e.g. 4 2Mhz cycles before that last pixel is displayed)
At what time in the horizontal timing do the vertical states change?
At what time is the vbi generated? (i assume at the begin of vsync)
At what time is the new memory address latched into the video counters? (steems video.h says in line 310, but that's of limited use for me as i don't know where sync and thus vbi happen)

Some signals are of no use for emulators like e.g. blank signals. But real hardware needs these as some screens really don't like to see non-blanked lines close to/in the sync phases. Thus i assume that steem counters count from the moment hbi and vbi are generated? So e.g. the border starts 34 hbis after vbi? This also means that the address counters are reloaded three lines before vbi (i assume this is where my display problems in goldrunner are)?

Edit: Yes, it was the relation of VBI and video counter reload causing the goldrunner problem. With video counter reload slightly before vbi the display is just fine ...

[MasterOfGizmo]

No, all the old computers used genuine 50Hz frames rather than 25Hz interlaced modes. I actually found this on a real ST back in the day by flickering a double resolution image at 50Hz and could show it was indistinguishable between frames ABABAB and BABABA implying it was impossible to exploit interlace.

Ah, ok. I just remembered that the images weren't very stable at that time. But you are right. By switching between two images at 25Hz one would then have been able to do interlaced video.

CRT TVs are analogue devices and pretty tolerant of gammy signals. Even discounting the 50Hz frame effect (which also implicitly states that either the H or V timing must be slightly out, since the standards are designed for 312.5 and 262.5 lines) computers generate sync which is usually very dubiously conformant with the actual standards.

Also the fact that NTSC and PAL STs had different crystals definitely means that they weren't able to do the exact timing of the "opposite" region. But this also means that Atari really tried as those two frequencies only differ by a fraction of a percent.

[troed]

PAL 50 HZ hor total = 512, vert total = 313
NTSC 60 HZ hor total = 508, vert total = 263
MONO 72HZ hor total = 896, vert total = 501 (some sources say 500)

Mono is 224 cycles per line - your value is four times that though so maybe we mean the same thing.

E.g. the video.h from steem says border display starts in line 34 and data display starts in line 63. But it's still unclear to me where the counters start. At the end of sync? At the begin of sync?

In the other thread are trace diagrams posted by Dio - the one named "50hz_video clock DE to load to screen latencies" can be pixel counted to see where HSYNC ends, BLANK ends, DE goes high, LOAD goes high all the way until first data on RGB pins A better answer would be to just give you the values but then maybe I misrepresent something. I'll try though:

We're in wakestate territory, but if we go with wakestate 1 then HSYNC ends at cycle 504, BLANK ends at cycle 32, DE goes high at cycle 60, LOAD at 66 and first data on RGB pins at 84. This is for low res.

CPU cycles counter as used above start at a traditionally used value and are not based off actual SYNC timings.

How wide are the borders (top/botton/left and right)?

Actual pixels possible to show by demos using tricks? 26 bytes left border and 44 bytes right (so 52 and 88 pixels). In PAL low res.

How long are the blank (hor and vert front and back porches) and sync phases?

The following is a straight quote from a post in the other thread by Dio:

Horizontal timing, starting from the start of HSYNC: 5us sync, 5us blank, DE activated after 3.5us, DE active for 40us, BLANK active after 9us, HSYNC after 1.5us; in clocks, that's 40 / 40 / 28 / 320 / 72 / 12.
VSYNC starts 104 cycles after the start of the previous line's HSYNC, so that's 4 cycles before DE would be activated. It is likely that this is the point at which the H counter is reset (and V incremented) so one would expect that the horizontal period would be determined at about this point.


That's what I could gather quickly from my notes - hope it helps. Others know this better than me - but I'd be happy to help out in more detail when you want accurate simulation of sync tricks for different line lengths, syncscrollers and stuff

/Troed

[MasterOfGizmo]

Mono is 224 cycles per line - your value is four times that though so maybe we mean the same thing.

Yes, sure. It depends whether you cound in 8Mhz cpu cycles or 32 Mhz pixel clocks. I am using 32Mhz since that's what the (scan doubled) VGA output is always clocked at.

We're in wakestate territory, but if we go with wakestate 1 then HSYNC ends at cycle 504, BLANK ends at cycle 32, DE goes high at cycle 60, LOAD at 66 and first data on RGB pins at 84. This is for low res.

...

Horizontal timing, starting from the start of HSYNC: 5us sync, 5us blank, DE activated after 3.5us, DE active for 40us, BLANK active after 9us, HSYNC after 1.5us; in clocks, that's 40 / 40 / 28 / 320 / 72 / 12.
VSYNC starts 104 cycles after the start of the previous line's HSYNC, so that's 4 cycles before DE would be activated. It is likely that this is the point at which the H counter is reset (and V incremented) so one would expect that the horizontal period would be determined at about this point.

Thanks! That really helps. I just learned about wake states ... what a mess

Your numbers are really helpful. Thanks a lot!

The other thread is really great. One day you may understand where the counters start and why changing the timing at certain points makes it skip/extend/repeat certain states resulting in all those overscans. That's the point where a hdl implementation of the atari video might actually become trivial since i don't expect the original state machine to be overly complex. After all it was designed in a hurry and with simplicity/price in mind.

Currently it doesn't make too much sense for me to look into the horizontal tricks as none of the hdl 68k cpu cores is cycle exact and thus no program would be able to hit the sweet spots, anyway. So i currently focus on the original timing (with additional tricks to help VGA screens like a scan doubler, a 56Hz replacement for the 50Hz mode and the ability to move the VGA sync phases independently from the ST sync phases.

Anyway. THANKS!

[MasterOfGizmo]

Actual pixels possible to show by demos using tricks? 26 bytes left border and 44 bytes right (so 52 and 88 pixels). In PAL low res.

I am not sure if a real ST blanks outside the sync phase (what a VGA timing would call front and back porch). If it does then there's a specific number of border pixels between blank and real display even if not used for overscan tricks. If the ST just displays its border color for anything outside the sync phase then this would also mean that the borders have a well-defined width but you'd likely never see them all.

[AtariZoll]

...
Also the fact that NTSC and PAL STs had different crystals definitely means that they weren't able to do the exact timing of the "opposite" region. But this also means that Atari really tried as those two frequencies only differ by a fraction of a percent.

Right. The reason for slightly different main clock - what determines CPU, Video, STE audio DMA, + some other clocks is to avoid interference in color encoders - PAL or NTSC . As some tests confirmed, NTSC machines have 0.4% faster main clock. In some thread here, exact crystal frequencies for diverse models are given. Of course, only very small count of SW is sensitive on this - mostly some demos. And I'm pretty sure that most of them is made on PAL machines.

[Steven Seagal]

Actual pixels possible to show by demos using tricks? 26 bytes left border and 44 bytes right (so 52 and 88 pixels). In PAL low res.

I am not sure if a real ST blanks outside the sync phase (what a VGA timing would call front and back porch). If it does then there's a specific number of border pixels between blank and real display even if not used for overscan tricks. If the ST just displays its border color for anything outside the sync phase then this would also mean that the borders have a well-defined width but you'd likely never see them all.

Yes it blanks. This is also discussed in the 'horizontal scrolling' thread.

Border pixels low resolution:
top: at least 36
bottom: at least 50
left: 52 (but scanlines are shifted 4 left by overscan tricks)
right: 48 before HBlank

It's what I use, I don't claim it's right.

[MasterOfGizmo]

In conclusion, how many pixels is a physical line wide?

In mono 70Hz 896, in Mid 50hz 1024, in low 50hz 512, in mid 60hz 1016 and in low 60hz 508