New P2 Silicon

1235726

Comments

  • Though I was unable to find any preview (copyright concerns), I believe good information could be found into that standard's contents.

    https://webstore.ansi.org/standards/ansi/cta7702017-1663326
  • cgraceycgracey Posts: 13,078
    edited 2019-08-06 - 05:12:06
    cgracey wrote: »
    There are protocols used by security cameras to transmit 1080p30 and 4k15 over a single coax line. e.g. AHD. Converter boxes to convert AHD to HDMI are available starting at $50. It's questionable whether some of these converter boxes can output HDMI above 1080p.

    The specs are probably not available so we would need to reverse engineer it.

    The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
    cgracey wrote: »
    or even 2160i, if such a format exists.
    No, no, no, no, please no! Now that we use LCDs, it should be fine to output 30p, 24p, or even 15p. I'm hoping we can do 720p30 over HDMI.

    720p60 signals at 74.25MHz. Half that would be 37.125MHz, which would need 371.25 MHz for HDMI. That would barely work.

    Ok then, 720p24 at 29.7MHz. Or 720p15 at 18.5625MHz. I should be able to get that on my P2ES board. I might have to try just to see how many displays will handle it.

    I will give 720p24 HDMI a try.

    I remember reading that a 250MHz bit rate (25MHz pixel rate) is the minimum for HDMI. Less than that is not recognized by receivers.
  • I've just been playing with my cheapo LCD TV with its VGA input and found it is quite fussy about the horizontal scan frequency for some resolutions but not so much for other resolutions. And you know it's not happy by the way it shifts the display area half off screen. It's a tad bizarre because the image looks complete and stable. Even the resolution reported is correct.

    1920x1080@60 is particularly sensitive, it specifically wanted 67 kHz. For a while I was thinking that particular mode was broken over VGA until I was getting extreme with another resolution and it went sideways on me as well.
  • evanhevanh Posts: 9,962
    edited 2019-08-06 - 05:22:20
    cgracey wrote: »
    I remember reading that a 250MHz bit rate (25MHz pixel rate) is the minimum for HDMI. Less than that is not recognized by receivers.
    It seems bizarrely arbitrary but still I'll be most amused if that isn't rigidly enforced. Like how PC monitors refuse to drop below 30 kHz horizontal scan rate.
  • potatohead has it right, the MPAA/etc. wanted HDMI because it has DRM (HDCP). They don't want hires component because it's not protected (DRMed).

  • Roy Eltham wrote: »
    potatohead has it right, the MPAA/etc. wanted HDMI because it has DRM (HDCP). They don't want hires component because it's not protected (DRMed).

    Those guys really know how to ruin the fun.
  • True, maybe it is manicured just to look like market driven. I vaguely remember difficulties in general usefulness with component into a TV. It seemed entirely dedicated to DVD players.
  • cgraceycgracey Posts: 13,078
    edited 2019-08-06 - 07:12:37
    I got HDMI 720p24 working. It signals at 297MHz.
    '***********************************
    '*  720p24 HDMI - 16bpp 5:6:5 RGB  *
    '***********************************
    
    CON		hdmi_base = 8
    
    DAT		org
    '
    '
    ' Setup
    '
    		hubset	##%1_010011_0100101000_1111_10_00	'configure PLL, 20MHz / 20 * 297 * 1 = 297MHz
    		waitx	##20_000_000 / 200			'allow crystal and PLL 5ms to stabilize
    		hubset	##%1_010011_0100101000_1111_10_11	'switch to PLL
    
    		rdfast	##640*350*2/64,##$1000	'set rdfast to wrap on bitmap
    
    		setxfrq ##$0CCCCCCC+1		'set transfer frequency to 1/10th clk, +1 for initial rollover
    
    		setcmod	#$100			'enable HDMI
    
    		drvl	#7<<6 + hdmi_base	'enable HDMI pins
    
    		wrpin	##%10110_0001_0000_10_00000_0,#7<<6 + hdmi_base	'123-ohm DAC
    '
    '
    ' Field loop
    '
    field		mov	hsync0,sync_000		'vsync off
    		mov	hsync1,sync_001
    
    		callpa	#5+10,#blank		'top blanks
    
    		mov     x,##720-20			'set visible lines
    line		call	#hsync			'do horizontal sync
    		xcont	m_rf,#1			'do visible line
    		djnz    x,#line           	'another line?
    
    		callpa	#20+10,#blank		'bottom blanks
    
    		mov	hsync0,sync_222		'vsync on
    		mov	hsync1,sync_223
    
    		callpa	#5,#blank		'vertical sync blanks
    
                    jmp     #field                  'loop
    '
    '
    ' Subroutines
    '
    blank		call	#hsync			'blank lines
    		xcont	m_vi,hsync0
    	_ret_	djnz	pa,#blank
    
    hsync		xcont	m_bs,hsync0		'horizontal sync
    		xzero	m_sn,hsync1
    	_ret_	xcont	m_bv,hsync0
    '
    '
    ' Initialized data
    '
    sync_000	long	%1101010100_1101010100_1101010100_10	'
    sync_001	long	%1101010100_1101010100_0010101011_10	'	 hsync
    sync_222	long	%0101010100_0101010100_0101010100_10	'vsync
    sync_223	long	%0101010100_0101010100_1010101011_10	'vsync + hsync
    
    m_bs		long	$7F910000+110		'before sync
    m_sn		long	$7F910000+40		'sync
    m_bv		long	$7F910000+220		'before visible
    m_vi		long	$7F910000+1280		'visible
    
    m_rf		long	$BF950000+1280		'visible rfword rgb16 (5:6:5)
    '
    '
    ' Uninitialized data
    '
    x		res	1
    
    hsync0		res	1
    hsync1		res	1
    '
    '
    ' Bitmap
    '
    		orgh	$1000 - 70		'justify pixels at $1000
    		file	"birds_16bpp.bmp"	'rayman's picture (640 x 350)
    


    I tried 720p15, which would signal at 185.625MHz, but it doesn't work on my HDTV.
    576 x 1024 - 238K
  • Cool. I can't tell but is that transmitted as 48 Hz interlace in the signalling?
  • evanh wrote: »
    Cool. I can't tell but is that transmitted as 48 Hz interlace in the signalling?

    It's a progressive 24fps scan.
  • evanhevanh Posts: 9,962
    edited 2019-08-06 - 07:17:33
    Yeah, that's why the name "progressive" was given, it's built out of two fields to make one still image.
  • evanh wrote: »
    Yeah, that's why the name "progressive" was given, it's built out of two fields to make one still image.

    So, the whole image is sent in order, not odd and even lines separated.
  • That would be more correctly called a sequential, or non-interlaced, transmission.
  • cgraceycgracey Posts: 13,078
    edited 2019-08-06 - 07:38:57
    The lowest frequency I can get 720p to work at on my HDTV is 285MHz. That's 23.03fps. My next frequency down is 22.95fps and that doesn't work. So, I think 24fps is the official low-end, with 1fps allowance downward. It's really nice that we can do 720p24, though! Thanks for suggesting that, Saucy. 720p in portrait mode with an 8x8 font could show 90 columns by 160 lines of code. That would be great.
  • Oh, wow, that's only 18 kHz line rate! I bet there is no computer monitor will support that mode.

  • Here is HDMI 720p24 mode properly displaying the source image in a 2x2 array.
    '***********************************
    '*  720p24 HDMI - 16bpp 5:6:5 RGB  *
    '***********************************
    
    CON		hdmi_base = 8
    
    DAT		org
    '
    '
    ' Setup
    '
    		hubset	##%1_010011_0100101000_1111_10_00	'configure PLL, 20MHz / 20 * 297 * 1 = 297MHz
    		waitx	##20_000_000 / 200			'allow crystal and PLL 5ms to stabilize
    		hubset	##%1_010011_0100101000_1111_10_11	'switch to PLL
    
    		setxfrq ##$0CCCCCCC+1		'set transfer frequency to 1/10th clk, +1 for initial rollover
    
    		setcmod	#$100			'enable HDMI
    
    		drvl	#hdmi_base + 7<<6	'enable HDMI pins
    
    		wrpin	##%10110_0011_0000_10_00000_0,#hdmi_base + 7<<6	'123-ohm DAC
    '
    '
    ' Field loop
    '
    field		mov	hsync0,sync_000		'vsync off
    		mov	hsync1,sync_001
    
    		callpa	#5+10,#blank		'top blanks
    
    		mov     x,##720-20		'set visible lines
    line		rdfast	#640*2/64,addr		'set rdfast to wrap on bitmap
    		call	#hsync			'do horizontal sync
    		xcont	m_rf,#1			'do visible line
    		cmp	x,#351		wz
    	if_nz	cmp	x,#1		wz
    	if_nz	add	addr,##640*2
    	if_z	mov	addr,base
    		djnz    x,#line           	'another line?
    
    		callpa	#20+10,#blank		'bottom blanks
    
    		mov	hsync0,sync_222		'vsync on
    		mov	hsync1,sync_223
    
    		callpa	#5,#blank		'vertical sync blanks
    
                    jmp     #field                  'loop
    '
    '
    ' Subroutines
    '
    blank		call	#hsync			'blank lines
    		xcont	m_vi,hsync0
    	_ret_	djnz	pa,#blank
    
    hsync		xcont	m_bs,hsync0		'horizontal sync
    		xzero	m_sn,hsync1
    	_ret_	xcont	m_bv,hsync0
    '
    '
    ' Initialized data
    '
    sync_000	long	%1101010100_1101010100_1101010100_10	'
    sync_001	long	%1101010100_1101010100_0010101011_10	'	 hsync
    sync_222	long	%0101010100_0101010100_0101010100_10	'vsync
    sync_223	long	%0101010100_0101010100_1010101011_10	'vsync + hsync
    
    m_bs		long	$7F910000+110		'before sync
    m_sn		long	$7F910000+40		'sync
    m_bv		long	$7F910000+220		'before visible
    m_vi		long	$7F910000+1280		'visible
    
    m_rf		long	$BF950000+1280		'visible rfword rgb16 (5:6:5)
    
    base		long	$1000
    addr		long	$1000
    '
    '
    ' Uninitialized data
    '
    x		res	1
    
    hsync0		res	1
    hsync1		res	1
    '
    '
    ' Bitmap
    '
    		orgh	$1000 - 70		'justify pixels at $1000
    		file	"birds_16bpp.bmp"	'rayman's picture (640 x 350)
    


    576 x 1024 - 215K
  • 848x480@60 would suit 16:9 format monitors. I've tested a 32 MHz dot clock mode for VGA output. That might just scrape in at the top end for the HDMI output.
     ' 848x480 VGA (16:9), 30.77 kHz, 60 Hz
      fpix		= 32_000_000.0
      H_DISP        = 848			' HT = 1040 (192), x1.25 = 1056 (208), x1.3 = 1096 (248)
      H_FPORCH      = 16
      H_SYNC        = 112
      H_BPORCH      = 64
      V_DISP        = 480			' VT = 513 (33)
      V_FPORCH      = 3			'511 max
      V_SYNC        = 7			'511 max
      V_BPORCH      = 23			'511 max
    
  • The problem with operating at 320 MHz is it's well into the slew limited area of the I/O pins where there is multiple lag effects that are temperature dependent - https://forums.parallax.com/discussion/comment/1472679/#Comment_1472679

    It won't be an issue for straight outputs, or even straight inputs most likely. But timings that rely on both together, like SD cards, could be in a difficult position for reliability. Dunno, maybe it's as simple as allowing enough leeway for the worse case and a slower sysclock just has to suck it.

  • cgracey wrote: »
    Roy Eltham wrote: »
    potatohead has it right, the MPAA/etc. wanted HDMI because it has DRM (HDCP). They don't want hires component because it's not protected (DRMed).

    Those guys really know how to ruin the fun.

    Fun fact: HDCP was/is entirely pointless, too. Pirates were/are much more interested in ripping the actual video files being played. Recording from the output is impractical and looses a lot of quality.
    HDCP 1.x is also a terrible encryption scheme that is farily easy to break. Someone even reverse-engineered the master key.
    Or you can just bypass it entirely by purchasing a badly designed HDMI splitter (altough since this bug is fairly common, I think at some point they started doing it on purpose), for as they didn't really check whether licensed devices violate the spec.
    It is also the reason for why an HDMI connection sometimes takes f o r e v e r to be established.


    And thus we are stuck with HDMI, no HD VGA / YPbPr anymore and HD-SDI never became a home standard.
  • 24fps is the low end. It is supported for direct film frame rates to preserve cinematography.

    I have a 1080p 24fps BluRay of an old western, "How the West Was Won" The thing is amazing. Matching that up makes a big difference. I bought it to see that 24fps mode in action.

    Yeah Chip. Spoilers, aren't they? Well, what they ended up with is cheapo TVs from Asia that will decrypt and then present the raw stream internally. That ended up being as good as the analog hole was.

    It sure is a lot less resource intensive.

    Cool to see a bit higher resolution will work at the lower frame rates. People will put that to use.

    Re: Component usefulness

    Game systems, disc players and some computer graphics cards will output component. Anything that does has a larger color space than plain RGB does. I have used with plasma and CRT HD displays for years.

    On both plasma and CRT you get a real black and serious contrast, if you want it.

    I like component because just one wire will deliver a grey scale monochrome signal from 240p all the way through 1080p. Super lean, and your choice of sweep rates from 15khz on up. :D



  • Chip,
    Here's 1280x720@24 tweaked to run at 28 MHz VGA out - Tested on my LCD TV. I presume it'll work over HDMI out too.
     ' 1280x720 VGA (16:9), 18 kHz, 24 Hz
      fpix		= 28_000_000.0
      H_DISP        = 1280			' HT = 1552 (272), x1.25 = 1600 (320), x1.3 = 1664 (384)
      H_FPORCH      = 16
      H_SYNC        = 176
      H_BPORCH      = 80
      V_DISP        = 720			' VT = 750 (30)
      V_FPORCH      = 3			'511 max
      V_SYNC        = 7			'511 max
      V_BPORCH      = 20			'511 max
    
  • David BetzDavid Betz Posts: 14,179
    edited 2019-08-06 - 11:08:10
    Chip: Have you made any assessment yet about whether the new P2 is bug-free enough to proceed with making some production chips? Have you seen any problems that might indicate another spin? From what you've posted I would guess not. I'm asking because I think Ken said that Parallax was unlikely to ramp up any tools effort until you were sure you had a chip that could go into production. Are we at that point now?
  • evanhevanh Posts: 9,962
    edited 2019-08-06 - 11:17:08
    Lol, David, is that a gentle nudge for Chip to stay on track?
  • evanh wrote: »
    Lol, David, is that a gentle nudge for Chip to stay on track?
    Maybe. Why should Chip be the only one having fun? We need P2v2 chips for the rest of us too! :smile:

    Seriously, I think it made sense for Parallax to avoid spending a lot of resources working on tools until they knew for sure that they had a chip they could sell. I'm just asking if Chip thinks we're there yet.

  • evanhevanh Posts: 9,962
    edited 2019-08-06 - 11:34:07
    True, Chipmas before December hopefully.

    One thing that was not easy to prove in the FPGA was the DIR/OUT timing relationship pertaining to glitch removal on simultaneous transitions. Chip worked with On Semi to fine tune that area I believe.

    PS: It's not something that would be show stopper either way though.

  • There is other new stuff still to test, e.g. Sinc2/Sinc3, Hann/Tukey windows, SCOPE instruction. I imagine Chip has a list that he is working through in order and we'll have to be patient.

    Re HDMI, I think there are 720x480 60Hz and 720x576 50 MHz modes at 270 MHz, which could give better looking text than 640 pixels/line. Also from memory, the DVI/HDMI spec says minimum clock is a bit less than 250 MHz, but no point trying that as the new P2 works at 297 MHz.
  • evanhevanh Posts: 9,962
    edited 2019-08-06 - 11:55:35
    TonyB_ wrote: »
    Also from memory, the DVI/HDMI spec says minimum clock is a bit less than 250 MHz, ...
    That would be handy to know how low. It opens up possible other resolutions and also allows the chip to be operated at a lower frequency if desired.
  • evanh wrote: »
    TonyB_ wrote: »
    Also from memory, the DVI/HDMI spec says minimum clock is a bit less than 250 MHz, ...
    That would be handy to know how low. It opens up possible other resolutions and also allows the chip to be operated at a lower frequency if desired.

    From the DVI v1.0 spec, p.18:
    http://www.cs.unc.edu/Research/stc/FAQs/Video/dvi_spec-V1_0.pdf
    2.3 Bandwidth

    2.3.1 Minimum frequency supported

    The minimum frequency supported is specified to allow the link to differentiate between an active low-pixel format link and a power managed state (inactive link). The lowest pixel format required by the DVI specification is 640x480@60 Hz (clock timing of 25.175 MHz). The DVI link can be considered inactive if the T.M.D.S. clock transitions at less than 22.5 Mhz for more than one second.

    25.0 MHz works of course, but precisely how low one can go I do not know.

  • TonyB_ wrote: »
    2.3 Bandwidth

    2.3.1 Minimum frequency supported

    The minimum frequency supported is specified to allow the link to differentiate between an active low-pixel format link and a power managed state (inactive link). The lowest pixel format required by the DVI specification is 640x480@60 Hz (clock timing of 25.175 MHz). The DVI link can be considered inactive if the T.M.D.S. clock transitions at less than 22.5 Mhz for more than one second.
    Thanks Tony. 23 MHz looks doable then.

    It's not hard to see the intentional blindness in the lowest required wording.

  • cgracey wrote: »
    I remember reading that a 250MHz bit rate (25MHz pixel rate) is the minimum for HDMI. Less than that is not recognized by receivers.

    Doh! Thankfully I decided to sleep instead of code.

    The 720p24 is great news! We can advertise "Digital HD Video". I remember that HDMI devices are required to support 640x480x60. That should include audio too.
    evanh wrote: »
    Thanks Tony. 23 MHz looks doable then.

    It's not hard to see the intentional blindness in the lowest required wording.
    DVI was designed in the CRT era. Even 60Hz refresh was annoying then. There was probably no practical use for lower pixel rates. Although when HDMI came along it should have been lowered to support 480i without pixel doubling.

    I've wanted to try ATSC output. I didn't since the IQ modulator was broken. But the MPEG2 encoding is likely a bigger problem. Except if we are outputting text. If we use a 16x32 font then each character will fill exactly 2 macroblocks. We would just be assembling pre-calculated macroblocks. For 1080p that would be 120x33 characters. Scrolling could be easily done using motion compensation. Note: This is not a suggestion for Chip. We haven't heard about all the ADC upgrades yet.



Sign In or Register to comment.