+ Reply to Thread
Page 2 of 11 FirstFirst 123456 ... LastLast
Results 21 to 40 of 212

Thread: Full Color Tile Driver Thread

  1. #21

    Default Re: Full Color Tile Driver Thread

    What's the lowest sweep frequency most VGA monitors will display?

    And can't the pixels be stretched to fit? That's something I've not had a chance to learn yet. On a TV, one just makes a longer pixel, and have it be a factor of the optimal number of pixels.

    Can't that happen on VGA? So then, maybe it's good for 300 pixels, or so, right?

    As for usability, that's a matter of what one wants the display for. Sprites are usable in low RAM situations. Tiles are too, which is how the nice text displays are done.

    The idea being explored here is to present a graphical set of choices. Since the prop has software video, one can simply load what it takes to make that happen, stop it, then load something else from storage. That changes the usability game considerably, which is why I bothered with the tile display in the first place.

    Baggers has a full on Raycaster running on the thing. A few tiles isn't out of the realm of what can be done. Besides, it's fun!
    Last edited by potatohead; 11-15-2010 at 03:52 AM.
    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




  2. #22

    Default Re: Full Color Tile Driver Thread

    Wow.. Very cool indeed!

    Had to make a run to Cleveland today and missed this thread..
    Will definitely be playing catch-up!

    OBC
    Visit PROPELLERPOWERED.COM -:- PMC/PEB 2014 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.

  3. #23

    Default Re: Full Color Tile Driver Thread

    100Mhz prop? Guess I'd better get some faster xtals.

    Sounds like we do TV first?

    Re the use, well, lots of uses. I'm thinking a black screen with six hi-color 64x64 buttons (approx ipad size), and each of those brings up menus of other buttons, or runs binary programs. But you can do other things too - eg have primitive tiles for things like the corners of buttons, and the lines on the side and top, and the fill. Tiles for a check box that is checked, and one that is unchecked.

    Sure, you are not going to fill a screen with these due to hub ram limitations, but if you have a gray screen with a couple of check boxes and a button, and then you refresh off the sd card with brand new tiles and redraw another screen, it would have an 'eye candy' appeal that text based operating systems will never have.

    Of course, it still might be something like Kyedos behind the scenes. Or Catalina (which gives you about 30k of hub ram to play with).
    Last edited by Dr_Acula; 11-15-2010 at 03:50 AM.
    Said Hamlet to Ophelia, I'll draw a sketch of thee, What kind of pencil shall I use? 2B or not 2B? - Spike Milligan

  4. #24

    Default Re: Full Color Tile Driver Thread

    Would some external SRAM allow for more colors here?

    I can picture all kinds of interesting uses for something like this..

    OBC
    Visit PROPELLERPOWERED.COM -:- PMC/PEB 2014 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.

  5. #25

    Default Re: Full Color Tile Driver Thread

    Re external ram, I think potatohead is going to do it all from hub ram.

    External ram may be useful though as it could be faster to load tiles from sram than from an sd card. For flexibility, one would probably have the option to load tiles from either source.

    I'm not sure it would be possible to load external ram on the fly for each frame. Possibly with cluso's ram but the aim would be to design screens that don't require this. Lots of simple screens that you click through rather than putting everything on one screen.
    Last edited by Dr_Acula; 11-15-2010 at 04:35 AM.
    Said Hamlet to Ophelia, I'll draw a sketch of thee, What kind of pencil shall I use? 2B or not 2B? - Spike Milligan

  6. #26

    Default Re: Full Color Tile Driver Thread

    Pretty much needs to be HUB RAM.

    OBC: From here, the paths to more colors involve new video circuits, as in what Coley and Baggers did, or multi-cog tricks, and in all cases, the HUB RAM gets consumed. Using all the Prop colors has always been possible. What changes the game is being able to run programs from external RAM, and SD card, followed by the idea of BLOB style drivers. Kye-DOS means being able to make a fairly large program, fetching things, doing something, then fetching something else. It's like early computers now!

    So, some driver work now makes sense. Before, it was a curio, like for the wiki display, and the fractals, where only a tiny program is needed, or possible.
    Last edited by potatohead; 11-15-2010 at 04:38 AM.
    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




  7. #27

    Default Re: Full Color Tile Driver Thread

    Potatohead, can you briefly describe how the hex codes for colors map to colors? Eg, for TV, you have three pins, right, and a DAC with three resistors, so isn't that only 7 values?

    Looking at the palatte for TV, it seems different to the vga palatte I calculated - eg there seem to be a lot less red and yellows. Is there a mathematical formula to convert RGB values to the single byte hex code you use?
    Said Hamlet to Ophelia, I'll draw a sketch of thee, What kind of pencil shall I use? 2B or not 2B? - Spike Milligan

  8. #28

    Default Re: Full Color Tile Driver Thread

    There is, but I don't understand it that well.

    VGA uses RGB values directly. So it's just levels of red, blue, green.

    TV uses a phase angle for the HUES, and there are 16 of those. Google the color wheel, and dividing the wheel into 16 slices gets you the kind of formula you need to work out the hues. Edit: And how the signals add together limit things some. Just for extra fun, we can shift these some in the TV cog, by altering the reference signal, improving reds and yellows, at the expense of greens and probably blues... TV's are messy.

    Intensities range from 02 to 07, and are just added to a hue. If you broke the RGB down to HSV, those values would map over more easily.

    Lower order bits are intensity, higher order bits are hue, some unused with TV.

    Color = hue(0-17) + intensity(2-7) is the space I use, with the CLUT table you found.

    Another oddity is any hue + intensity 7, is outta spec, and shows up as a higher saturation color. That's the top row in graphics_palette.spin

    If you look at the wiki page I did, ALL the propeller colors are in that table on the page, and there are two high-saturation color sets, and they are hue shifted from the ordinary colors. Look at the strip along the bottom, and up the right hand side. Those are all "pure" Propeller TV colors. About 96 of those will display well on all devices. Some devices reject the low intensity colors, and some reject the brightest, out of spec colors too.
    Last edited by potatohead; 11-15-2010 at 05:26 AM.
    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. #29

    Default Re: Full Color Tile Driver Thread

    Re: 8 pixel waitvid, could be: waitvid colors, pixels

    where "pixels" = %%00112233, for the same 320 pixel resolution found on TV. That's the thing to try on my next session.

    So, scratch the 4 pixel frame, never more, never less. It can vary. It might have to on the higher sweep rates.
    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




  10. #30

    Default Re: Full Color Tile Driver Thread

    I looked up NTSC and it makes more sense now.

    Ok, the color wheel http://en.wikipedia.org/wiki/Color_wheel is great for colors but it doesn't show shades of gray, nor shades of gray with slight color added (gray with a tinge of blue). I think you need three axes to describe all the colors? (hue/saturation/lightness or red/green/blue).

    So "Lower order bits are intensity, higher order bits are hue" - what does lightness? http://en.wikipedia.org/wiki/HSL_and_HSV

    So say we take the first two lines of the data

    byte byte $02, $03, $04, $05, $06, $07, $07, $07 'Six intensities
    byte byte $09, $0a, $0b, $0c, $0d, $0e, $88, $9f

    Is the first line the shades of gray?

    And is the second line a combination of intensity and color, or do you pass these as two separate bytes?

    I'm just thinking if we are going to preprocess a bitmap, may as well process it so the cog does the absolute minimum. Eg if it is easier to pass a long to a value rather than a byte, then pre combine pixels into a long.
    Last edited by Dr_Acula; 11-15-2010 at 10:45 AM.
    Said Hamlet to Ophelia, I'll draw a sketch of thee, What kind of pencil shall I use? 2B or not 2B? - Spike Milligan

  11. #31

    Default Re: Full Color Tile Driver Thread

    So, I looked back at my calculations and its actually very possible to do this.

    By strenching the pixels across the screen by setting the vscl register you will have plenty of time to get the next four pixels.

    So, I think 160x120 at 1 byte per pixel will be very much doable. The only problem I see is that you won't be able to double buffer...

    So, now the real question is: Would this driver be usable if you can't do that. 160x120 = 19200 pixels... That's alot of elements to clear and change at 60 FPS. Changing them any slower will result in screen crawl.

    ... So, unless the resolution gets even smaller the screen will never be able to be updated nicely.
    Nyamekye,

  12. #32

    Default Re: Full Color Tile Driver Thread

    Dr_Acula

    Translating from Propeller luma+hue to 24 bit RGB is easy, just start with the CCIR 601 YCrCb to RGB formulas. RGB to Propeller luma+hue is more problematic as there are only 102 colors and they aren't arranged nicely in the RGB color cube. It might be possible to try to do the remapping as the image is loaded into HUB RAM, but I don't think it would be possible to do it on the fly as part of the video driver.
    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)

  13. #33

    Default Re: Full Color Tile Driver Thread

    Interesting driver... I'll keep an eye on this thread

    Quote Originally Posted by potatohead View Post
    Ok, I've reached a first pass.

    Tiles are 4x8. I know that is a tiny tile, but the trade-off is very good screen positioning. Groups of tiles can be handled in SPIN.

    Resolutions are: 40, 80, 160, 256, 320. Right now, 320 pixels requires 96Mhz. Probably that restriction can go away with some more Cluso out of order instruction mo-jo, like we did on Potatotext.

    Edit: BTW, if somebody has a fast board, the thing will probably do 512. If you try it, let me know the clock

    I'm thinking the way to go here is a tile file, where the binary values are just in the file, with up to 256 tiles possible. Any pixel may be any color within a tile. No restrictions, but for the number of tiles possible.

    This archive can be tinkered with. There is more to do, but 8K of full color tile data is possible with this one. Maybe try the SD card tricks with two of the menu tiles?? More to come, I'm sure, but this is enough to prototype with.

    **I need some sexy tile data, for screen shots.

    No screen SPIN routines are written yet. I've just written a few sample tiles, and put their values on the screen manually to verify the display driver is actually working as given.

    I would suggest taking a image, and encoding it in tiles. The tile format is simple. Starting from the base address of where tiles are stored, each tile is 8 longs, stored sequentially, up to 256 tiles.

    Tiles can be stacked on the screen such:

    1,4,7
    2,5,8
    3,6,9

    That block of tile numbers would equal a 12x24 pixel image on screen. To place the image, just put the tile numbers in the screen array where you want the image to appear, multiple places, if desired.

    Stored in the RAM such:

    Tile one longs
    0
    1
    2
    3
    4
    5
    6
    7
    Tile two longs
    0
    1
    2
    3
    4
    5
    .
    .
    .

    Each long is 4 pixels on screen. The screen is the number of pixels / 4, with one byte indexing the tile for each screen cell. 320 pixels = 80 screen cells horizontal, 25 screen cells vertical.

    Vertical resolution is 200 pixels.

    I'll try to build some some tiles to illustrate where it is so far. I'm also seriously thinking about trying it the Parallax tile way, because it might be more flexible. Deffo want a bigger tile, or larger number of tiles too.

    This is just barely enough to prototype reading some tiles from SD to see what might could happen.
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / Products and Projects:
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
    SchoolBoard ][ Solderless Educational Development Board (Propeller, FPGA, more)
    Advanced prototyping & Parallax Propeller boards - Follow @Mikronauts on Twitter

  14. #34

    Default Re: Full Color Tile Driver Thread

    Thanks for looking Kye. I won't have a shot until later today. All I did was run your driver and look the really clean code over. Again, nice!

    Pretend the solution is not clean for a moment. Do you think a unrolled loop would do 320? Maybe just stuff 80 waitvids in there along with the add, required for the index!

    And the final product will only need to read from a HUB buffer, for a single scan line. Another COG will build from the "screen" tilemap, writing the product of that into the buffer, as the VGA COG is drawing it. What I do, is start the graphics building, right after the VGA cog enters the front porch. That gives the graphics COG a head start writing the buffer. It tends to run a bit more slowly at higher resolutions, just finishing as the VGA COG fetches the last visible waitvid frame.

    If any more speed is needed, multi-COG is needed, or the buffer needs to be a double buffer, which I'm considering anyway. A single buffer is lean, but causes a timing problem, if multiple COGs are all combining data for the buffer. Double makes that easier.

    Another thing that could be done is to adjust the porches, so that a different primary resolution is drawn, making something between 160 and 320, worst case, a factor, so that the highest possible at 80Mhz can be done, or we just do 96 or 100Mhz. I've xtals for both. It's possible to make a "remainder" waitvid frame too, so that non-factor resolutions work. If those things are done, the graphics COG gets a longer porch time for it's run up ahead of the VGA COG, and the display narrows by some small percentage. What I don't know here is whether or not digital monitors will sync to stuff like that. Analog is no problem. I've seen other PC applications do tricks like that, and TV's don't care what you do after the sync, happy to display a mess, if you code one. My VGA is a analog one, BTW, though I could test finished code on various digital ones at work.

    The end product will be a tile driver. It's by nature, double buffered, in that the tile can be written, while off screen. The "screen" memory, unlike a bitmap, is simply a index of tile numbers, where each tile can be positioned anywhere on the screen grid.

    A small stack of tiles acts very much like a bitmap too. That's actually almost how the Parallax drivers work, the difference being "the screeen" is a list of tile addresses, but same concept applies.

    Screen manupulation can happen two ways. One is to build the tiles off screen, then "pop" them on the screen by writing a few values to the "screen" array. They will appear on the next scan of the monitor. The other, is to write some tile values, so the tiles are seen, then operate as one would a bitmap driver, and that can be seen while drawing, and is basically single buffered.

    Finally, since the tiles are indexed, common graphic tiles can be used in multiple places on the screen. Unlike the Parallax driver, which has color redirection, this one works in absolute color, so the common graphics would need to have the same color, not true of the Parallax tile drivers, because they also have a colors array to address that.

    This particular driver allows 8K of unique tile data. That's going to get expanded on the next pass. This was a proto, "is it worth it?" pass, basically done at Dr_A's request, because I had code that was close.

    For what it's worth, the Parallax driver, can run single buffered, and use a small pool of tiles off screen to render things, popping that onto the screen, exchanging it for another small region, in a sense, double buffering a fractional screen, trading flicker for tearing in the image during changes. Doing that round robin style for a whole screen is something I've always called "ripple draw", because the tearing can be seen, as can image change errors over time, but it doesn't flicker much, if any at all. For some things, like perhaps a aircraft flight simulation, or instrument panel, it can work well. Partial buffered I guess is the right way to describe doing that with tiles.

    I'll have to code this as a demo one day, also doing common tiles with different colors and using color redirection to "pop" things onto the screen with no flicker. Tiles are very useful that way, and were used in older computers that had limited fill rates. Color can be used to hide a image already drawn. When a visible color is assigned, the entire thing will be displayed next frame. On the Parallax driver, progress bars, check boxes and other things could be on the screen, shared, and just made visible or not, kind of like those stereo displays with the elements just needing to light up, depending on state, using very little HUB RAM, and no requirement for a double buffer.

    Lots of great graphics, Propeller relevant, mo-jo is to be had by looking at the very late 70's through late 80's. That's when graphics really started to take off, and there were a lot of trade-offs in speed, and overall screen color / resolution capability. The Apple ][ is where I first saw "ripple draw" being used to manage a whole frame. It was possible to draw a smaller region quickly enough to avoid major flicker, and so that was done, dividing the frame into a few regions. Effective frame rate for the entire image to change was, like 15Hz, but there was no flicker, and detail regions could change much quicker than that. Apples had no color redirection though. Saw that used on many other computers, often to great effect. Best thing since sliced bread, if your fill rate is low, IMHO.

    Finally, there is dynamic drawing. Baggers has many examples posted here. With dynamic drawing, the screen does not exist as a static entity, like a bitmap. It's just created on the fly, as the beam is drawn. Best example of this is the old Atari VCS, which had NO frame buffer, and only 128 bytes of system RAM, yet was capable of drawing "Space Invaders" nicely. In that scenario, one draws only what is needed just in front of the monitor beam, doing it again, each frame.

    Props are well suited to that, and single buffer tricks because they are actually quite fast compared to their ~320 - 640 pixel resolution. (I know they go higher, but those two are the ones where the chip shines, IMHO) Props also can do stuff in parallel, which helps considerably. For example, on a bitmap, there could be multiple regions, where each is managed by a COG, contributing to one single buffer display, no flicker. That's difficult to do anyway, but way more difficult on a interrupt based CPU. Props just make it a management problem. Sweet!

    Anyway, in the end, the simple bitmap is the hardest one to deal with. It's very demanding of RAM, and requires the most operations to fill, but it's the easiest to code for. On a Prop, because of the HUB RAM, other display tricks are often needed to get a significant display. Honestly, that's one of the big attractions of the Prop for me. It's software defined video means pretty much all of those things are on the table, and that's fun for me, so here I am.


    Quote Originally Posted by Kye View Post
    So, I looked back at my calculations and its actually very possible to do this.

    By strenching the pixels across the screen by setting the vscl register you will have plenty of time to get the next four pixels.

    So, I think 160x120 at 1 byte per pixel will be very much doable. The only problem I see is that you won't be able to double buffer...

    So, now the real question is: Would this driver be usable if you can't do that. 160x120 = 19200 pixels... That's alot of elements to clear and change at 60 FPS. Changing them any slower will result in screen crawl.

    ... So, unless the resolution gets even smaller the screen will never be able to be updated nicely.
    Last edited by potatohead; 11-15-2010 at 03:11 PM.
    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




  15. #35

    Default Re: Full Color Tile Driver Thread

    The second line is a combination of hue and intensity. Only one byte is used for color definition, and it has a intensity bit-field, and a hue bit field.

    Yes, a third axis is needed, however the Propeller saturation is fixed at two levels. There is the faded one, common to most of the colors, and the overly intense one, common to a few of them. The color wheel idea was just to communicate how hue ends up on the screen. Sorry about that.

    Quote Originally Posted by Dr_Acula View Post
    I looked up NTSC and it makes more sense now.

    Ok, the color wheel http://en.wikipedia.org/wiki/Color_wheel is great for colors but it doesn't show shades of gray, nor shades of gray with slight color added (gray with a tinge of blue). I think you need three axes to describe all the colors? (hue/saturation/lightness or red/green/blue).

    So "Lower order bits are intensity, higher order bits are hue" - what does lightness? http://en.wikipedia.org/wiki/HSL_and_HSV

    So say we take the first two lines of the data

    byte byte $02, $03, $04, $05, $06, $07, $07, $07 'Six intensities
    byte byte $09, $0a, $0b, $0c, $0d, $0e, $88, $9f

    Is the first line the shades of gray?

    And is the second line a combination of intensity and color, or do you pass these as two separate bytes?

    I'm just thinking if we are going to preprocess a bitmap, may as well process it so the cog does the absolute minimum. Eg if it is easier to pass a long to a value rather than a byte, then pre combine pixels into a long.
    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




  16. #36

    Default Re: Full Color Tile Driver Thread

    For a first pass RGB lookup table I took the screenshot potatohead made http://forums.parallax.com/showthread.php?t=126099 and generated the attached file for the 134 colors (6 grey + 8 * 16 colors).
    Attached Files Attached Files
    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)

  17. #37

    Default Re: Full Color Tile Driver Thread

    Ok. Silly question time.

    How do we add text to the screen?

    We can't have 80+ tiles just for text.
    There must be a way switch modes (per-tile?) for low resolution text.

    @ericball, I've been looking for that table. Thanks.

    It does map to the clut right?
    And the clut is used in this. Right?

    Last edited by jazzed; 11-15-2010 at 03:28 PM.

  18. #38

    Default Re: Full Color Tile Driver Thread

    Quote Originally Posted by jazzed View Post
    @ericball, I've been looking for that table. Thanks. It does map to the clut right?
    It's a simple list of color number to 8R 8G 8B value translations. The RGB values are not authoritative, but should be "close enough" if someone wanted to try to work out how to perform the reverse translation.

    Note: due to how the Propeller generates color, colors $x8 and $xF are the same hue and luma as $xB and $xC (respectively) but with triple the saturation.
    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)

  19. #39

    Default Re: Full Color Tile Driver Thread

    Right now, on this one, it's tiles = text.

    I've not had good luck mode switching waitvids mid-display. The decisions required in the video COG consume time, and will on occasion miss the waitvid data latch window, resulting in extra pixels, or snow. That said, modes per tile would be a excellent use for the unused bits present, if tile definitions were to move to a word per tile. Maybe that's worth another play. We know more about the waitvid now compared to the last time I personally tried that.

    Coupla ways this could go:

    Add a COG to overlay a text screen, right on top of the tile screen, crunching bits to fill the buffer. (maybe)

    Multi-mode tiles. (maybe) Divide screen into vertical regions, where a given region could be text tiles(2 or 4 color), or graphics tiles (all colors). (possible)

    Add to the number of possible tiles and just draw text, or define enough text to suit the display. (possible, and easiest) Probably costs 4-6K though.

    One last method would be to just fire off a monochrome text COG for TV, and output to the same pins. Works for text on black, but not text on white. Same for VGA, only that could be color. (maybe) Linus showed how to really sync COGs.

    Other??? Any and all comments welcome here.

    That's one of the "is it worth it?" task questions! Everything costs something.
    Last edited by potatohead; 11-15-2010 at 03:44 PM.
    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




  20. #40

    Default Re: Full Color Tile Driver Thread

    Quote Originally Posted by potatohead View Post
    What's the lowest sweep frequency most VGA monitors will display?
    Line-rate of CRT's bottomed out at 28 kHz. It was frustrating trying to find monitors that would be happy with the 18-24 kHz range. And even specialist scan-converter units were never spec'd for it either. It was always boring old video to VGA or VGA(+) to video.

    As far as I know that hasn't improved with modern LCD's even though they all have the fancy scan-converters built right in that, theoretically, wouldn't have any problem at all handling pretty much any lower frequency.

    And can't the pixels be stretched to fit? That's something I've not had a chance to learn yet. On a TV, one just makes a longer pixel, and have it be a factor of the optimal number of pixels.

    Can't that happen on VGA? So then, maybe it's good for 300 pixels, or so, right?
    Yep, just the same for VGA signaling. Tweak the pixel clock to suit.

+ 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, 10: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, 11:08 AM
  3. Color applet for tile driver
    By Rayman in forum Propeller 1 Multicore Microcontroller
    Replies: 2
    Last Post: 09-05-2007, 05: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, 12: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, 07: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