|
|---|
Claudio Wieland
Germany
| | (Natami Team)
Posts 706
24 Jan 2012 21:26
| André Jernung wrote:
|
Marcel Verdaasdonk wrote:
|
hm, 1920*1200*60=138.24MHz
|
1920 X 1200 @ 60Hz has a total data rate of 193 MHz. This requires dual link DVI running at 96.5 MHz. But perhaps it could be solved with reduced blanking - such resolutions are not common on CRTs anyway.
Source: EXTERNAL LINK |
Yes, reduced (horizontal and vertical) blanking is the only way to achieve 1920x1200@60Hz. Thomas' video chip should support it as well, IIRC.
| |
Claudio Wieland
Germany
| | (Natami Team)
Posts 706
24 Jan 2012 21:28
| Marcel Verdaasdonk wrote:
|
André Jernung wrote:
|
Marcel Verdaasdonk wrote:
|
hm, 1920*1200*60=138.24MHz
|
1920 X 1200 @ 60Hz has a total data rate of 193 MHz. This requires dual link DVI running at 96.5 MHz. But perhaps it could be solved with reduced blanking - such resolutions are not common on CRTs anyway.
Source: EXTERNAL LINK |
André according to your link 1080P also isn't available for the Natami. ;)
Besides i would like to know the math they used since it's about 1/3 higher then mine.
|
Pure pixel rate is irrelevant. There's a lot of extra data that has to be transmitted to make sure that hopefully each monitor that gets connected to the system works and can sync to the signal.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
24 Jan 2012 21:51
| Sync is relative easy IMHO, especially when we consider that modern monitors have I²C to communicate to the system and tell what modes are supported.
| |
Nixus Minimax
Germany
| |
Posts 273
25 Jan 2012 06:46
| Marcel Verdaasdonk wrote:
|
Sync is relative easy IMHO |
With just the pure image data there is nothing you could sync to. You have to consider the case that the image could be random noise. With digital high speed transmission you will also want some error coding, e.g. 8bit/10bit encoding (already gives an extra 25%).
| |
Claudio Wieland
Germany
| | (Natami Team)
Posts 706
25 Jan 2012 07:52
| Valid video formats actually demand "empty" regions (black pixels) before and after the actual image data, not accounting for possibly embedded audio data and such.
IIRC, normal DVI has 1.6GB/sec for 8_to_10bit encoding per data channel. This is 160 mega "pixels", which contains emdedded data and additionally needed data (see above).
In principle, a TFT monitor would not need blanking periods to refresh its data. There is no electron beam which needs time to travel back across the screen on CRT:s otherwise. For the devices to be compatible with all possible monitor types, official video standards with sync signals must be adhered to and blanking periods added as prescribed.IMO there's no reason, though, why Natami should not be able to produce 1080p with reduced blanking.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
25 Jan 2012 10:53
| My led cube uses the blanking periods to sync to, like i said easy.
I think the Natami won't have more trouble with 1920*1200 then with 1080p.
| |
Nixus Minimax
Germany
| |
Posts 273
25 Jan 2012 11:48
| Marcel Verdaasdonk wrote:
|
My led cube uses the blanking periods to sync to, like i said easy. |
Whatever your led cube does, syncing to a data stream is everything but easy unless there are specific signals available or constraints on the data itself that guaranty certain spectral characteristics. If you just have the raw image data payload, you can only sync to the data stream assuming certain properties of the payload which cannot be taken for granted (e.g. non-black image content, slowly varying image content, non-random image content). A display mode that makes common monitors lose sync when displaying certain image data would be considered broken.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
25 Jan 2012 13:32
| Both DVI and VGA have Vertical and Horizontal Sync Signals.
When turned on a normal screen does not need to show directly all data it gets in.
No it delays untill it's Sync, and then shows what is comming in this is also why most screens after 2004 have a reduced blanking signal and not completely droped it.Besides that Nixus go read up on PLL applications 4046 specific. ;)
| |
Nixus Minimax
Germany
| |
Posts 273
25 Jan 2012 14:44
| Marcel Verdaasdonk wrote:
| | Both DVI and VGA have Vertical and Horizontal Sync Signals. |
Wrong. DVI can have VSYNC and HSYNC, it needs not. A valid DVI-implementation can do completely without analogue signals. This is commonly known as "DVI-D". BTW, DVI does use 8bit/10bit encoding which in itself means an extra 25%. It does so to guaranty a minimum of 5 transitions per pixel character. Guess why it does. To make the syncing possible. Marcel Verdaasdonk wrote:
| Besides that Nixus go read up on PLL applications 4046 specific. ;)
|
If I were you, I'd be less big-mouthed. I have done extensive research in the field of PLLs and I am inventor of some PLL-related patents.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
25 Jan 2012 14:58
| Nixus Minimax wrote:
|
Marcel Verdaasdonk wrote:
| Besides that Nixus go read up on PLL applications 4046 specific. ;)
|
If I were you, I'd be less big-mouthed. I have done extensive research in the field of PLLs and I am inventor of some PLL-related patents.
|
That is cool but still Sync is easy with a PLL.
| |
Pawel K.
Poland
| |
Posts 53
31 Jan 2012 12:03
| Thomas Hirsch wrote:
|
Natami uses currently a single channel DVI link. This limits the pixelclock to about 160MHz.
|
wikipedia wrote:
| Example display modes (single link):
HDTV (1,920 × 1,080) @ 60 Hz with CVT-RB blanking (139 MHz)
UXGA (1,600 × 1,200) @ 60 Hz with GTF blanking (161 MHz)
WUXGA (1,920 × 1,200) @ 60 Hz with CVT-RB blanking (154 MHz)
SXGA (1,280 × 1,024) @ 85 Hz with GTF blanking (159 MHz)
WXGA+ (1440 × 900) @ 60 Hz (107 MHz)
WQUXGA (3,840 × 2,400) @ 17 Hz (164 MHz) |
Single link DVI is definitely capable of 1920x1200@60Hz both with reduced blanking for LCDs and even with normal full "CRT" blanking. I actually tested it with HDFireFury that is single link and it looked fine on my CRT.
There are no good LCD monitors that are not 1920x1200 !!! Lacking such mode would be EPIC FAIL :(
| |
Thierry Atheist
Canada
| |
Posts 1830
01 Feb 2012 09:19
| I wonder..... Demo coders, could sending data differently to these hi-def monitors be used as a hack to generate unusual screen effects? Something that would be (very) hard to do on ultra-complex PC video cards?
| |
Nixus Minimax
Germany
| |
Posts 273
01 Feb 2012 10:55
| Thierry Atheist wrote:
|
I wonder.....
Demo coders, could sending data differently to these hi-def monitors be used as a hack to generate unusual screen effects? |
I don't think there will be any way to have an influence on the flow of data from screenbuffer to monitor.
| |
Rune Stensland
Norway
| | (MX-Board Owner)
Posts 871
01 Feb 2012 19:40
| Thierry Atheist wrote:
|
I wonder.....
Demo coders, could sending data differently to these hi-def monitors be used as a hack to generate unusual screen effects? Something that would be (very) hard to do on ultra-complex PC video cards?
|
Democoders would compress the signal. This could be done with a modern copper... But it would require a monitor wich can decompress the signal.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
01 Feb 2012 22:19
| Rune I don't suppose the team is gonna design a screen too so I doubt it would be worth to make thierry happy with a feature that will not work on most screens.
| |
Golgoth 27
France
| |
Posts 185
01 Feb 2012 23:13
| What about a Screen with 8 more phone plugs and another answering machine, just in case the NatAmi answering machine would be busy ? ;-p
| |
Andreas G. Szabo
Germany
| |
Posts 134
01 Feb 2012 23:17
| loool, this is funny :D
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
02 Feb 2012 05:22
| seems you never thought about multiplexing since most phone lines are digital now.
| |
|
Do you have questions about the Natami?