ST and STE interlaced video signal

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

ST and STE interlaced video signal

Postby ijor » Tue Aug 30, 2016 2:32 am

Almost a decade ago we had quite a heated debate about whether the ST outputs an interlace video signal or not:
viewtopic.php?f=15&t=10383

By now, I think everybody agrees that both the ST and the STE, as most classic consoles and computers, outputs a non-interlaced signal. The output mode is usually called 240p.

Not too long ago, when reverse engineering GLUE video logic, I found what seemed to be a buggy interlace logic. As it was trying to interlace the signal but it didn't work. Recently, when Christian found some original STE GLUE/MCU combo schematics, I was astonished to found that the buggy, non-working, logic is still there, and the output signal is called, of course: INTERLACE!

The signal is supposed to be active during the first scan of every other frame. The horizontal sync counter processes this signal when it wraps around. If the signal is asserted at that time, the topmost bit of the horizontal counter is asserted. So that instead of restarting from zero, it restart from the middle value. This should result in that particular scan line having half the length, which should (probably) produce an interlaced effect in most monitors of the period (even when standard interlace is not exactly like that).

But the signal is asserted at the wrong time. It just misses the cycle where the horizontal sync counter overwraps. I am attaching simulation waveforms in the next message to show the bug.

But more interesting than the technicalities of the bug, is the anecdotal historical side of the story. So they wanted the ST to interlace? Always? When they realized the logic is not working? Why the hell nobody ever either fixed it or removed it, not even when redoing GLUE in the STE combo ???

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST and STE interlaced video signal

Postby ijor » Tue Aug 30, 2016 2:44 am

Simulation waveforms of the processing of the INTERLACE signal:

InterlaceBug.png


InterlaceBugZoom.png


The actual INTERLACE signal is in read. It is the result of combining the two signals just below. EvenOdd, light blue, changes every frame (actually, every field in interlaced terminology). PrevField (gold), just follows the EvenOdd signal but one scan line later (well, sort of). INTERLACE is asserted when when EvenOdd changed to low.

hsyncReload is a pulse active when the horizontal sync counter is overwraping. In the next cycle (at the video 2MHZ clock) the horizontal sync counter is restarted, the exact value depends on the current frequency (50,60 or 70Hz).

But as the first waveform shows, INTERLACE is asserted just one cycle later. Too late to be processed on this scan line. To be processed correctly, it need to be asserted when hsyncReload is asserted as well. But, by the time of the next scan line, it was already deasserted. So it is never processed.

And that's why the ST (and the STE) does NOT interlace :)
You do not have the required permissions to view the files attached to this post.

nukebloodaxe
Atari User
Atari User
Posts: 32
Joined: Tue Jul 05, 2016 10:33 am
Location: New Zealand

Re: ST and STE interlaced video signal

Postby nukebloodaxe » Tue Aug 30, 2016 6:34 am

*taps his chin* I'm wondering a moment, what would the actual effects be for current ST/STEs if a replacement IC was created with the logic corrected?

I know the main aim for an eventual plugin IC is full accuracy where possible, but the thought of having a bug-fixed plugin replacement is intriguing. Do you believe the main problem would be with demos relying on certain bugs, or could they possibly still work? (An amateur question, I know, but then again I am an amateur.)

Keep up the good work, it's been getting really interesting.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1862
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: ST and STE interlaced video signal

Postby Cyprian » Tue Aug 30, 2016 9:23 am

great finding ijor.
is there any way to activate it? any memory mapped register?
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST and STE interlaced video signal

Postby ijor » Tue Aug 30, 2016 10:53 am

nukebloodaxe wrote:*taps his chin* I'm wondering a moment, what would the actual effects be for current ST/STEs if a replacement IC was created with the logic corrected?


Well, just enabling interlace always and by default would break compatibility. Any kind of animation running at 50 (or 60) fps, won't display correctly. What were supposed to be two consecutive frames, will now be two simultaneous interlaced fields. Even slower animations at half speed, 25 or 30 fps, would still be wrong.

Besides of making it optional, which is not so difficult, you would need to let the software know somehow which field is currently displaying. And/or extend the memory mapped screen twice the vertical resolution. Don't know how it is usually implemented on systems that interlace.

Cyprian wrote:great finding ijor. is there any way to activate it? any memory mapped register?


Nope. It is already always activated. Just that because of the bug it doesn't work.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1862
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: ST and STE interlaced video signal

Postby Cyprian » Tue Aug 30, 2016 11:27 am

ok.

