Help needed with VGA64_TMPEngine. [SOLVED]

ktesibios

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

AntoineDoinel

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

Cluso99

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.

JRetSapDoog

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!!!

ktesibios

Thank you very much for your replies, and for welcome messages.
And also thanks JRetSapDoog for your correction; I meant 7 inches of course
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

AntoineDoinel

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"

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

ktesibios

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

ktesibios

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.



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

Leonardo