+ Reply to Thread
Page 11 of 11 FirstFirst ... 7891011
Results 201 to 212 of 212

Thread: Full Color Tile Driver Thread

  1. #201

    Default Re: Full Color Tile Driver Thread

    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

  2. #202

    Default Re: Full Color Tile Driver Thread

    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.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another

    Parallax colors simplified: http://forums.parallax.com/showthrea...hics_Demo.spin
    PropGCC Mac OS 10.6.8 + https://www.dropbox.com/sh/pf1uulr4b...Xx0wYC?v=1mcis




  3. #203

    Default Re: Full Color Tile Driver Thread

    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.

    OBC
    Visit PROPELLERPOWERED.COM -:- Micromite Companion available now!
    After you are done here, wander over to our Friendly Forums.
    Online Chat Saturday Nights 9pm EST -:- Projects, not Platforms -:- Follow me on Twitter.

  4. #204

    Default Re: Full Color Tile Driver Thread

    Quote Originally Posted by potatohead View Post
    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.

  5. #205

    Default Re: Full Color Tile Driver Thread

    If it's the same issue Bill is facing, then it's highly likely Jim just figured it was the PLL and moved on.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another

    Parallax colors simplified: http://forums.parallax.com/showthrea...hics_Demo.spin
    PropGCC Mac OS 10.6.8 + https://www.dropbox.com/sh/pf1uulr4b...Xx0wYC?v=1mcis




  6. #206

    Default Re: Full Color Tile Driver Thread

    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.
    Code:
    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
    
                            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, href              'do invisible back porch pixels
                            xor     hv,#%10
                            waitvid hv,#0
    
                            ...
    
    href                    res     1
    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
    Last edited by kuroneko; 03-09-2011 at 09:35 AM. Reason: changed reference point

  7. #207

    Default Re: Full Color Tile Driver Thread

    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!

    OBC
    Visit PROPELLERPOWERED.COM -:- Micromite Companion available now!
    After you are done here, wander over to our Friendly Forums.
    Online Chat Saturday Nights 9pm EST -:- Projects, not Platforms -:- Follow me on Twitter.

  8. #208

    Default Re: Full Color Tile Driver Thread

    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
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another

    Parallax colors simplified: http://forums.parallax.com/showthrea...hics_Demo.spin
    PropGCC Mac OS 10.6.8 + https://www.dropbox.com/sh/pf1uulr4b...Xx0wYC?v=1mcis




  9. #209

    Default Re: Full Color Tile Driver Thread

    Quote Originally Posted by potatohead View Post
    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...ull=1#post4139 (driver only).

    Update: Please refer to post #206 instead.
    Last edited by kuroneko; 12-10-2011 at 02:41 AM. Reason: external link is down permanently

  10. #210

    Default Re: Full Color Tile Driver Thread

    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.
    Attached Thumbnails Attached Thumbnails Click image for larger version

Name:	mario.jpg‎
Views:	79
Size:	12.9 KB
ID:	83550   Click image for larger version

Name:	luncheon320.jpg‎
Views:	80
Size:	41.0 KB
ID:	83554  
    Attached Files Attached Files

  11. #211

    Default Re: Full Color Tile Driver Thread

    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.
    Pay for your free software - let the developers know how much you appreciate their work!

    Links to Propeller stuff I've done (mostly composite video)

  12. #212

    Default Re: Full Color Tile Driver Thread

    Thanks for that. 33ms for a frame and say a frame has 320x240 which is 77kilobytes. Number of bytes per second is 320*240*1000/33 which is 2.3 megabytes a second. Approx 429 nanoseconds per pixel. The SRAM is a 55ns part and needs one NOP in PASM.

    This should be well within the limits of the ram chip.

    I'm thinking of buffers so that timing is not so critical - eg one cog is reading data off the ram into hub, and the video cog is reading data from hub. Maybe enough of a hub ram buffer for a few lines of the picture. So that should avoid color artifacts.

    As was pointed out on another thread, this is not going to work very well for fast moving graphics as there is limited time to update the sram with new video information.

    Although, thinking this through, if at 320x240 the sram is nearly 10x faster than it needs to be, that might leave plenty of time.

    The refresh rate for a video signal is 30x a second, and the frame rate for a movie with the sd card running flat out is around 7-8 frames a second. So there should be enough time to
    1) keep a video buffer topped up from the sram
    2) feed data into the sram from another buffer and
    3) keep data coming into the input buffer.

    With 24 pins devoted to running the sram, if the sram is disabled then that leaves all those propeller pins free to do other things, eg read data off an sd card. Or establish a fast parallel link with another propeller (maybe a 16 bit wide link?).

    I have some boards on the way to test some of this - hopefully soon.

    ericball - I've heard you have a high resolution driver available. I have the driver code but not the 'main' demo program. Do you have any code you might be able to share?

    PS - as an aside, is your avatar a CRO tracing of a NTSC signal?
    Last edited by Dr_Acula; 08-01-2011 at 03:34 AM.

+ Reply to Thread

Similar Threads

  1. 640x480 Pixel 40x30 Tile 4 color VGA Tile Map Driver @ 60HZ Uploaded to the Obe
    By Kye in forum Propeller 1 Multicore Microcontroller
    Replies: 6
    Last Post: 08-08-2010, 11:02 PM
  2. Plotting full color pixels? (1-255 color)
    By Microcontrolled in forum Propeller 1 Multicore Microcontroller
    Replies: 8
    Last Post: 01-06-2010, 12:08 PM
  3. Color applet for tile driver
    By Rayman in forum Propeller 1 Multicore Microcontroller
    Replies: 2
    Last Post: 09-05-2007, 06:32 PM
  4. I need a VGA 512x384 / 4 color tile driver compatible with graphics.spin
    By Marc Gebauer in forum Propeller 1 Multicore Microcontroller
    Replies: 14
    Last Post: 01-15-2007, 01:11 PM
  5. New VGA 1024x768 4-Color Tile Driver
    By cgracey in forum Propeller 1 Multicore Microcontroller
    Replies: 25
    Last Post: 11-12-2006, 08:45 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts