Shop OBEX P1 Docs P2 Docs Learn Events
Full Color Tile Driver Thread - Page 6 — Parallax Forums

Full Color Tile Driver Thread

123468

Comments

  • KyeKye Posts: 2,200
    edited 2010-11-26 06:02
    @Dr_Acula - Yep, that would be how you could do it. FSRW should be abe to give you more frames per second. Look into the displaySync method if you need to fix flicker issues.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-26 15:37
    Hi Kye, thanks for the PM. I'd love to write a review for your SD driver code. Only problem is - I can't seem to be able to log into the Obex. Do you know if the passwords changed with the forum migration?

    I'm using more and more 'Kye code'. I've got a new PCB that just arrived today with a mouse port, so in the near future I'll be looking to add the combo mouse/keyboard object you have as well.

    Re the tile driver, the attached picture is fake, as the propeller is not really browsing the internet, but it does show that colors look good, and it also gives an indication of how much screen space you would get. One would need a html translator that knows about the small screen. And of course, there is no memory left in the propeller, so this would have to be running in Catalina in external memory. And some C code to build new tile maps on the fly (a copy of the existing vb.net code). There must be some C code out there that can translate html. And decode jpegs and bitmaps.
    879 x 843 - 107K
  • JT CookJT Cook Posts: 487
    edited 2010-11-27 11:38
    I was able to get the program working on the C3 and it looks pretty awesome! I also tried it on my HDTV and it worked there as well.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-27 14:22
    With some help from Baggers, I've almost got the TV display operating with the render COG. 256 pixels x 200 lines. I'll post shortly after some cleanup and final debugging.

    I'll include a TV folder, with data and such, running basically the same demo bit. That way, people can build from there, using either device.

    @JT: Excellent!

    Screenie from the same data converted for TV attached. There is a purple supposed to be transparent ending up green problem in the font. Needs work, but the little figure 8 sprites show the renderer working properly.

    :)

    Zip archive soon. Just need to tidy the mess
    720 x 540 - 207K
  • JT CookJT Cook Posts: 487
    edited 2010-11-27 15:37
    My plan is to merge that with my TV graphics driver and maybe port over some of my games to VGA. The hard part will be converting the graphics :)
  • jazzedjazzed Posts: 11,803
    edited 2010-11-27 19:49
    This is looking better all the time.
    Having a TV driver with the same functionality as the VGA driver would be great.
    Now if only the start interface could be as simple as start(basepin), that would be excellent.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-27 20:26
    Well, I'm going to keep it lean on this one. Demoboard @ 80, with people doing mods from there.

    There are a lot of boards now, lots of clocks, and lots of drivers. The standards work is very significant, and that's not something I want to own, mostly because it would take my hobby time completely to do. It's hard to test without maintaining a lot of boards too.

    So yeah, me too :(

    I've attached the TV modded driver. Some small work to do yet, but it's basically up and running with the same calls as the VGA one. Good for a play. I've got notes and such to pack in there about the converter, and the mod to the renderer. Might make that a constant, and just have one renderer file too.

    Tomorrow for that.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-27 20:58
    potatohead wrote: »
    Well, I'm going to keep it lean on this one. Demoboard @ 80, with people doing mods from there.

    There are a lot of boards now, lots of clocks, and lots of drivers. The standards work is very significant, and that's not something I want to own, mostly because it would take my hobby time completely to do. It's hard to test without maintaining a lot of boards too.
    A "Properties.spin" file should be sufficient to satisfy any user's config.
    Simple, no dependencies on what other pins might be connected, etc....

    Such a file can define clocks and pins for any board.
    Developers can add new board types as necessary.
    Users can reference the file that works for them.

    No headaches, No bias, No multiple file source edits.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-27 21:24
    There are basically several source code trees for video drivers. Parallax, CardboardGuru, Eric Ball, others...

    There are variations on how timings are calculated, and pin use, etc...

    And there are variations on boards, as well, as circuits. Finally, the demands of the drivers themselves mean some variation, running on some boards, not on others, etc...

    If you want to start such a project, or rope somebody in, I'm happy to share what I know, and run something on occasion on the boards I have. The know how to configure all the drivers is more or less here, just not well organized. That's one start. Maybe not too tough. Then come the many code changes... I'm just not up for that right now.

    When OBC went down that road, ownership of that project was clearly significant, and it kind of just splattered. Out of that came the Coley autodetect, and that's kind of cool, but not all that inclusive, though perhaps it could be extended some. Don't know. I like it, but got the same query despite it being there.

    Honestly, I just want to get the TV function operating well, mostly because Baggers was nice enough to jump in with the sprites and a great VGA timing, which advanced things a lot! I had just started on the drivers that were close, and he had pretty much nailed it already. (wonder just what he has cooking that we don't know about? LOL!!) So, it's nice timing.

    The calls are all there, and the renderer and such work. Just need a clean up pass for some signal options, comments, and such, and it's at a stage where people can then build on it. That was the original intent anyway.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-27 21:46
    I'm used to the simplicity of the Parallax drivers - others are too.
    Sure all the other drivers add value, but not everyone uses them.

    I saw and participated the mess that ensued after the OBC foray :)
    We can get more mileage out of localized driver specific properties files.
    That way we don't have to define the universe.

    We use a simple userdefs.spin file for ZOG to define a few basic items.
    There's been no complaints at all, and it solved the problems.

    It should be pretty easy to extract the constants out of the HwInit method
    as a start. The board and driver owners should add/correct the properties.

    No point in changing the old drivers, but if these two drivers could be
    friendly to more people, that would be great.

    I'll contribute something more substantial after a fresh cup of coffee tomorrow.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-27 22:55
    Properties.spin sounds interesting.

    So - that would define things like the pins you use for the video driver, sd card etc?

    The solution for multiple platforms on the emulation projects has been multiple #ifdef statements at the beginning of the code. And possibly through the code, and that is where things get messy.

    Only problem there is that you need BST (or other compilers) and can't do a 'quick and simple' test on some code using the prop tool.

    I like quick tests!

    Ok, so is the idea that every program you release has a line in the OBJ section:
    properties : properties.spin

    and in that is a list of CON declarations that then become common to the entire program?

    I like the concept!

    on another topic...

    @baggers/potatohead - the 256x240 driver is amazing and is probably the best resolution we are going to get with full color. I've gone some way towards automating scaling having discovered the vb.net instructions to rescale images. However, 256x240 is not 4:3 and it seems most of the other video drivers are. Are there any technical reasons a similar driver cannot be written that is 256x192? Would you do this with different sized tiles, or would you do it with less than 30 rows?
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-27 23:16
    Well, the TV driver is 200 lines, which is a whole lot closer!

    I'm not sure whether or not the VGA will run at 320, due to the sweep timings. Maybe without the color or operation happening... That's going to make data conversion and on the fly creation harder though.

    Could run fewer rows, but then the actual display shrinks too. That means tweaking the screen.

    Kind of funny how it all worked out. The TV is probably looking near best case at 256, but can run 320. VGA would rock hard at 320, but that's a stretch! Too bad, that can't be flipped around.

    Problem is the TV range timings just don't work on very many displays, which would limit the driver. As it is, Baggers found a good one that's pretty low --lower than the one Kye was running.

    Re: Properties files.

    Well? If it works with the Prop Tool, I'm eager to see how that goes. Honestly, once the last few bits are folded back into the TV part of this the resulting package will have VGA and TV, horizontal resolution matched, converter that will do either one, and the demo able to run on either one.

    Jazzed will post some stuff up soon enough, so we can take a peek!

    Re: Art.

    Do you have any vector art? Ever run anything like Inkscape? (free software vector SVG editor) Art done with that thing can be output at the aspect needed. Just a thought.

    Yeah, above this resolution, it's deffo a 4 color scene, with various ways to encode different colors. Scan line palettes, tile palettes, sprite palettes are basically the options.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-28 00:41
    Could run fewer rows, but then the actual display shrinks too. That means tweaking the screen.

    Yes, I'm still a bit confused about that. You have a 640x480 vga screen and it displays 4:3 and fill an area x cm by y cm on the screen. Shrink to 160x120 and it fills the same physical area on the screen. That makes sense.

    But display it 256x240 and it still fills the same physical area on the screen.

    What has changed? Are squares stretched? Is 4x8 something that is hard to code any other way? What actually is a square tile?

    For example, 640x480, then a 3x3 pixel square will display square on the screen, right? So will a 6x6 and 12x12. If 256 is the max squares per row, then is there a divisor that divides into that, gives a square tile and works out ok with Longs (4 bytes) as well?

    Could a 256x192 driver be coded that fills the same screen as, say, 160x120?

    Of course, if it were possible to push the VGA to 320...
  • jazzedjazzed Posts: 11,803
    edited 2010-11-28 11:49
    Here is potatohead's TV zip with changes to support a TvProperties.spin.
    Configuration comes down to choosing a few parameters and moving the file.

    TvProperties.spin is not usable with VGA just now because of the different
    configuration methods. Also TV and VGA pins are just different by nature.
    A calculation for ifrqa rather than some constants would be an improvement.

    While the startup interface is not as simple as tv.start(pin), this method does
    centralize the changes in a user replaceable file which is advantageous.

    The same idea can be used with the VGA package and potentially merged.
    I'll leave this for someone else as an exercise as my time is limited today.

    --Steve
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-28 13:00
    Dr_A, it's the relationship between the horizontal and vertical sweep signals that determines how the pixels will end up on the display.

    The timings in use right now are not 4:3, thus the display won't be 4:3.

    Other timings could be used, but they might not all display. The trick on these things is to use ones that are well recognized by a variety of devices, and that are slow, so the Prop has time to get pixels done.

    At this sweep frequency, displaying fewer rows would change the screen refresh rate, and spread them out on the monitor, leaving gaps between the pixels, IMHO.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-28 14:18
    @jazzed - yes that would simplify things. You could swap between vga and tv by changing one config file.

    @potatohead - that makes sense. With 256x240 I'll look at a little vb.net routine to scale 640x480 to 256x240.
  • BaggersBaggers Posts: 3,019
    edited 2010-11-29 06:09
    Hi Guys, in collaboration with Potatohead, I now release the latest version.

    You can now with just a simple change use TV or VGA.
    ( Also set SCAN_YCOUNT to 200 for TV or 240 for VGA. to tell the renderer what line to stop at )

    Now with Button printing too, which draws a box, and puts text on it.

    Enjoy,
    Baggers.

    I've modified the bmp8tolite too.

    to convert mario.bmp for TV
    bmp8tolite mario -novga -vga4x8

    to convert mario.bmp for vga
    bmp8tolite mario -vga4x8

    to convert font.bmp for TV
    bmp8tolite font -novga -norep -vga4x8

    to convert font.bmp for VGA
    bmp8tolite font -norep -vga4x8
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2010-11-29 10:36
    Perfect!

    This gives me "exactly" what I need to finish an old demo that was set aside due to video driver limitations.

    Thanks Baggers & Potatohead!

    OBC
  • BaggersBaggers Posts: 3,019
    edited 2010-11-29 10:46
    Perfect!

    This gives me "exactly" what I need to finish an old demo that was set aside due to video driver limitations.

    Thanks Baggers & Potatohead!

    OBC
    You're welcome OBC, look forward to seeing your demo.

    Baggers.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-29 12:48
    @Baggers. Impressive work as usual.

    Here's an updated TvProperties.spin file if anyone cares to use it.
    Maybe a VGA variant will come later. VGA is much easier to use though.
    {{
    TvProperties.spin
    Copyright (c) 2010, various contributors
    See MIT license for terms of use.
    }}
    
    {{
    ----------------------------------------------------------------------------
    Users select TV properties for their hardware platform
    in a single, well defined, and easily replacable file.
    
    This file should be modified by the user and put in a library folder
    separate from the downloaded folder. Once the file is copied and
    modified, the file should be removed from the download folder.
    
    The file can then be referenced by the driver as:
    
    1) Propeller Tool users: copy the file to the Propeller Tool library folder.
    2) BST/BSTC users: keep modified file in the user specified library folder.
    ----------------------------------------------------------------------------
    }}
    
    CON
    {{
    '' USER DEFINED CLOCK PROPERTIES:
    ----------------------------------------------------------------------------
    clkmode is used to define the clock parameters used by the program.
    xinfreq is used to define the frequency of the crystal being used.
    sysclock is used to derive an IFRQA or calculated clkfreq value.
    }}
    
      clockmode = xtal1 + pll16x          ' enable external clock and pll times 16
      xtalfreq  = 5_000_000               ' set frequency to 5 MHZ
      sysclock  = xtalfreq*16             ' sysclock frequency is xtalfreq * pllx
    
    {{
    '' USER DEFINED VCFG PIN PROPERTIES:
    ----------------------------------------------------------------------------
    basepin is the first pin used by the TV DAC
    ifrqa   is value to use with the TV COG frqa register - prefer calculation
    }}
    
    ''NTSC Demoboard & Hydra @ 80MHz
    ' basepin= 12
    ' ifrqa = $16E8_BA2F            ' accurate ifrqa value for NTSC @ 80MHz
    
    ''NTSC GadgetGangster SDRAM Module TV  @ 80MHz
      basepin= 20
      ifrqa = $16E8_BA2F            ' accurate ifrqa value for NTSC @ 80MHz
    
    ''NTSC Hybrid @ 96MHz
    ' basepin= 24                   ' Hybrid
    ' ifrqa = $1317_45D1            ' accurate ifrqa value for NTSC @ 96MHz
    
    ''NTSC IFRQA value for 100MHz
    ' ifrqa = $1253C824
    
    {{
    '' DERIVED IFRQA VALUES
    '' If you have an odd frequency use this. The method is not accurate, but
    '' seems to produce reasonable values for a range of sysclock frequencies.
    '' You can always comment out this and use the ifrqa values above.
    '' If the value is not suitable, open your calculator to 64 bit mode and
    '' enter the following (AOS or infix - RPN postfixers figure it out):
    '' 7159090.1/sysclock*268435456 then convert to hex if you like.
    ----------------------------------------------------------------------------
      ntsc  = 7_159_090_9
      ntscm = 268_435_456/(sysclock/1000)
      ifrqa = (ntsc/10000*ntscm)<<4
    }}
    
    {{
    '' Derived values for driver
    ----------------------------------------------------------------------------
    }}
      group  = (basepin/8)          ' group selects P0-7, P8-15, P16-23, P24-31
      nibble = (basepin/4) & 1      ' nibble selects the 4 bits of a group to use
      vmode  = 2 | nibble           ' vmode selects the video mode in VCFG
    
      ipins = (group<<9) | (7 << (nibble*4))
      idira = %0111 << basepin
      ictra = %0_00001_110_00000000000000000000000  ' CTRA PLL Mode VCO/2
      ivcfg = (%0_00_1_0_1_000_00000000000 << 12) | (vmode << 29) | ipins
    
    
    {{
    All spin files must have at least one PUB method.
    This method satisfies that requirement and is not to be called.
    }}
    PUB none
    
    {{
    ----------------------------------------------------------------------------
      MIT License:
    ----------------------------------------------------------------------------
    Permission is hereby granted, free of charge, to any person obtaining a copy
    of this software and associated documentation files (the "Software"), to deal
    in the Software without restriction, including without limitation the rights to
    use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
    of the Software, and to permit persons to whom the Software is furnished to do
    so, subject to the following conditions:
    
    The above copyright notice and this permission notice shall be included in
    all copies or substantial portions of the Software.
    
    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
    FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
    COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
    IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
    CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.                         
    ----------------------------------------------------------------------------
    }}
    
  • BaggersBaggers Posts: 3,019
    edited 2010-11-29 13:43
    Cheers Jazzed,

    I'll incorporate that for the next release :D and do a VGA version too.
  • JT CookJT Cook Posts: 487
    edited 2010-11-29 13:48
    Does the bmp tool support other sizes besides 4x8? I have my own rendering driver that I am going to try to plug into it which uses different sizes for sprites and tiles.

    Also what are the rules for VGA colors? Is it $V(sync)H(sync)RRGGBB for the byte setup?
  • markaericmarkaeric Posts: 282
    edited 2010-11-29 15:34
    I know my question is quite contrary to the premise of this thread, but since this is quite active, and there has been slight mention of it, I'll ask anyways..

    How exactly would increasing the greyscale depth work? For instance, would 6bpp require 6 pins for an r2r ladder, or would it actually require 64?

    I'm asking this because I've been doing a little experimentation today to see the results of colored photos converted to various lower greyscale bit depths, and found detail to remain quite good - especially if dithering was used. While not as pretty for games, it's certainly much better than a similar bit-depth in color for photos - a huge plus for the previously discussed wiki reader. Any thoughts?
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-29 17:04
    Would a full scan TV driver, doing 240 lines be useful?

    It would be overscan on most all ordinary TV devices, though it may be visible on small LCD displays, and will be visible on PC capture type devices.

    Baggers and I tossed that around early this morning. It's possible to do, but I don't know if practical. Targeting that for a next release actually.

    BTW: @Jazzed, you will find a border color setting in the bottom of the TV driver, along with the other core parameters. :)
  • BaggersBaggers Posts: 3,019
    edited 2010-11-30 01:20
    JT Cook wrote: »
    Does the bmp tool support other sizes besides 4x8? I have my own rendering driver that I am going to try to plug into it which uses different sizes for sprites and tiles.

    Also what are the rules for VGA colors? Is it $V(sync)H(sync)RRGGBB for the byte setup?

    Hi JT,
    yes, it supports bitmaps, so if you line your sprites or whatever in a column image, you can grab it all as bitmap

    instead of -vga4x8 you need to do -bitmap2 or bitmap4 or bitmap16 or bitmap256
    and -vga if you want to grab vga colours instead of TV
  • ericballericball Posts: 774
    edited 2010-11-30 04:17
    markaeric wrote: »
    How exactly would increasing the greyscale depth work? For instance, would 6bpp require 6 pins for an r2r ladder, or would it actually require 64?
    6bpp would require 6 pins. Most of the answers to your questions can be found on page 4 of this thread.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-30 05:09
    Just to take that further, can you do grayscale on vga? eg say you have 6 pins and go into a R/2R array, then output that to the red/green/blue pins joined together. Any issues with impedance matching?
  • markaericmarkaeric Posts: 282
    edited 2010-11-30 17:00
    ericball wrote: »
    6bpp would require 6 pins. Most of the answers to your questions can be found on page 4 of this thread.



    My apologies for blabbering - had I done a little homework like I did shortly after posting, I would have actually understood an R2R ladder circuit. Typical case of wanting to talk instead of listen.

    Anyone else interested in a ~6bpp greyscale composite driver?
  • ericballericball Posts: 774
    edited 2010-11-30 18:44
    Dr_Acula wrote: »
    Just to take that further, can you do grayscale on vga? eg say you have 6 pins and go into a R/2R array, then output that to the red/green/blue pins joined together. Any issues with impedance matching?

    Unfortunately, simply connecting the RGB lines together would only get you 0..3*3 == 0..9 or 10 levels which would net you 7 levels of grey + 3 sync.
    markaeric wrote: »
    Anyone else interested in a ~6bpp greyscale composite driver?

    I did a low res high grey driver: http://forums.parallax.com/showthread.php?t=116828

    See also: http://forums.parallax.com/showthread.php?t=119588
  • JT CookJT Cook Posts: 487
    edited 2010-12-01 18:14
    Baggers: The bmp converter worked pretty well! After some tweaking I was able to get X-Racer running on the VGA driver. It still needs some tweaking because I need a way to plug in vsync and adjust the VGA driver to display 192 lines instead of 240 lines ( filling it with just black lines or something).
Sign In or Register to comment.