For extended screen resolution (like 320x400 and 640x400, both interlaced) that "interlace" logic should also be implemented into MMU (in order to modify video counter between every half-frame).

If I understand you correctly, GLUE "interlace" is always on, and there is no any linkage with MMU?
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

fenarinarsa
Atari freak
Atari freak
Posts: 51
Joined: Sat Mar 15, 2014 11:23 pm

Re: ST and STE interlaced video signal

Postby fenarinarsa » Tue Aug 30, 2016 12:01 pm

Interesting topic :) I wondered if something interesting would surface with the ASIC designs now found.

ijor wrote:Well, just enabling interlace always and by default would break compatibility. Any kind of animation running at 50 (or 60) fps, won't display correctly. What were supposed to be two consecutive frames, will now be two simultaneous interlaced fields. Even slower animations at half speed, 25 or 30 fps, would still be wrong.

No, actually it would work. Field 1 would display frame 1 and field 2 would display frame 2. So the motion would actually be correct. It's just that you won't take advantage of the extended number of lines because the same lines from the video buffer would be used for field 1 and field 2. This makes flickering stronger, but that's all.

ijor wrote:Besides of making it optional, which is not so difficult, you would need to let the software know somehow which field is currently displaying. And/or extend the memory mapped screen twice the vertical resolution. Don't know how it is usually implemented on systems that interlace.

You don't need to do anything, you use a framebuffer that has twice more lines (let say 400 lines on the ST) and for the upper field the chips sends odd lines, for the lower field the chip sends even lines. It should be handled by the hardware or else you're right, you need to change the video base address each frame and make the video counter skip each other line.
Check http://amigadev.elowar.com/read/ADCD_2. ... e0316.html
In any case only half the picture is display for each field. That's why some motions render very badly on an interlaced display (for example, you must avoid vertical 1-pixel scrollers because you would display the same lines twice)


Now I have a question. I know that the STE can lock to an external video sync (genlock), but I never saw it work. All the cases I heard of genlock is from people using Amigas because they could output a standard PAL or NTSC interlaced signal, so Amigas were used in a lot of TV productions for on-air graphics.

But what about the STE when configured to lock to an external video sync ? Maybe it's the purpose of the "interlaced" mode you found, to keep a probable external interlaced video sync and to output the video buffer on each field (line doubler) ?

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST and STE interlaced video signal

Postby ijor » Tue Aug 30, 2016 12:08 pm

Cyprian wrote:For extended screen resolution (like 320x400 and 640x400, both interlaced) that "interlace" logic should also be implemented into MMU (in order to modify video counter between every half-frame).


Thinking ...

Well, yes, you will need either some MMU minor update ... or you could get alone without touching MMU but then with some board level mod ...

All what MMU does, relevant to this issue, is that it resets the video counter to the vbase address during vsync. So what you need for extended mapped resolution, is to MMU to not reset the counter on the second field of the frame.

But you could fool MMU if you would have a separate VSYNC signal, one to MMU, another to the video output. Then, you could control when MMU resets the above counter. Just a thought ...

It could also be done by software. Changing vbase each field (half frame).

If I understand you correctly, GLUE "interlace" is always on, and there is no any linkage with MMU?


Correct.

Btw, the interlace logic is for low rez only. It is completely shut off for other resolutions.Let me post the relevant page from the schematics ...

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST and STE interlaced video signal

Postby ijor » Tue Aug 30, 2016 12:10 pm

Interlace logic on the original STE GLUE/MCU schematics:

InterlaceComboPage.png


InterlaceComboZoom.png
You do not have the required permissions to view the files attached to this post.

vizfizz
Atari maniac
Atari maniac
Posts: 83
Joined: Fri Feb 24, 2012 4:15 pm
Location: Los Angeles
Contact:

Re: ST and STE interlaced video signal

Postby vizfizz » Tue Aug 30, 2016 12:23 pm

There appears to be a genlock for the STE called the graffiti by Titan Designs that once existed. Might be worth researching.

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2779
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: ST and STE interlaced video signal

Postby alexh » Tue Aug 30, 2016 3:41 pm

If interlace HAD worked AND been enabled all of the time. Would the Atari ST have been as competitive? Surely they would have had to respin?

User avatar
EmpireAndrew
Captain Atari
Captain Atari
Posts: 444
Joined: Fri Jul 15, 2016 5:46 pm
Location: Texas, USA

Re: ST and STE interlaced video signal

Postby EmpireAndrew » Tue Aug 30, 2016 5:55 pm

