Shop OBEX P1 Docs P2 Docs Learn Events
[POC] How far ... — Parallax Forums

[POC] How far ...

kuronekokuroneko Posts: 3,623
edited 2013-02-20 00:48 in Propeller 1
can one push the text resolution of a single cog VGA text driver? Colour depth and font source (RAM/ROM) are not relevant for this exercise but the driver must work at 80MHz.
  • 32x15 VGA_Text (using VGA)
  • 40x15 [thread=150593]full colour/paletted ROM font text driver (640x480 timing)[/thread]
  • 50x18 [thread=150636]full colour ROM font text driver (800x600 timing)[/thread]
  • 50xH [thread=136666]full colour RAM font text driver[/thread]
  • 80xM [thread=151855]monochrome RAM font text driver[/thread]
  • 100xM [thread=146085]monochrome RAM font text driver[/thread]
  • ???
Not strictly a text driver but listed for completeness.
  • 512x384 2 colour pixmap driver (64/85 columns with 8bit/6bit font), requires lots of memory, not counting font data

Comments

  • doggiedocdoggiedoc Posts: 2,243
    edited 2013-02-16 03:47
    Is this a challenge or a question? I would bet that DrAcula could offer some solutions. I think Rayman has done some text driver work too. I'll see if I can find a link.

    Doc
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-16 03:50
    doggiedoc wrote: »
    Is this a challenge or a question?
    Bit of both really ... I just have this odd feeling that 50 columns isn't the final answer.
  • AribaAriba Posts: 2,690
    edited 2013-02-16 05:28
    Bill Henning has made 64 and 80 column text drivers with one cog.
    http://forums.parallax.com/showthread.php/129739

    Andy
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-16 05:37
    Ariba wrote: »
    Bill Henning has made 64 and 80 column text drivers with one cog.
    I know but the former looks horrible on an LCD (aliasing) and the latter needs 100MHz.
  • AribaAriba Posts: 2,690
    edited 2013-02-16 06:14
    There is also the 512x384 Bitmap driver from Chip. If you copy 8x8 or 6x8 pixels from a font bitmap into the screen bitmap, then you can have text resolutions of:
    85 x 48 chars with a 6x8 font, or 64 x 48 chars with a 8x8 font.
    But this needs a lot of memory (24kB for the bitmap alone) If 24 rows are enough then you can set the bitmap driver to 512x192 pixels, this will need only 12kB.

    Andy
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-16 06:29
    Ariba wrote: »
    There is also the 512x384 Bitmap driver from Chip.
    Added to list for completeness. Thanks.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-02-16 09:33
    Do you care whether or not things are interlaced?

    If not, the VGA timing Baggers used in the full color sprite tile driver linked in my sig might be interesting. It's 640x200 timing and it displays on every monitor I've tried and it does so at 640x400.

    At full color, it's really tough to get it to 320 pixels. At text color depths, it should go quite a bit higher.
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-16 16:53
    potatohead wrote: »
    If not, the VGA timing Baggers used in the full color sprite tile driver linked in my sig might be interesting.
    Are we talking VGA_JB_001 (256x240)? IIRC that's a scanline driver so needs at least another cog doing the (text) rendering.

    I really mean single cog driver which - given screen and font pointers - displays the text.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-02-16 18:35
    I wasn't referring to the render code. Yes, it's a scan line driver. It is one because it's built to do sprites and tiles, both of which typically take more than one COG. Really, what I wanted to mention was just the signal timing, which is one of the lowest horizontal sweeps, if not the lowest that I've seen render on every display I've tried. A simple text driver, particularly one that doesn't need color attributes and such benefits significantly from lower sweep rates.
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-16 18:48
    potatohead wrote: »
    Really, what I wanted to mention was just the signal timing, which is one of the lowest horizontal sweeps, if not the lowest that I've seen render on every display I've tried. A simple text driver, particularly one that doesn't need color attributes and such benefits significantly from lower sweep rates.
    Fair enough. That said, it suffers from artefacts trying to display 256 pixels with 640x? timing (on my LCD screen that is). Anyway, something worth looking into for 64/80 columns.

    Does anyone think 100 columns (as the logical extension of 50xH) would be possible?
  • potatoheadpotatohead Posts: 10,261
    edited 2013-02-16 19:35
    Are you seeing waitvid artifacts or monitor artifacts? Got a picture?

    I'm curious now. Frankly, I think more than 640 pixels can be displayed with that timing, it's just often easy to refer to the ideal or nominal pixel count for the timing.

    Re: 100 columns. I don't know. I need to look at your 50xH code and understand how it's currently doing things.
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-16 20:09
    potatohead wrote: »
    Are you seeing waitvid artifacts or monitor artifacts? Got a picture?
    waitvid issues have been dealt with (provided you have an updated driver). It's on the monitor. The signal is recognised as 640x480 but 256 pixel don't fit too well into that timing (CRT is probably OK).

    attachment.php?attachmentid=99306&d=1361073866

    The white rectangles cover a 4 pixel block (1x waitvid), the odd pixels appear wider than the even ones. The attached archive will generate the screen the image is taken from (left, middle). The RGBY stripes have been manually added as markers.
    detail.png
    695 x 431 - 801K
    zip
    zip
    VGA_JB_Demo - Archive [Date 2013.02.17 Time 12.51].zip
    17K
  • potatoheadpotatohead Posts: 10,261
    edited 2013-02-17 11:37
    I'm where I can run this today. Very interesting what your display is doing. 640/256 = 2.5 Thin pixels are 4 monitor LCD elements, thicker ones 6. I've got a CRT and an older LCD that appeared to display this driver output consistently. Maybe it doesn't.

    What is the resolution of that display?
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-17 17:30
    potatohead wrote: »
    What is the resolution of that display?
    It's 1280x1024, so no excuse for not doing 640 properly. Anyway, assuming that LCD monitors sample the incoming data with a clock matching the resolution I came up with this: 
    25M    -|---|---|---|---|---|---|---|---|---|---
 10M    |---------|---------|---------|---------|
             3         2         3         2
    Pixels are issued with 10MHz, 640x480 uses 25.175M as official pixel clock (I'm using 25M here). As you can see there is an arrangement where one pixel is sampled 3 times the next one only twice which matches what I can see on the screen.

    The driver is currently using about 320 hub windows for a (double) scanline and the line buffer is effectively blocked (each scanline re-reads the buffer). I had a go at scanline drivers a while back ([thread=142629]256x192[/thread], [thread=142764]400x300[/thread]). The 256x192 driver signals as 1024x768, a scanline takes about 420 hub windows and 315 of them can be reused (buffer is sampled during first scan line). Even if you reduce the scanlines to 3 (256x256) you get 315/210 which brings it into the current timing range but still allows you to re-use the scanline buffer earlier.
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-20 00:48
    potatohead wrote: »
    At full color, it's really tough to get it to 320 pixels.
    I wouldn't say that. The only irritating bit was the pixel clock which makes placing the hubops a bit of a pain and unlike the 256 and 400 pixel variants it would need at least double buffer operation (which is probably a minor issue).

    Driver is now available [thread=146236]over here[/thread].
Sign In or Register to comment.