@VonSzarvas @evanh @Rayman
Connected HyperRAM to P2 EVAL Rev B
HyperHDMI_16bpp_4g.spin2 moves Lorikeet.bmp from SD card to HyperRAM to Display https://parallax.com/product/7-hdmi-display-800-x-480/
Where to now? See FlexProp PST Terminal.
That's good- proves your monitor and hardware is working ok.
You ask... Where to now?
What are you wanting to do next? Write text over the image?
I'm not familiar with the rayman and rogloh HyperRam drivers, but I'd imagine you can draw some basic lines and write text with them.
If you wanted to create a machine display, maybe you could create a bmp image that is the background of your menu/display (instead of loading that Lorikeet), and then write text over the image.
Actually- I thought I say someone post a sensor display demo; maybe that was rayman too.
@VonSzarvas Thank you for your comments.
I hope we can progress P2_CharacterMapDemo.spin2 and use HyperRAM and P2 EVAL Rev B to complete the project you started. Is this possible?
Kevin
It's possible, but would rely on significant code development to add the HyperRAM option to that code.
Rogloh (the graphics driver wizard) mentioned in the other thread that swapping PSRAM and HyperRAM is not available yet in his underlying drivers. The 3-part video demos all rely on Rogloh's driver.
Realistically I'd suggest the way to move forward with those QuickByte demos is to use the same hardware listed in the articles.
Roger developed the two DRAM drivers at different times. The HyperRAM was much earlier and included HyperFlash support in the same driver. While the PSRAM version was developed for the later EC32MB plus some other experimental PSRAM add-ons using different combination bus widths. The APIs evolved in different ways at different times.
They can't be that different though. I'm sure he demo'd both using his common graphics driver, albeit at different evolutions of said graphics. Expect them to eventually be drop-in swappable.
This forum tends to let past ideas and work become buried. Yes some people move on and explore new ideas but the future of Parallax Inc needs newcomers that buy Parallax product and utilize that product in even larger projects. Software research should lead Parallax to more sales of Parallax product. This is the reality of a World that faces greater barriers to trade and economic recession.
"P2 Quick Byte" is a great idea which should help increase sales. The link from a "P2 Quick Byte" to forum discussion on that topic / project should be clear to newcomers. Newcomers should be encouraged to show their successes on this forum and / or as a comment to a "P2 Quick Byte".
The link from research to sales is important, but in these times, even more important.
Yes, writing text is much simpler (quicker) to the display, and so doesn't need buffering into the larger memory before being output to the display.
You can do text and simple color (maybe setting the foreground and background color of the text elements), without needing to have the extra ram buffer.
Once you add graphics or overlaying techniques, it takes too long to calculate "on the fly" and you'd need the ram buffer.
I've not seen a scalable font yet, but that would be nice for simple text displays without ram buffer.
You can actually do quite a lot on the fly. See the P2 version of Spin Hexagon. Can run at 1920x1080 displaying simple vector graphics and scaled text from a display list using the VJET library.
Don't actually have a good image of the P2 version, so just look at the video of the P1 version, squint your eyes and imagine it being in Full HD.
Haven't had a chance to respond lately but I'm having a quick look today at whether the PSRAM wrapper driver can be hacked to get some HyperRAM working with VonSzarvas graphics demo in a bare bones RAM only mode at sysclk/2.
Won't promise anything, and it's not necessarily the direction I want this driver to go as it creates yet another variant/file. I have been wanting to go the other way and try to share files more to avoid bloat while still supporting PropTool, seemingly still mutually exclusive.
"First we get the buzzards off her back!" - Mad Max 4
Ok so I got something working with HyperRAM and tried it in my setup. It's still not perfected and is barely tested and there are still some timing issues at 800x600/1024x768 in analog VGA output mode but it displays images with the other 640x480 VGA mode and both DVI modes in the demos. The higher resolutions failing is probably because it is using some PSRAM timing stuff in its burst size calculations and I need to look more into fixing that computeCogBurst function in p2simplevideo.spin2 to work correctly with HyperRAM instead, but that will take a while. Also HyperRAM timing is less forgiving than PSRAM so it can fail at lower P2 clock speeds in comparison. In the meantime it does partially work and can still be used to test things out and mess about with displaying graphics from external RAM.
The extra two driver files required for VonSzarvas demos to work are included in the attached zipfile. Copy them into his demo folders. I've only tried with flexspin just now but I expect the new source will still compile in PropTool with any luck.
To get it working, in p2simplevideo.spin2 you need to adjust the memory driver object to use hyperRAM instead of PSRAM. Eg. setup this:
OBJ
mem : "hyperram"
And in hyperram.spin2 you need to setup the correct base pin for your HyperRAM breakout module by adjusting the DATABUS pin number to be your base pin where you fit the module in the P2-EVAL board. In my case it was at pin 16.
CON
' HyperRAM pin mapping
DATABUS = 16 ' This can be adjusted to customize base pin
CLK_PIN = DATABUS + 8
CS_PIN = DATABUS + 12
RWDS_PIN = DATABUS + 10
RESET_PIN = DATABUS + 15
So I found that the failure of higher analog resolutions with HyperRAM was because the bit depth in these demos is set too high at 32bpp. This puts a large burden on the memory bandwidth. Lower bit depths at these resolutions would likely work fine as is, although these particular VonSzarvas demos are coded to only use truecolor right now I believe. You can adjust the "BPP" value in p2simplevideo.spin2 to 8 and 16 though instead of 32 to see if that helps.
Changing the SVGA timing in p2videodrv.spin2 to the numbers below sort of works in 800x600 as it runs the P2 much faster at 320MHz but could have some write memory contention as there is not a lot of bandwidth left (as I still need to adjust the COG's burst calculations accordingly for HyperRAM in order to guarantee QoS). I do see some glitching when the screen updates so it's probably not handling it perfectly.
Same problem will be happening for 1024x768 but it's even worse there due to the increased resolution. We can't do truecolour with HyperRAM at sysclk/2 on the P2 (at least at 60Hz refresh). It's simply too high and needs 4096 bytes read every 48.4kHz scan line, which is 189MB/s. You'd probably need a 400 MHz P2 for achieving that, once overheads are factored in etc.
svga_timing ' SVGA resolution 800x600 60Hz with 40MHz pixel clock
long 0
long 320_000000
'_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
' 1 bit 7 bits 8 bits 8 bits 8 bits
long (SYNC_POS<<31) | ( 40<<24) | (128<<16) | ( 88<<8 ) | (800/8)
'_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
' 1 bit 8 bits 3 bits 9 bits 11 bits
long (SYNC_POS<<31) | ( 1<<23) | ( 4<<20) | ( 23<<11) | 600
long 8 << 8
long 0
long 0 ' reserved for CFRQ parameter
Update: as a quick improvement you can change PSRAM_XFER_TIME to 8 from 4 in p2simplevideo.spin and it will significantly improve the burst size calculations for HyperRAM transferring byte wide streamer data at sysclk/2. I would still need to determine the equivalent FRAGMENT_OVERHEAD_CLOCKS and REQUEST_OVERHEAD_CLOCKS values for HyperRAM specifically, but the current values are probably somewhat reasonable approximations, at least in the absence of anything else. Computing these values from the code precisely is tedious and requires counting hundreds of instructions and tracing executed paths to figure out the timing. I already did it for lots of PSRAM variants. It wasn't fun.
I think my WVGA 800x480 resolution should already work okay at 270MHz with this Parallax LCD. But your 300MHz timing is also useful for slightly higher memory bandwidth and the line rate and total scan line count is probably closer to standard VGA @evanh.
wvga_dvi_timing ' reduced blanking for 800x480 60Hz LCD at 27MHz pixel clk YMMV
long CLK270MHz
long 270000000
'_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
' 1 bit 7 bits 8 bits 8 bits 8 bits
long (SYNC_POS<<31) | ( 16<<24) | ( 16<<16) | ( 50<<8 ) | (800/8)
'_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
' 1 bit 8 bits 3 bits 9 bits 11 bits
long (SYNC_POS<<31) | ( 7<<23) | ( 3<<20) | ( 20<<11) | 480
long 10 << 8
long 0
long 0 ' reserved for CFRQ parameter
@rogloh Many thanks for the fantastic effort you have made with your driver. To achieve the color and definition in your photos above, I have more to explore!
Kevin
Not sure why your LCD colours look like that, maybe the viewing angle is changing it? I was outputting the DVI on my Dell monitor, not the Parallax LCD, although I've heard from others that my driver does work with the Parallax LCD. Maybe the timing is different in your picture if you've been playing about with it, or there is some LCD product variation or loose wiring. It should be crisp and solid and I see the title centered in the middle of the screen like this...plus the character map text itself is mostly in shades of green not red.
Also, you could try the HyperRAM in a different position, eg. at base pin 16 instead of 32 to see if that changes anything. I was powering directly off my laptop USB port as well instead of an external 2A supply, that's another difference I noticed, in case that affects anything also or there is interference with the LCD power.
EDIT: Ok so you must have set the BPP to 16 when you took that photo. That is why the colours are all messed up. Set it back to 32 and you should get it looking like mine. You only need to reduce the colour depth if you want to run higher resolutions in analog VGA output mode like SVGA and XGA, but the application itself needs to be tailored to that new colour depth and the VonSzarvas demo programs are currently not. That's why it looks bad.
Current settings:
in p2simplevideo.spin2
line 55 mem : "hyperram"
line 105 BPP := 32
in P2_CharacterMapDemo.spin2
line 34 VideoAccessory_BasePin = 8
line39 VideoFormat = video#DVI_800x480
in hyperram.spin2
line 42 DATABUS = 32
No power to AUX USB plug
Tried VideoFormat = video#DVI_800x600 result black display but for me not a problem.
Yeah okay, looks like you got these demos working in the end at the 800x480 native panel resolution. Good one.
800x600 is the wrong resolution for that panel, and requires boosting the P2 clock rate in 32 bits per pixel storage mode used by these demos, or reducing the bits per pixel (BPP) to 8 or 16. Just stick to 800x480 and you'll be fine.
@rogloh Many thanks for your help. Very much appreciated.
Here is detail on the Parallax display:
7" inch INNOLUX AT070TN92 V.X LCD Screen 7DD1+1 FPC 800*480 for Tablet Car DVD lcd hotmcu.com/wiki/HDMI/VGA/AV_RTD2660H_Video_Converter_Board
Within 3 to 5 days I will have a P2 Edge Module with 32MB RAM and a BuyDisplay ER-TFTV070-3-4860-3158-3372-3370-3371 The display is presently on its way to NARITA-SHI JP Japan. Perhaps Fedex has lost its way!
I will experiment with your psram driver in about a week.
Kevin
@rogloh Just looking at:
"In-line PASM code can access the first 16 longs of parameters/results/locals via registers with the same symbolic names."
I believe this is a rule that is not applied in FlexProp but which constrains Propeller Tool.
In your file: p2simplevideo.spin2 in line 630:
PRI {++opt(!regs)} gfxText8(textStr, addr, w, h, stride, srcAddr, srcStride, fontPtr, fg, bg, buf, flags) : len | scanLines, maxBytes, maxChars, lcl_fontWidth, char, glyph, pix, pix1, pix2, srcPtr, destPtr, font, lcl_fontHeight, fontOffset
there are 18 variables that are used in asm blocks.
Variables such as: flags, stride, srcAddr, srcStride, fontPtr use up some of the first 16 longs leaving the usable number as eleven even though they are not within the variables actually used in asm blocks.
Am I understanding this correctly?
Do you have a strategy around this other than shooting the author of:
"In-line PASM code can access the first 16 longs of parameters/results/locals via registers with the same symbolic names."
Kevin.
Are you trying to get these VonSzarvas demos working under PropTool and encountered this limitation? I thought that limit was increased recently but I don't use PropTool myself so I'm possibly wrong there. Or maybe it was increased to 16.
Perhaps there are a few potential ways you could do something to work within the 16 argument limitation, and this is a generalization as I'm not specifically looking at the indicated code to see if these things are indeed fully possible in the case you've mentioned:
refactor the APIs to split total workload over multiple SPIN methods,
share temporary local variables for more than one purpose if they are used a different times
change the API arguments to pass the needed API parameters in a memory block (aka structure) rather than individually and just use a pointer to this HUB RAM block, although you do need to read them from this block at some point into locals, and doing so may obviate the speedup in the PASM blocks you otherwise get from keeping them in a local register, particularly in a repeated loop, at least for FlexSpin.
Actually I think I may have even mentioned the third one too as a future preference when I was writing these APIs and providing them to VonSzarvas for him to bundle together into a demo. We agreed that it was simpler to have all arguments sent individually but I'm not sure if PropTool operation was a priority or not at that time (or even whether that limitation had been seen).
Well I made quite an error. I apologize @rogloh . To correct:
p2videodrv.spin2 written by rogloh
p2simplevideo.spin2 written by VonSzarvas
and p2videodrv.spin2 has an object utilised by p2simplevideo.spin2
The function gfxText8 is part of p2simplevideo.spin2
rogloh prefers FlexProp and @VonSzarvas also prefers FlexProp?
The item above should have been directed to VonSzarvas!
Every file of code on this website should be clearly labeled for a particular IDE.
For any newcomer this must be very confusing!
It is so easy to use the wrong tool for a particular file of code.
Ok I just dug up some PM with VonSzarvas we had while I was providing some code for these demos. Of course I won't post his replies without permission in advance (as that's simply rude) but this was some of my own commentary from back then:
One problem is that PropTool will probably not be able to do this sort of thing. That tool is limited in the number of arguments it can take for the methods as well as the local variable count. It will likely be exceeded. Also its inline assembly code is different to Flexspin's I believe.
and
I think for now these API methods should be capable of pretty much want(what) you need, although they are not the most efficient in terms of number of arguments being copied and passed about, but it's flexible to a user that way and doesn't need all sorts of other structures defined to get something going for a demo etc. Ideally a higher performing API would use pointers to structures for its arguments to these methods, although the SPIN language doesn't really work out so well with named structured data etc. I'd prefer have pointers to 4 long rectangle structures, and window ID base addresses maintained in some display list etc, and more font, colour stuff defined. But that's just too much for now and doing all that needs more soak time in my head too.
@kg1 said:
Well I made quite an error. I apologize @rogloh . To correct:
p2videodrv.spin2 written by rogloh
p2simplevideo.spin2 written by VonSzarvas
and p2videodrv.spin2 has an object utilised by p2simplevideo.spin2
The function gfxText8 is part of p2simplevideo.spin2
rogloh prefers FlexProp and @VonSzarvas also prefers FlexProp?
The item above should have been directed to VonSzarvas!
Every file of code on this website should be clearly labeled for a particular IDE.
For any newcomer this must be very confusing!
It is so easy to use the wrong tool for a particular file of code.
Yes, that's about right. Rogloh wrote the video drivers and I applied a wrapper to demonstrate how to use it, and hopefully simplify the usage- at least for getting started.
The whole code and video-demo was presented using FlexProp for that QuickByte, based on the hardware listed. It was never intended for (or tried with) different hardware or a different IDE. So you've certainly jumped in the hard way by changing both the hardware and compiler
I'm pretty impressed to see it working though, and glad you did that. Bet you learned far more "under the hood" stuff already, by figuring out how to get it working with HyperRAM.
About your point with marking code, I don't disagree. I added the "Flexprop" tag in the source filename hoping that would be enough, and obviously used the FlexProp IDE in the video. In future I will aim to include the compiler details in the source code header comments too. Truth be known, I hadn't really properly understood the differences between the two IDEs before this project, and just wrote the code to work with FlexProp at the time, as Rogloh had used the same for his drivers. Moving forward I'll be trying to stick with PropTool for anything that's published to QuickBytes page so that we (hopefully) keep things more compatible. I wouldn't say I have a preference for one over the other though- I'd rather say that I like to use the tool that works for each job, and in this case it was FlexProp.
kg1
Posts: 164
Comments
@VonSzarvas @evanh @Rayman
Connected HyperRAM to P2 EVAL Rev B
HyperHDMI_16bpp_4g.spin2 moves Lorikeet.bmp from SD card to HyperRAM to Display
https://parallax.com/product/7-hdmi-display-800-x-480/
Where to now? See FlexProp PST Terminal.
That's good- proves your monitor and hardware is working ok.
You ask... Where to now?
What are you wanting to do next? Write text over the image?
I'm not familiar with the rayman and rogloh HyperRam drivers, but I'd imagine you can draw some basic lines and write text with them.
If you wanted to create a machine display, maybe you could create a bmp image that is the background of your menu/display (instead of loading that Lorikeet), and then write text over the image.
Actually- I thought I say someone post a sensor display demo; maybe that was rayman too.
Found these...
EVAL + HyperRam:
https://forums.parallax.com/discussion/172518/wvga-hdmi-8bpp-graphics-driver-works-with-the-parallax-7-hdmi-lcd-in-spin2#latest
This demo mentions HyperRAM compatibility, and appears to include text and drawn elements:
https://www.parallax.com/dvi-vga-text-driver-demo/
@VonSzarvas Thank you for your comments.
I hope we can progress P2_CharacterMapDemo.spin2 and use HyperRAM and P2 EVAL Rev B to complete the project you started. Is this possible?
Kevin
It's possible, but would rely on significant code development to add the HyperRAM option to that code.
Rogloh (the graphics driver wizard) mentioned in the other thread that swapping PSRAM and HyperRAM is not available yet in his underlying drivers. The 3-part video demos all rely on Rogloh's driver.
Realistically I'd suggest the way to move forward with those QuickByte demos is to use the same hardware listed in the articles.
Oh, now I understand. I gather there is some posted easy to follow demos somewhere that use the EC32MB with HDMI displays.
Yep. QuickByte Articles: https://www.parallax.com/search-articles/?swpengine=articles&swpquery=Using+Video
Roger developed the two DRAM drivers at different times. The HyperRAM was much earlier and included HyperFlash support in the same driver. While the PSRAM version was developed for the later EC32MB plus some other experimental PSRAM add-ons using different combination bus widths. The APIs evolved in different ways at different times.
They can't be that different though. I'm sure he demo'd both using his common graphics driver, albeit at different evolutions of said graphics. Expect them to eventually be drop-in swappable.
This forum tends to let past ideas and work become buried. Yes some people move on and explore new ideas but the future of Parallax Inc needs newcomers that buy Parallax product and utilize that product in even larger projects. Software research should lead Parallax to more sales of Parallax product. This is the reality of a World that faces greater barriers to trade and economic recession.
"P2 Quick Byte" is a great idea which should help increase sales. The link from a "P2 Quick Byte" to forum discussion on that topic / project should be clear to newcomers. Newcomers should be encouraged to show their successes on this forum and / or as a comment to a "P2 Quick Byte".
The link from research to sales is important, but in these times, even more important.
@VonSzarvas @evanh @rogloh
No HyperRAM used in P2 EVAL Rev B
https://parallax.com/product/7-hdmi-display-800-x-480/
Yes, writing text is much simpler (quicker) to the display, and so doesn't need buffering into the larger memory before being output to the display.
You can do text and simple color (maybe setting the foreground and background color of the text elements), without needing to have the extra ram buffer.
Once you add graphics or overlaying techniques, it takes too long to calculate "on the fly" and you'd need the ram buffer.
I've not seen a scalable font yet, but that would be nice for simple text displays without ram buffer.
You can actually do quite a lot on the fly. See the P2 version of Spin Hexagon. Can run at 1920x1080 displaying simple vector graphics and scaled text from a display list using the VJET library.
Don't actually have a good image of the P2 version, so just look at the video of the P1 version, squint your eyes and imagine it being in Full HD.
Haven't had a chance to respond lately but I'm having a quick look today at whether the PSRAM wrapper driver can be hacked to get some HyperRAM working with VonSzarvas graphics demo in a bare bones RAM only mode at sysclk/2.
Won't promise anything, and it's not necessarily the direction I want this driver to go as it creates yet another variant/file. I have been wanting to go the other way and try to share files more to avoid bloat while still supporting PropTool, seemingly still mutually exclusive.
"First we get the buzzards off her back!" - Mad Max 4
Ok so I got something working with HyperRAM and tried it in my setup. It's still not perfected and is barely tested and there are still some timing issues at 800x600/1024x768 in analog VGA output mode but it displays images with the other 640x480 VGA mode and both DVI modes in the demos. The higher resolutions failing is probably because it is using some PSRAM timing stuff in its burst size calculations and I need to look more into fixing that computeCogBurst function in p2simplevideo.spin2 to work correctly with HyperRAM instead, but that will take a while. Also HyperRAM timing is less forgiving than PSRAM so it can fail at lower P2 clock speeds in comparison. In the meantime it does partially work and can still be used to test things out and mess about with displaying graphics from external RAM.
The extra two driver files required for VonSzarvas demos to work are included in the attached zipfile. Copy them into his demo folders. I've only tried with flexspin just now but I expect the new source will still compile in PropTool with any luck.
To get it working, in p2simplevideo.spin2 you need to adjust the memory driver object to use hyperRAM instead of PSRAM. Eg. setup this:
OBJ mem : "hyperram"And in hyperram.spin2 you need to setup the correct base pin for your HyperRAM breakout module by adjusting the DATABUS pin number to be your base pin where you fit the module in the P2-EVAL board. In my case it was at pin 16.
CON ' HyperRAM pin mapping DATABUS = 16 ' This can be adjusted to customize base pin CLK_PIN = DATABUS + 8 CS_PIN = DATABUS + 12 RWDS_PIN = DATABUS + 10 RESET_PIN = DATABUS + 15Good luck.
So I found that the failure of higher analog resolutions with HyperRAM was because the bit depth in these demos is set too high at 32bpp. This puts a large burden on the memory bandwidth. Lower bit depths at these resolutions would likely work fine as is, although these particular VonSzarvas demos are coded to only use truecolor right now I believe. You can adjust the "BPP" value in p2simplevideo.spin2 to 8 and 16 though instead of 32 to see if that helps.
Changing the SVGA timing in p2videodrv.spin2 to the numbers below sort of works in 800x600 as it runs the P2 much faster at 320MHz but could have some write memory contention as there is not a lot of bandwidth left (as I still need to adjust the COG's burst calculations accordingly for HyperRAM in order to guarantee QoS). I do see some glitching when the screen updates so it's probably not handling it perfectly.
Same problem will be happening for 1024x768 but it's even worse there due to the increased resolution. We can't do truecolour with HyperRAM at sysclk/2 on the P2 (at least at 60Hz refresh). It's simply too high and needs 4096 bytes read every 48.4kHz scan line, which is 189MB/s. You'd probably need a 400 MHz P2 for achieving that, once overheads are factored in etc.
svga_timing ' SVGA resolution 800x600 60Hz with 40MHz pixel clock long 0 long 320_000000 '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns ' 1 bit 7 bits 8 bits 8 bits 8 bits long (SYNC_POS<<31) | ( 40<<24) | (128<<16) | ( 88<<8 ) | (800/8) '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible ' 1 bit 8 bits 3 bits 9 bits 11 bits long (SYNC_POS<<31) | ( 1<<23) | ( 4<<20) | ( 23<<11) | 600 long 8 << 8 long 0 long 0 ' reserved for CFRQ parameterUpdate: as a quick improvement you can change PSRAM_XFER_TIME to 8 from 4 in p2simplevideo.spin and it will significantly improve the burst size calculations for HyperRAM transferring byte wide streamer data at sysclk/2. I would still need to determine the equivalent FRAGMENT_OVERHEAD_CLOCKS and REQUEST_OVERHEAD_CLOCKS values for HyperRAM specifically, but the current values are probably somewhat reasonable approximations, at least in the absence of anything else. Computing these values from the code precisely is tedious and requires counting hundreds of instructions and tracing executed paths to figure out the timing. I already did it for lots of PSRAM variants. It wasn't fun.
The LCD in the QuickBytes examples is 800x480 at sysclock/10 (HDMI). That'll likely improve the bandwidth.
Here's my auto-generated timings for Roger's driver:
I made an auto-mode builder a while back, still not completely happy with it. but this is what generated the above timings:
PUB computeCustomDvi(timing, p2freq, hres, vres, vfreq) : r | divisor, vblank, hblank, hfp, hbp {{ So there is a total of four effective parameters to build complete HDMI timings from: 1 - sysclock frequency (p2freq) 2 - horzontal resolution (hres) 3 - vertical resolution (vres) 4 - vertical frequency (vfrq) Remaining timings are: (currently out of date, since there is now a bias toward a vblanking of 45) dotfrq (>= 25 MHz) = p2freq / 10 htot = hres + 80 hfp = 8 hsw = 64 hbp = 8 vtot = dotfrq / (htot * vfrq) vblank = vtot - vres vsw = 2 vfp = (vblank - vsw) / 2 vbp = vblank - vsw - vfp negative hsync and vsync both }} p2freq #>= 250_000_000 'minimum DVI link speed divisor := 10 'fixed ratio dot-clock, DVI hardware is locked to 10:1 vfreq #>= 10 'sane minimum hres &= $7f8 '8-bit range (x8) vres &= $7ff '11-bit range vblank := vres / 10 'kick-off with desired mid-range vblank vblank := 45 r := divisor * vfreq * (vres + vblank) 'htot = dotfreq / (vtot * vfreq) hblank := (p2freq + r/2) / r - hres 'hblank = htot - hres ' hblank := ((hblank + 4) & $fff8) #> 80 'bound to min 80 hblank, multiples of eight hblank := hblank #> 80 r := divisor * vfreq * (hres + hblank) 'vtot = dotfreq / (htot * vfreq) vblank := (p2freq + r/2) / r - vres 'vblank = vtot - vres vblank := 20 #> vblank <# 960 'bound blanking, possibly break vfreq ' hfp := ((hblank - 64) >> 1) & $7ff8 'multiples of eight hfp := (hblank - 64) >> 1 hbp := hblank - 64 - hfp long[timing][2] := hres >> 3 long[timing][2] |= (hfp & $7f) << 24 'hfp (bit31 high for positive sync) long[timing][2] |= (64 & $ff) << 16 'hs long[timing][2] |= (hbp & $ff) << 8 'hbp long[timing][5] := ((hfp << 1) & $ff00) 'hfp ' long[timing][5] |= ((64 >> 4) & $f0) 'hs long[timing][5] |= ((hbp >> 8) & $f) 'hbp r := ((vblank - 2) >> 1) <# $ff long[timing][3] := vres long[timing][3] |= r << 23 'vfp (bit31 high for positive sync) long[timing][3] |= 2 << 20 'vs r := (vblank - 2 - r) <# $1ff long[timing][3] |= r << 11 'vbp long[timing][0] := 0 'use auto-compute of clock mode long[timing][1] := p2freq ' long[timing][4] := (divisor +< 256) ? (divisor << 8) : divisor long[timing][4] := $0CCC_CCCC+1 'DVI TMDS encoding hardware is wired for 10:1 only long[timing][6] := 0 'Calculate final vertical scan frequency (in tenths of hertz) ' vblank := long[timing][3].[30..23] + 2 + long[timing][3].[19..11] ' r := (hres + 80) * (vres + vblank) 'htot * vtot ' r := (p2freq + r/2) / r 'vfreq = dotfreq / (htot * vtot) return timingI think my WVGA 800x480 resolution should already work okay at 270MHz with this Parallax LCD. But your 300MHz timing is also useful for slightly higher memory bandwidth and the line rate and total scan line count is probably closer to standard VGA @evanh.
wvga_dvi_timing ' reduced blanking for 800x480 60Hz LCD at 27MHz pixel clk YMMV long CLK270MHz long 270000000 '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns ' 1 bit 7 bits 8 bits 8 bits 8 bits long (SYNC_POS<<31) | ( 16<<24) | ( 16<<16) | ( 50<<8 ) | (800/8) '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible ' 1 bit 8 bits 3 bits 9 bits 11 bits long (SYNC_POS<<31) | ( 7<<23) | ( 3<<20) | ( 20<<11) | 480 long 10 << 8 long 0 long 0 ' reserved for CFRQ parameter@VonSzarvas @evanh @rogloh
Connected HyperRAM to P2 EVAL Rev B
Using different hardware from that of: https://parallax.com/video-hardware-character-map/
Display: https://www.parallax.com/product/7-hdmi-display-800-x-480/
Board: https://parallax.com/product/propeller-2-evaluation-board-rev-c/
HyperRam: https://parallax.com/product/p2-es-eval-board-hyperram-hyperflash-add-on/
Still requires further tuning.
@rogloh Many thanks for the fantastic effort you have made with your driver. To achieve the color and definition in your photos above, I have more to explore!
Kevin
Not sure why your LCD colours look like that, maybe the viewing angle is changing it? I was outputting the DVI on my Dell monitor, not the Parallax LCD, although I've heard from others that my driver does work with the Parallax LCD. Maybe the timing is different in your picture if you've been playing about with it, or there is some LCD product variation or loose wiring. It should be crisp and solid and I see the title centered in the middle of the screen like this...plus the character map text itself is mostly in shades of green not red.
Also, you could try the HyperRAM in a different position, eg. at base pin 16 instead of 32 to see if that changes anything. I was powering directly off my laptop USB port as well instead of an external 2A supply, that's another difference I noticed, in case that affects anything also or there is interference with the LCD power.
EDIT: Ok so you must have set the BPP to 16 when you took that photo. That is why the colours are all messed up. Set it back to 32 and you should get it looking like mine. You only need to reduce the colour depth if you want to run higher resolutions in analog VGA output mode like SVGA and XGA, but the application itself needs to be tailored to that new colour depth and the VonSzarvas demo programs are currently not. That's why it looks bad.
@VonSzarvas @evanh @rogloh
Connected HyperRAM to P2 EVAL Rev B
Using different hardware from that of: https://parallax.com/video-hardware-character-map/
Display: https://www.parallax.com/product/7-hdmi-display-800-x-480/
Board: https://parallax.com/product/propeller-2-evaluation-board-rev-c/
HyperRam: https://parallax.com/product/p2-es-eval-board-hyperram-hyperflash-add-on/
Current settings:
in p2simplevideo.spin2
line 55 mem : "hyperram"
line 105 BPP := 32
in P2_CharacterMapDemo.spin2
line 34 VideoAccessory_BasePin = 8
line39 VideoFormat = video#DVI_800x480
in hyperram.spin2
line 42 DATABUS = 32
No power to AUX USB plug
Tried VideoFormat = video#DVI_800x600 result black display but for me not a problem.
Yeah okay, looks like you got these demos working in the end at the 800x480 native panel resolution. Good one.
800x600 is the wrong resolution for that panel, and requires boosting the P2 clock rate in 32 bits per pixel storage mode used by these demos, or reducing the bits per pixel (BPP) to 8 or 16. Just stick to 800x480 and you'll be fine.
@rogloh Many thanks for your help. Very much appreciated.
Here is detail on the Parallax display:
7" inch INNOLUX AT070TN92 V.X LCD Screen 7DD1+1 FPC 800*480 for Tablet Car DVD lcd
hotmcu.com/wiki/HDMI/VGA/AV_RTD2660H_Video_Converter_Board
Within 3 to 5 days I will have a P2 Edge Module with 32MB RAM and a BuyDisplay ER-TFTV070-3-4860-3158-3372-3370-3371 The display is presently on its way to NARITA-SHI JP Japan. Perhaps Fedex has lost its way!
I will experiment with your psram driver in about a week.
Kevin
@rogloh Just looking at:
"In-line PASM code can access the first 16 longs of parameters/results/locals via registers with the same symbolic names."
I believe this is a rule that is not applied in FlexProp but which constrains Propeller Tool.
In your file: p2simplevideo.spin2 in line 630:
PRI {++opt(!regs)} gfxText8(textStr, addr, w, h, stride, srcAddr, srcStride, fontPtr, fg, bg, buf, flags) : len | scanLines, maxBytes, maxChars, lcl_fontWidth, char, glyph, pix, pix1, pix2, srcPtr, destPtr, font, lcl_fontHeight, fontOffset
there are 18 variables that are used in asm blocks.
Variables such as: flags, stride, srcAddr, srcStride, fontPtr use up some of the first 16 longs leaving the usable number as eleven even though they are not within the variables actually used in asm blocks.
Am I understanding this correctly?
Do you have a strategy around this other than shooting the author of:
"In-line PASM code can access the first 16 longs of parameters/results/locals via registers with the same symbolic names."
Kevin.
Are you trying to get these VonSzarvas demos working under PropTool and encountered this limitation? I thought that limit was increased recently but I don't use PropTool myself so I'm possibly wrong there. Or maybe it was increased to 16.
Perhaps there are a few potential ways you could do something to work within the 16 argument limitation, and this is a generalization as I'm not specifically looking at the indicated code to see if these things are indeed fully possible in the case you've mentioned:
Actually I think I may have even mentioned the third one too as a future preference when I was writing these APIs and providing them to VonSzarvas for him to bundle together into a demo. We agreed that it was simpler to have all arguments sent individually but I'm not sure if PropTool operation was a priority or not at that time (or even whether that limitation had been seen).
Well I made quite an error. I apologize @rogloh . To correct:
p2videodrv.spin2 written by rogloh
p2simplevideo.spin2 written by VonSzarvas
and p2videodrv.spin2 has an object utilised by p2simplevideo.spin2
The function gfxText8 is part of p2simplevideo.spin2
rogloh prefers FlexProp and @VonSzarvas also prefers FlexProp?
The item above should have been directed to VonSzarvas!
Every file of code on this website should be clearly labeled for a particular IDE.
For any newcomer this must be very confusing!
It is so easy to use the wrong tool for a particular file of code.
Ok I just dug up some PM with VonSzarvas we had while I was providing some code for these demos. Of course I won't post his replies without permission in advance (as that's simply rude) but this was some of my own commentary from back then:
and
Yes, that's about right. Rogloh wrote the video drivers and I applied a wrapper to demonstrate how to use it, and hopefully simplify the usage- at least for getting started.
The whole code and video-demo was presented using FlexProp for that QuickByte, based on the hardware listed. It was never intended for (or tried with) different hardware or a different IDE. So you've certainly jumped in the hard way by changing both the hardware and compiler
I'm pretty impressed to see it working though, and glad you did that. Bet you learned far more "under the hood" stuff already, by figuring out how to get it working with HyperRAM.
About your point with marking code, I don't disagree. I added the "Flexprop" tag in the source filename hoping that would be enough, and obviously used the FlexProp IDE in the video. In future I will aim to include the compiler details in the source code header comments too. Truth be known, I hadn't really properly understood the differences between the two IDEs before this project, and just wrote the code to work with FlexProp at the time, as Rogloh had used the same for his drivers. Moving forward I'll be trying to stick with PropTool for anything that's published to QuickBytes page so that we (hopefully) keep things more compatible. I wouldn't say I have a preference for one over the other though- I'd rather say that I like to use the tool that works for each job, and in this case it was FlexProp.