Help needed with VGA64_TMPEngine. [SOLVED]

ktesibiosktesibios Posts: 5
edited June 4 in Propeller 1 Vote Up0Vote Down
Hi all, this is my first post to this forum.

For a project I'm designing, I need to use a 7' display, and I tried VGA64_TMPEngine from OBEX as a display manager (thanks to Kwabena Agyeman), which works quite fine. As my display is 800x480, while the engine is designed for 640x480, I would like to use it at full resolution. I tried by modifying the program according to my limited knowledge, with no success. Is there some wizard out there who could share any hints?

Thanks in advance and greetings from Italy.

Leonardo

Comments

  • 7 Comments sorted by Date Added Votes
  • Ciao Leonardo, benvenuto!

    I had a peek at the source, there are constant in multiple places for the number of horizontal tiles (40) and similarly for "last column" (39). Those would become 50 and 49 respectively.
    Memory is allocated at the end of the source, lumabuffer and chromabuffer both need to grow, from 1200 to 1500.
    But I guess you already tried changing that.

    I also see that there's a formula probably related with pixel clock (25_175_000 / ...), and I'm quite confident that should be changed in the same proportion as horizontal resolution increment, if vertical blank has to stay at 60Hz.

    Hopefully Kye will notice this thread, and give you more information.

    You could also try the opposite route, starting from an 800x600 driver and reduce height. The problem of changing the constants and pixel clock remains the same, but you would be more on the safe side assuming that the PASM loop in such driver can handle 800 horizontal res.

    Alessandro
  • Cluso99Cluso99 Posts: 12,738
    edited May 14 Vote Up0Vote Down
    Ciao from Rome :)
    Tiring day at the zoo with out twin 3 yo grandsons. Then the Spanish Steps, Fountain, etc.

    Unfortunately cannot help with your VGA resolution problem as I am without my laptop. Kye's code is usually explained quite well. Alessandro said, you will need to change the parameters. The biggest thing is to ensure you have sufficient buffer space allocated - obviously 800x480 is quite a bit bigger than 640x480. If you don't all sorts of problems are likely to result.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • JRetSapDoogJRetSapDoog Posts: 481
    edited May 14 Vote Up0Vote Down
    For what it's worth, if you're using a 7" (inch, not foot) display like those commonly sold for use with car headrests, the video chip in them can often be configured to stretch 640 pixels to span an 800-pixel wide screen. That doesn't change the driving resolution, but it avoids the vertical black bars that would otherwise appear on the left and right sides (as you likely know). Many such displays can be configured with a small key pad, allowing one to choose whether to stretch the video or not, as well as to change the scanning directions (horizontally and vertically to flip things, etc.). Using the Parallax font that is 16 pixels wide, you get 40 characters horizontally on a line (640/16=40) with standard VGA, whereas, with wide VGA (WVGA), you could get 50 characters (800/16=50), but that would take modifying the driver parameters/code, as mentioned above. For some drivers, perhaps there might not be enough time to feed the video serializer fast enough, but, even if you could, that increases the memory footprint for the video buffer that the driver writes to. For a standard tile-map driver, the increase in the buffer size is not that much, but for the one that you mention from Kye, the increase would be larger since his driver allows mixing in boxes (if I recall correctly).

    Towards the bottom of Kye's driver/engine, the lines "chromaBuffer long 0[1_200]" and "lumaBuffer word 0[1_200]" already reserve a total of 7200 bytes for the single video buffer. So, as a quick guess, I'd plan on that increasing by 25% to 9000 bytes because you'd be moving from a 600-character display (40 cols/row x 15 rows) to a 750-character display (50 cols/row x 15 rows). But a lot of applications could accommodate that.

    Anyway, I just wanted to mention the stretching capability that many of the 7" displays have. And once you configure the video chip to stretch (or not), the setting is stored in non-volatile memory, such that the display will recall your preference/setting even after being powered down. So, if you can live with 40 characters per line (for a tile map display), then maybe you don't need to try modifying the driver. But if you want 50 characters (or if you want to use another driver) and really drive the display at 800 pixels per line (which is the native resolution of most of those cheap 7" displays), then, yeah, driver modifications would be required. Maybe that's feasible at the standard 80 MHz clock rate (depending on the driver details and how much data it needs to fetch from hub), but I'm not sure. You'd definitely have to increase the pixel clock rate above the 25.175 MHz rate to pump out more pixels, as Alessandro mentioned, in order for the display to lock on (recognize) the video signal correctly, otherwise, I guess you'd have chaos (or no signal recognized).

    Update: Oh, wow! Welcome to the forum, Leonardo!!!
  • Thank you very much for your replies, and for welcome messages.
    And also thanks JRetSapDoog for your correction; I meant 7 inches of course :smile:
    I already tried modifying the settings for colums along the code, and buffers' sizes. Kye's comments are quite good. The part I didn't modify is the one related to pixel clock, line sync etc, that is a bit out of my knowlwdge; I'm pretty well informed on audio - sound - MIDi matters rather then video protocol.

    The chromaBuffer and lumaBuffer can be raised to 1500 safely, but there are two more buffers, lumaCache and chromaCache, which appear to be involved in the dynamic building up of video lines, and require 80 longs each (two times the number of columns ?). They are allocated in cog's RAM, and if I try to set them to 100, the compiler tells I'm out of memory for 34 longs. Is this modification really needed or am I wrong here ?

    As of the display, the one I'm using (I don't know if mentioning brand names is allowed in this forum) comes with a driving board that stretches the lines automatically, so as to cover the entire screen. This leads to columns wider than rows' height, that in the end is not so bad. Using the original engine, I fiddled with it with strings, text boxes and different color combinations and was pretty satisfied. On the other side, I must say that my plan is to use 4 of such displays, arranged side by side, so as to obtain a wide screen, intended as a control panel. If 10 columns can be gained from each display, 40 extra columns will be available for a better management of control elements, and this is the main reason why I would like it.
    Ok, I will go deeper with VGA clock and control signals for now.

    Thank you again
    Leonardo
  • AntoineDoinelAntoineDoinel Posts: 277
    edited May 17 Vote Up0Vote Down
    Hi Leonardo

    I didn't notice that the driver does line buffering inside COG RAM... this could effectively be a show stopper for this driver. It won't fit.
    Also, constants related to number of columns are all around the code, it's quite difficult to catch them all whitout overwriting some innocent and unrelated "40" :lol:

    Can I ask you what are your requirements? Do you strictly need the mouse cursor?

    Because I guess it's much more easier to start from Chip's "VGA HiRes Test" (also in OBEX), that already has commented sections for different resolutions.
    Try this to replace the relevant section in that driver:
    ' 800 x 480 @ 60Hz settings: 100 x 40 characters
    
      hp = 800      'horizontal pixels
      vp = 480      'vertical pixels
      hf = 24       'horizontal front porch pixels
      hs = 72       'horizontal sync pixels
      hb = 96       'horizontal back porch pixels
      vf = 173      'vertical front porch lines
      vs = 3        'vertical sync lines
      vb = 10       'vertical back porch lines
      hn = 7        'horizontal normal sync state (0|1)
      vn = 1        'vertical normal sync state (0|1)
      pr = 30       'pixel rate in MHz at 80MHz system clock (5MHz granularity)
    
    

    Note that cell/font size is 8x12, vs 16x16 in Kye's driver.
    Probably sync and porch timings need do be tuned, all the rest (columns/rows) should be "auto-magic".
    Unfortunately I can't test it on real hardware right now or soon, I could only make sure it compiles and generates some output on GEAR emulator.

    Hope it helps
    Alessandro
  • Thank you Alessandro for your information, especially for the VGA setting data.

    I don't need the mouse; in fact I was thinking to cancel all that is related to mouse so as to free some memory, but this might be excessively time expensive, although I like this job for all the good things I'm learning.

    As regards to VGA_HiRes_Test, it was my first choice in this work. Actually, I tested VGAHiResTextGUIDemo1.2 at first with a 40'' TV and it appeared just fine, also because of its library of control objects (buttons, menus etc.). But when I tested it with the 7'' display, I realized that characters are too small, and also "simplified" and not so readable on a small screen, then I gave up with it.

    All in all, the way to go I foresee for now is to cancel/disable all that is mouse-related, as far as I understand it, and set VGA parameters with the data you provided, as time permits.

    Thank you again
    Leonardo

  • Just a quick update to report that I solved the problem and succeeded in extending the resolution of the driver to 800x480.
    First I eliminated the mouse-related parts of the code, then recovering some cog ram, which allowed to extend the cache buffers as required. Then, I modified the relevant parts of the code and variables. There were a few tricky (for me) passages requiring some time to be solved.
    As of pixel clock and sync parameters, the data provided by Alessandro did not work; I tried several different combinations of parameters I found on the internet, and varied them by trials and errors. The best was: maintaining the same pixel clock frequency (25_175_000) of the original code, and setting the following sync values: HFP: 80, HS: 96, HBP: 24, VFP: 10, VS: 2, VBP: 10. The refresh frquency lowered to 49 Hz., as expected, but that is fine for my application.
    Here is a picture of the display; at bottom of the display menu window the resolution and frequency it detected are shown.

    DSCI1277_4.jpg

    Thank you to all who replied. Next step, implementing the touch panel.

    Leonardo
Sign In or Register to comment.