If it has be enabled all the time I wouldn't have bought the machine as interlacing sucks if you're using it for productive work.
1977 VCS Heavy Sixxer (Boxed)
1990 Atari 1040STE, 4MB, UltraSatan, TOS 2.06, TT Touch -> Atari SC1435 Colour CRT Monitor
1991 Atari TT030, 2/64MB, Int 8GB Gigafile SCSI2CF, TOS 3.06, CaTTamaran Accelerator -> Atari TTM195 19" Mono CRT Monitor
1993 Atari Falcon030, 14MB, Int 8GB HDD, TOS 4.04 -> Atari PTC1426 Color CRT Monitor
Amiga, Mac, DOS, SGI, Sun, NeXTStation, PDA's and more!

nbz
Atarian
Atarian
Posts: 8
Joined: Tue Nov 22, 2011 9:34 pm

Re: ST and STE interlaced video signal

Postby nbz » Wed Aug 31, 2016 11:40 am

I don't have the hardware knowledge to judge if it's a "bug" that the interlace mechanism "doesn't work" (that's to say, does not actually produce an interlaced signal).

But in my opinion, it would have been a HUGE bug - and just horrible - if the ST would *always* produce an interlaced signal whenever operated in low res. With no further mechanism to actually display even and odd fields, making use of the doubled vertical resolution would have been left to software. Worse, it would have been impossible to display non-interlaced content in an acceptable fashion, as the entire screen content would be jittering up/down by HALF a scanline all the time.

So I have no idea why this circuitry ended up in the chip, and/or wasn't removed on later redesigns. But I would not be surprised if the "signal is asserted at the wrong time" bit was a deliberate action to deactivate the logic, possibly in a quick-and-dirty way because of time contraints / office politics.

If it had been an OPTIONAL feature, accessible through some hardware register, I would have loved it, even if it's just doing the signal part (the half-a-scanline offsetting of fields) and leaving the management and flipping of fields (buffers) to the programmer. But if it was meant to be always active in low res... thank heavens it doesn't work!

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST and STE interlaced video signal

Postby ijor » Thu Sep 01, 2016 3:41 am

fenarinarsa wrote:Interesting topic :) I wondered if something interesting would surface with the ASIC designs now found.


Well. This is partially from the new find. The main concept that the logic exists in the older chipset generation, I found it before from my reverse engineering work. But the fact that it still exists on the STE chip, and that the signal is actually named INTERLACE by Atari, comes from the original schematics.

ijor wrote:Well, just enabling interlace always and by default would break compatibility. Any kind of animation running at 50 (or 60) fps, won't display correctly. What were supposed to be two consecutive frames, will now be two simultaneous interlaced fields. Even slower animations at half speed, 25 or 30 fps, would still be wrong.

No, actually it would work. Field 1 would display frame 1 and field 2 would display frame 2. So the motion would actually be correct.


I don't have much experience with interlaced systems, but I'm not sure it would be correct. Let's say you have an horizontal line going down one scan line per field (50 or 60 fps). You display the line at scans 0,1 and 2.

In a non interlaced system it appears at physical scan lines 0,2 and 4. But if sync is interlaced, the monitor would display it at scans 0,3 and 4, or at scans 1,2 and 5. Because every other field the sync would move the display one scan line vertically.

It should be handled by the hardware or else you're right, you need to change the video base address each frame and make the video counter skip each other line.


What I meant is that assuming you have no hardware support, just sync becomes interlaced, you could handle by software like this. You do change vbase each field, and besides that, you arrange two buffers, one for each field.

Now I have a question. I know that the STE can lock to an external video sync (genlock), but I never saw it work.


All the STs since day one support, kinda, genlock. The system is designed to receive external sync. There is a setting on GLUE for that purpose. What the STE implements, that the ST had not, is to be able to use not only external sync, but also to receive external main clock.

But what about the STE when configured to lock to an external video sync ? Maybe it's the purpose of the "interlaced" mode you found, to keep a probable external interlaced video sync and to output the video buffer on each field (line doubler) ?


When GLUE is configured for external sync, the internal sync counters are not used. Conceivable the interlace logic does work better with external sync (depends on the exact timing of both sync signals). But then the result of this logic, the INTERLACE signal, is ignored. Or to be more precise, whatever INTERLACE effect has on the internal sync counters doesn't matter, because the internal sync counters are ignored.

fenarinarsa
Atari freak
Atari freak
Posts: 51
Joined: Sat Mar 15, 2014 11:23 pm

Re: ST and STE interlaced video signal

