Full Color Tile Driver Thread



  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-12-01 - 20:43:40
    Unfortunately, simply connecting the RGB lines together would only get you 0..3*3 == 0..9 or 10 levels

    Just thinking through the maths, is it not 4^3, not 3*3?

    You have 6 lines so with a R/2R D to A that is capable of 64 levels. That ought to be 64 gray scales.

    What I'm not sure about is whether you need an op amp buffer, and it might need to be a high speed one, as I don't know what the input impedance is for vga pins.

    @ Baggers, are you doing 240x192 on vga?
  • BaggersBaggers Posts: 2,965
    edited 2010-12-02 - 01:57:19
    Thanks JT Cook, glad it's worked well! :) I was also thinking of blacking some lines, to maybe do a 256x200 to go with the TV driver, and have border, which would give you some more vblank timing :)

    Dr_Acula, are you wanting a 240x192? or 256x192 for anything in particular?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-12-02 - 02:13:58
    Yes sorry, I meant 256/192 as that is 4/3.

    I guess the advantage of that over 246/240 is that no scaling is needed. Not sure how the tiles work out though.
  • ericballericball Posts: 774
    edited 2010-12-02 - 04:08:34
    Dr_Acula wrote: »
    Unfortunately, simply connecting the RGB lines together would only get you 0..3*3 == 0..9 or 10 levels

    Just thinking through the maths, is it not 4^3, not 3*3?

    VGA has the following output: RrGgBbHV or 2+1,2+1,2+1,2,2 from an output standpoint. So connecting RGB together (without any additional resistors) gets you 2+1+2+1+2+1 = 9.

    However, for greyscale there's a better way of doing things. . . .
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-12-02 - 04:11:49

    VGA feeds are 75 Ohms each for the RGB. The syncs are not so tightly defined and are something around TTL levels at 1K Ohms. Some posh cables use 5 x 75 Ohm coaxs (not strickly correct) but a lot just have 3 x poor excuses of coaxs and a couple of single wires (not nice at all).
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-12-02 - 04:55:43
    VGA has the following output: RrGgBbHV or 2+1,2+1,2+1,2,2 from an output standpoint. So connecting RGB together (without any additional resistors) gets you 2+1+2+1+2+1 = 9.

    Yes, that is exactly correct, if you didn't change the hardware.

    For grayscale, and noting the 75R impedance value above, I think it would require quite different hardware. 6 propeller pins. Feed them with 6 binary values xxNNNNNN and run that into a R/2R ladder. Maybe use 10k and 20k 1% resistors. Feed the output of that into three op amp buffers, and run each of the outputs of those op amp buffers into (I think) 75R resistors, and thence to the R and G and B pins.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-12-03 - 01:04:59
    If you run the amplified O/Ps through a 75 Ohm resistor then the o/p of the amp will have to be 2V p-p. This would have to be arranged either by the R2R and/or the amplifier gain.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-12-03 - 03:44:43
    Being thick. again.

    the double level before the output reistor would be 1.4 Volts.
  • jazzedjazzed Posts: 11,803
    edited 2010-12-22 - 12:02:32
    @Baggers or potatohead.

    I've never been able to get the latest demo with 16_TV.spin to show in color.
    I don't have a demo board. The only changes I think I need are these:
    ivcfg                   LONG    %0_11_1_0_1_000_00000000000_010_0_01110000      ' dac on p20..23
    ictra                   LONG    %0_00001_110_00000000_000000_000_000000         ' NTSC
    ifrqa                   LONG    $16E8_BA2F                                      ' (7,159,090.9Hz/80MHz)<<32 NTSC demoboard & Hydra 
    idira                   LONG    $0070_0000                                      ' dac on p20..23

    If I use the 09_TV.spin driver everything is fine except a few color problems.

    Any help?

    My end goal is to integrate something into ZOG, but I'd to get SPIN working first,

  • potatoheadpotatohead Posts: 10,070
    edited 2010-12-22 - 17:57:55
    I'll check on this for you near the end of the week. I'll have some prop time then.

    Hey, I need to ask. Baggers and I thought about a final release, with the TV driver extended out to 240 lines. That would include the overscan area, not viewable on many TV's, but likely viewable on little LCD devices, and capture cards. Would that have any value, or is the thing better with the TV operating in the safe area, at 200 lines, as it is right now!

    Since the driver package will be touched again over the holiday (at least by me), it makes sense to add this in, if possible, and or practical.

    Thoughts anybody and everybody?
  • jazzedjazzed Posts: 11,803
    edited 2010-12-22 - 18:24:27
    I want to use the driver in the SDRAM TV/SDCARD module ZOG demo and would prefer that "all customers" be able to use the device, so operating in the safe area is more important to me. Besides I kind of like the framing effect on the little LCDs.

    I think the fact that your non-interlace feature works so nice makes TV an attractive option as a "Propeller Computer" display. The current interlace only drivers don't really cut it at all for some combinations like CYAN on BLUE and others.

    Thanks for your time and Merry Christmas!

  • potatoheadpotatohead Posts: 10,070
    edited 2010-12-22 - 20:15:08

    That's a complete accident. Truth is, I spent a LONG time trying to get it to act like the other drivers do. Then, I connected the Demo Board I was running at the time to the SONY, and decided that's a feature!! Glad it works well for your display.

    More soon, when I can look. Deffo keep it a option then on the 240 lines. Easily done.
  • potatoheadpotatohead Posts: 10,070
    edited 2010-12-27 - 11:07:27
    Jazzed, are you around?

    Wondering about your clock and pin setup... And is that the TV code from the last release Baggers posted??
  • jazzedjazzed Posts: 11,803
    edited 2010-12-27 - 11:31:26
    Yes, I'm here. Here's the setup detail:
      basepin = 20
      ifrqa = $16E8_BA2F
      idira = $0070_0000
      ictra = %0_00001_110_00000000_000000_000_000000  ' CTRA PLL Mode VCO/2
      ivcfg = %0_11_1_0_1_000_00000000000_010_0_0111_0000

    Code is 16_TV.spin
  • potatoheadpotatohead Posts: 10,070
    edited 2010-12-27 - 14:39:39

    The TV driver as released is botched. I'll post another release here, with the TV driver sorted, proper headers and such. Sorry, if you've been getting a rough TV signal outta this demo.

    Edit: Here's a stable release, current, with converter, fixed TV driver, graphics samples.
  • potatoheadpotatohead Posts: 10,070
    edited 2010-12-27 - 18:03:04
    Bump (please lengthen your message to at least 10 characters) Sorry for the bump. Was dorking around with attachments.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,090
    edited 2010-12-27 - 19:20:43
    Very nice!

    I've got to get my Ghostbusters demo converted over to this!
    (Maybe after I finish my Tron lightcycles game)

  • trodosstrodoss Posts: 577
    edited 2011-02-24 - 07:48:24
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,090
    edited 2011-03-06 - 08:19:57
    Has anyone found a better solution to the PLL issue with this driver?

    The solution doesn't really work... This tends to happen in 8-10 compiles at random.
    EDIT: I'm noticing sometimes the PLL messes up and you get blocky columns, so I remember seeing something a while ago, that linus found about the stabilising of the PLL, hopefully that should fix it
    but for now, to fix, set the NUM_COGS to 6, then back to what you had it on, or a turn off and on, can fix it too.



    800 x 600 - 309K
    800 x 600 - 329K
  • kuronekokuroneko Posts: 3,623
    edited 2011-03-07 - 04:34:42
    Could one of the video warriers please explain what PLL messes up actually means? I can't decide for myself if it's either made up or tries to explain something else entirely. That said, I hope it's the latter but you never know with assumptions, that's why I ask :)
  • potatoheadpotatohead Posts: 10,070
    edited 2011-03-07 - 09:32:25
    I've not ever had this happen.

    The TV portion has some small issues on my list to fix, and I've tagged those. Know what's going on. This one confuses me, because the driver has always started correctly. Would be really helpful, if we could get a photo or screen capture of the failure condition.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,090
    edited 2011-03-07 - 09:45:00
    Photo's were added to my message. I'm currently testing a solution created by kuroneko. So far so good. If I don't see the issue reappear by late tonight, (after 20-30 compiles) I think we've got it.

  • kuronekokuroneko Posts: 3,623
    edited 2011-03-07 - 20:53:17
    potatohead wrote: »
    This one confuses me, because the driver has always started correctly.
    Relax and count yourself lucky. This particular setup has about 1 chance in 4 of failing which is skewed by the fact that not all cogs are equal after power-up (it took me a while but I collected all 4 cases). Anyway, it's the same issue Bill is facing. If you squeeze a waitvid into a fixed hub access raster, make sure that the hand-off point is where you want it. That said, I still don't see the PLL connection, you'd have the same issue with NCO driven video h/w.
  • potatoheadpotatohead Posts: 10,070
    edited 2011-03-07 - 21:04:46
    If it's the same issue Bill is facing, then it's highly likely Jim just figured it was the PLL and moved on.
  • kuronekokuroneko Posts: 3,623
    edited 2011-03-08 - 18:38:42
    Jeff reported that the issue disappeared which is probably as close as we can get to a solution (I did this as a blind fix as I don't have a VGA monitor available).

    This is based on the driver in the Sunday, November 21, 2010 at 7:52:15 PM package.
    blank_hsync             mov     vscl,_hf                'hsync, do invisible front porch pixels
                            waitvid hv,#0
                            mov     vscl,_hs                'do invisble sync pixels
                            xor     hv,#%10
                            waitvid hv,#0
                            [COLOR="red"]neg     href, cnt               ' waitvid reference ...
                            cogid   $ nr
                            add     href, cnt               ' ... relative to hub window
                            sub     href, #(76 + 42) * 4    ' pixels start in (_hs+_hb)*4
                            shr     href, #2                ' delta in frame clocks
                            and     href, #%11              ' limit to 0..3
                            add     href, _hb               ' add base -> _hb + 0..3
                            mov     vscl, [COLOR="red"]href[/COLOR]              'do invisible back porch pixels
                            xor     hv,#%10
                            waitvid hv,#0
    [COLOR="red"]href                    res     1[/COLOR]
    The single res goes at the end of the file.

    Pixels are latched between 2 hub ops which are in fact 2 slots apart (32 cycles). Meaning the waitvid has 16 cycles leg room in there somewhere. The code above will make sure that the waitvid stays in the middle of this windowA. Previously there was a condition that you got a non-blocking waitvid which means the pixel info was taken from the or instruction just before the waitvid. In this case the active value for pixels is $03030303 (coloror) which means colour 3 is used once and colour 0 three times. When you look at the relevant image you'll find that this is exactly what happens, two colours with a 1:3 ratio.

    A or rather finishes 8..11 cycles before the next rdlong which also means the unrolled loop could in fact be a loop as add only consumes 4 cycles of the gap
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,090
    edited 2011-03-09 - 07:19:23
    I'm on two days of testing with this adjustment and it seems to have fixed the issue with the VGA object.

    Well done and thank you!

  • potatoheadpotatohead Posts: 10,070
    edited 2011-06-19 - 15:11:53
    I am unclear if a fixed distribution was posted, or not. Jeff, et al. if there is, can you link me to it, or post the corrected software here?

    Thanks. PH :)
  • kuronekokuroneko Posts: 3,623
    edited 2011-06-19 - 16:37:55
    potatohead wrote: »
    I am unclear if a fixed distribution was posted, or not. Jeff, et al. if there is, can you link me to it, or post the corrected software here?
    I'm not aware of a complete posting in this forum. Try this instead http://www.savagecircuits.com/forums/showthread.php?529-VGA-Spyhunter-test-using-Tile-Driver&p=4139&viewfull=1#post4139 (driver only).

    Update: Please refer to [post=982876]post #206[/post] instead.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-07-30 - 18:21:52
    I've been testing out this code - see attached. The tv parameters are for 80Mhz and TV on pins P16-18.

    The original demo has a tile driver with 256x240 and a picture of mario with the colors matched to the closest color of the 86 in the palette.

    I thought I might run this through the Floyd Steinberg dithering and yes, it does come out better. See the pic of mario below 256x240.

    Pushing things further and further...

    Ok, 256x240 with tiles is a little fake in that this picture is about half white, so it does work with tiles where half the tiles are white (or the same as each other) but not with most pictures.

    Limitations of the prop memory limit things to 256x96 with 86 colors, or 256x192 with 16 colors.

    But I have resurrected this thread because I'm interested in how far things could go using external ram.

    Firstly, what is the absolute best resolution for TV, either with a replicated tile, or with code created on the fly? For the full palette, is it 256x240, or have things been pushed further?

    (The hypothetical demo might be a single small tile sitting in the middle of a white or black background).

    Next question - how fast can you read lines off external ram?

    Consider one of the smaller drivers we have - eg 256x96. That is 24k, and say you were reading at NTSC speeds of (I think) 30 frames a second, that is about 740k a second.

    Now imagine a propeller chip dedicated to video. 3 pins for video, some pins for a high speed data link, and 24 pins devoted to driving a ram chip. With 24 pins on a SRAM, you can do this with one latch and read out data in 8k blocks. Speed will be limited by the ram chip itself (55ns sram needs one NOP).

    Dedicate one cog to the high speed data link - buffer the data as it comes in, and store it to the ram in the back porch and at the end of the frame.

    Dedicate one cog to reading data one line at a time off the ram and into hub. This greatly decreases the requirement for hub video ram. Maybe hub ram is instead used for the data buffer for data coming in?

    And then there are the video driver cog(s). Only one minor change to the code - instead of the counter going up for the whole video buffer from 0 to 24575 (or whatever), it resets at the end of the line (256). Or maybe you have a little more of a buffer - maybe a few scanlines then everything can work out of sync and really capitalise on the parallel nature of the propeller.

    Can we read data off the sram fast enough?

    Well, with a 55ns ram, and for most of the time /RD is permanently enabled, so you are just clocking up the address lines and reading out data, that ought to be able to read at over 10megabytes per second.

    Reading in 256x96 at 30 frames a second is around 740 kilobytes a second.

    So I think there is scope to go higher than 256x96. Maybe even 320x240 with a 86 color palette.

    I see on some other threads that the PropGFX gang are using 2 propellers to increase the video memory. I wonder if one propeller plus a 512k ram chip would work out cheaper and give you more ram as well?

    Just to dream of what could be possible with 320x240 and F/S dithering and 86 colors is the Monet below.
    256 x 240 - 13K
    350 x 262 - 41K
  • ericballericball Posts: 774
    edited 2011-07-31 - 18:42:34
    NTSC is 525 lines in 33.367msec, PAL is 625 lines in 40ms. NTSC line period is 63.555usec, PAL line period is 61.249usec. So the first question is how much data you can pull from external RAM in that time. The closer your pixel rate is to twice the colorburst frequency (NTSC: 3.579545 MHz = 455 pixels/line, PAL: 4.43361875 MHz = 422 pixels), the more likely you are going to get color artifacts.
Sign In or Register to comment.