262 lines per frame
508 cycles per scan line
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: viewforum.php?f=16
e.g. this very interesting thread: viewtopic.php?f=16&t=24855
on page 15, you can find timing diagrams done by Dio
313 lines per frame
512 cycles per scan line
MasterOfGizmo wrote: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?
MasterOfGizmo wrote: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.
exxos wrote: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 wrote:exxos wrote: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.
troed wrote:I think all that is available in the thread, although spread out over several different posts.
Dio wrote: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.
Dio wrote: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.
MasterOfGizmo wrote: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)
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?
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?
troed wrote:Mono is 224 cycles per line - your value is four times that though so maybe we mean the same thing.
troed wrote: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.
troed wrote: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.
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.
MasterOfGizmo wrote:troed wrote: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.
Users browsing this forum: No registered users and 5 guests