Postby fenarinarsa » Thu Sep 15, 2016 10:16 pm

ijor wrote:I don't have much experience with interlaced systems, but I'm not sure it would be correct. Let's say you have an horizontal line going down one scan line per field (50 or 60 fps). You display the line at scans 0,1 and 2.

In a non interlaced system it appears at physical scan lines 0,2 and 4. But if sync is interlaced, the monitor would display it at scans 0,3 and 4, or at scans 1,2 and 5. Because every other field the sync would move the display one scan line vertically.


Interlaced video is my area :) you're not completely correct, the actual scanlines displayed in interlaced mode are
0 2 4 6 8... ("even", "upper" or "top" field)
1 3 5 7 9... ("odd", "lower" or "bottom" fied)
0 2 4 6 8...
1 3 5 7 9...
etc.

Let's say you don't have hardware support to handle interlacing but that the output is interlaced, you'll get that :
buffer => even field
0 => 0
1 => 2
2 => 4
3 => 6
...
buffer => odd field
0 => 1
1 => 3
2 => 5
3 => 7
...

I had to work a lot with that kind of signal since a lot of "line doublers" do exactly that to record an interlaced signal from old RGB progressive output (game consoles/ST/amiga).

For still pictures, the result is that all the original lines are doubled :
0
0
1
1
2
2
3
3
...

For motions, it's a bit more complex to describe in text, but you get this (let's say you have the first animation step a and the second animation step b) :
a0 ----
---- b0
a1 ----
---- b1
a2 ----
---- b2
a3 ----
---- b3
...

The motion is correct, since you have step A on the first field and step B on the second field.

But as I said earlier you get a huge flicker effect, and on big screens the pictures also seems to vibrate vertically. This is when I'm usually called to fix this :)

What I meant is that assuming you have no hardware support, just sync becomes interlaced, you could handle by software like this. You do change vbase each field, and besides that, you arrange two buffers, one for each field.


Yes, or you can have a 400 lines buffer and use the hardware scroll capabilities of the STE to skip a line and start displaying the buffer at line 0 or line 1, effectively sending only half the lines of the buffer for each field.
But you have no way to know if you should sending odd or even lines, and in the case you're not in sync, the motion will be okay but even and odd lines will be swapped. When this happens, people usually see the picture is degraded without understanding why (some early video capture cards with broken drivers swapped lines this way).

In any case you get the correct motion since fields are displayed in the same order you send them, unless you found a quantic machine in the GST-MCU that send the scanlines backward in time :)

(note that this is completely different for digital video recordings where a "field order" is required to play them out correctly. This is due to the fact fields are not recorded independantly by modern codecs: they are frame based, so they take two fields and stuff them in a single complete frame. Some field-based media do not have this issue, like Sony Digital Betacam)


But all of this is purely hypothetical since we don't know if the STE is can actually output interlaced signal :shrug:

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: ST and STE interlaced video signal

Postby AtariZoll » Thu Sep 15, 2016 11:33 pm

I'm not surprised about this. Designers managed to make non-working audio level correction in STE (Mega STE too), so YM sound is much louder than DMA one. Despite all components and proper resistor ratio is there. Only in Falcon it is made right.
And it reminds me on another design flaw: in ST, STE and TT content of video base registers is written into MMU (since it does actual addressing by screen draw) at V-blank start. What means that any write in those registers in V-blank routine will delay 1 period - will change actual screen base only at next V--blank start. Correct is to write right before screen draw start - again, only in Falcon.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: ST and STE interlaced video signal

Postby AtariZoll » Tue Sep 20, 2016 8:34 pm

Interlaced video was normal way on TVs when source was video camera. And it is still used now, in digital era. Because of way how it worked, it was actually something in between from 25 and 50 fps (PAL, Europe). There is SW what can make 50 fps video from interlaced 25 fps source, by calculating missing lines, and it looks good in most cases. We never have real frames there, only half frames, which aren't shot in same time. So, in case of computers some 50 fps game will look well with interlaced displaying, even if vertical position of lines is not completely accurate - in case of SW not using double vertical res.
Problems may appear when broadcasting progressive video - film source - then in case of wrong field order we will have half of frame from previous and half from current frame, so broken lines and like. I saw it multiple times on TV. In case of computers it means need to make SW to know in which field display is at moment (as is stated).
So, most likely they wanted interlaced as option, but it pulled more work and extra registers, more code in TOS, so it was just abandoned with some quick move. Like instead deleting/commenting out section of code in SW source, adding there one simple branch to jump over that part :D
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 6 guests