With PhiPi's information linked in the previous post I was able to build some tools to let me convert the original P1 font down to 8x16 size, with all the characters included. Then some of the symbols were hand tweaked after that to try to best represent the original P1 in the smaller character size. It's not going to be identical to the original of course, but it's close and looks very nice and clean on a high resolution LCD screen. Here's a photo of it (1:1 pixel accurate) on my Dell Ultrasharp (set to 1600x1200). I will include this font in the release of this video driver.
Yeah Wuerfel_21 it does look offset a bit. Most regular chars are 6 pixels wide, though I have widened a few others like M,m,W,w,Y,X etc to rebalance. I'll play more there. By the way I do find the box drawing symbols in the first 16 characters a bit confusing. I think some of them were special for P1 with 2bpp HW (I can't really recall making good use of those) but it now may not make as much sense for normal two colour stuff on the P2. So I may make a secondary font set which repurposes these for double thick box outlines which might be useful for push buttons. There are 8 symbols there that possibly could be reused for that. The dot and rounded square could be turned into two radio button/check box states. This could be helpful for hires text UIs. There are already other arrow characters that could be useful for control of scroll bars etc.
I'm also going to mull over the dual HyperRAM module thing a bit more. My HyperRAM driver was designed for multi-COGs, multi-banks, and multi-modules, and in my video driver software I do already have some infrastructure for interlaced source where it selects from different source locations in each field, though that is currently automatic while for HyperRAM we may also want manual control as to when the switching occurs. The dual HyperRAM thing also needs two different mailboxes. I do currently have two mailbox registers, and one is just a fixed offset from the other to accelerate the computation of my split up mailbox writes. If I can rework the code a bit I might be able to have a region control bit select between the two somehow. This would let us flip between two different mailboxes per display frame or even nominate them dynamically per region. It's probably asking to crash when abused but if done carefully it might let us have very high performances writes on one HyperRAM bus, while the video COG displays out of the second HyperRAM bus at the same time.
I have 2 instructions free for this. If I can make it fit it would be the icing on the cake.
Relatedly: Have you seen my ROM font compatible 8x8 font?
No not sure I have, does it look nice and easy to read? Is there a link to see a picture of it or other screenshot?
The smaller fonts are very handy in lower resolutions to increase the number of rows. At high resolutions they can start to become microscopic however. I know a while back I tried a 6 scan line font which looks ridiculously tiny but gets a crazy amount of text on screen (up to 240x200 on the 1920x1200 monitor). I had posted an image of that on my original PASM2 gurus driver thread here:
An 8x8 font there instead would be a lot easier to read and much easier to rotate for portrait mode use too. The possible 150x240 or 135x240 (@1080p) is convenient for file editing.
Thanks for posting, that looks rather good Wuerfel_21 and the drawing symbols are there. The various European lower case "a" symbols do get squished down but it's probably unavoidable.
So for enabling multiple HyperRAM buses in my video driver, overnight I was able to come up with an idea that might work...
I already keep all my HyperRAM mailboxes in contiguous order over different driver instances. Each spawned HyperRAM driver gets its own instance of 8x3 longs for the mailboxes (3 longs per COG). Then the next instance follows on from the prior one. This is key.
I already have two mailbox address registers in my code. One points to the first mailbox long for the video driver COG to use, the other to the second mailbox long for the COG. These two addresses get used to burst write two request parameters and then to trigger the HyperRAM read request command and to read back the result if waiting for completion (the wait only actually happens when drawing a mouse, just so we don't start to render it before the scan line data has been returned).
My screen buffer parameter data in each region is currently maintained in this format:
'..............................................................................
'
' SCREEN_BUFFER_1 - defines the text or graphics mode screen's start address
' ===============
'
' bit bit
' 31 30-28 27 24 23 0
' -----------------------------------------------------------
' | E |Rsvd| Bank | Screen Buffer Base Address |
' -----------------------------------------------------------
'
' External Memory (E)
' -------------------
' When in graphics mode, the buffer base address can be used for external
' memory such as HyperRAM.
'
' The E flag's value should be set to 0 for HUB RAM, 1 for external RAM.
'
' Bank
' ----
' Selects the bank for external memory accesses, ignored for hub access.
' Addresses will wrap within the same 16MB external memory bank.
'
' Screen Buffer Base Address
' --------------------------
' The Hub or External memory address to begin reading from at the start
' of the region being displayed.
I think I can modify it so the E+Rsvd bits above get instead re-claimed as a nibble to identify the instance of the HyperRAM driver. A zero nibble would get used to indicate internal memory accesses instead of external memory accesses so the driver instances would be based at 1 not 0 from the video client's perspective.
The current code to do external memory setup stuff for graphics regions is this:
gen_gfx
mov save, ptrb 'preserve for fifo use later
mov d, ptra 'preserve initial source pointer
extm_test testb screenaddr1, #31 wz 'check for external memory usage
testb modedata, #13 wc 'check transparent/sprite mode and
if_c_and_nz mov save, ptra '...display from ptra if no ext mem
if_z getnib a, screenaddr1, #6 'extract bank address
if_z setnib ptra, a, #6 'copy into external request
if_z setnib ptra, #EXTMEMREQ, #7 'add memory read request to address
p6 if_z mov a, #COLS 'transfer column "units" of memory data
if_z shl a, bppidx '...multiplied by bpp into HUB RAM
if_z setq #2-1 'write 2 values
if_z wrlong save, mailbox2 'setup memory request information
if_z wrlong ptra, mailbox1 'initiate memory read request
if_z add ptra, linebufsize 'increase ptra by this amount
bitz mouseptr, #23 'remember for late mouse render
if_c_or_z jmp #copy_done 'no need to do any copy this time
If I can find a free temporary working register (my "xx" below) I think I can do this instead, by eliminating the old mailbox1 COG register (now leaving 3 COG RAM locations free for the new instructions) and only maintaining my mailbox2 as the parameter base address of the first real instance for this driver COG id - 96 (which I will still compute at COG init time). This allows the top nibble of each screen buffer parameter to index into the different HyperRAM drivers for this COG id which is ideal because it all remains together so changing it is atomic. Plus I was already using Z flag to differentiate internal/external access so I can still get that with the MUL instruction saving a further instruction which would not have fit otherwise. I think this might just work.
gen_gfx
mov save, ptrb 'preserve for fifo use later
mov d, ptra 'preserve initial source pointer
getnib xx, screenaddr1, #7 'get ext-mem driver instance (0=hub only)
extm_test mul xx, #96 wz 'scale by mailbox bytes per driver
add xx, mailbox2 'compute mailbox2 address
testb modedata, #13 wc 'check transparent/sprite mode and
if_c_and_z mov save, ptra '...display from ptra if no ext mem
if_nz getnib a, screenaddr1, #6 'extract bank address
if_nz setnib ptra, a, #6 'copy into external request
if_nz setnib ptra, #EXTMEMREQ, #7 'add memory read request to address
p6 if_nz mov a, #COLS 'transfer column "units" of memory data
if_nz shl a, bppidx '...multiplied by bpp into HUB RAM
if_nz setq #2-1 'write 2 values
if_nz wrlong save, xx 'setup memory request information
if_nz sub xx, #4
if_nz wrlong ptra, xx 'initiate memory read request
if_nz add ptra, linebufsize 'increase ptra by this amount
bitnz mouseptr, #23 'remember for late mouse render
if_c_or_nz jmp #copy_done 'no need to do any copy this time
The other real bonus with the approach above is that I think it should remain fully compatible with my driver's region interlaced mode where each field displays graphical source data from a different buffer for that region, so you could have the flip done automatically for you if you choose that approach. This would be perfect for video applications where other COGs work to fill a frame buffer in one HyperRAM for one field, while the video COG displays from another different HyperRAM at the same time, and the video HW output will flip to use the other HyperRAM device automatically on the next field without intervention. My Screen_buffer_3 and Screen_buffer_4 parameters are used for this.
It doesn't have to actually be interlaced source material either. The auto-flipping will work for non-interlaced source material when you enable a region's interlaced mode. It will still just happen at the field rate (or entire frame in non-interlaced terminology).
Multiple HyperRAM driver access from the video driver is now all coded and builds with zero longs left in the COG. I've just run it and now see the top nibble of the screen buffer parameter is controlling sourcing pixels from hub vs external memory, just as I wanted. When set to 0 it displays from hub, when it's 1 data is coming from first HyperRAM bus, when greater than 1 the region is trying to use the corresponding HyperRAM driver(s) bus but because those board(s) do not exist in my system it is just alternating the two prior scan lines left in the line buffer since it won't get a mailbox response (as expected). I also can see my automatic interlaced source mode working with this feature too.
To see it properly switching video from different HyperRAM boards in all its glory I would need a second HyperRAM board to test for real. Unfortunately we are still in lockdown for probably at least another month here so I can't even travel more than the 5km needed to visit the local Melbourne guys to test it with one of their own boards without the risk of an $1652 on the spot fine! To ship one any faster from Parallax would cost me $282 so that's not happening either.
I'm actually pretty happy about getting this final capability into my video driver. It's now going to allow us some serious P2 video write performance with two or more HyperRAM memories on different buses for those that really need the most performance. With this firmware you could even have up to 5 buses with all the P2 pins and different COGs working on different buses with no contention. Might make a good video pipeline if you can carve up the workload appropriately.
Yeah I may need to do that, msrobots. But I will first need to resolve some weird problem I noticed tonight with HyperRAM addressing that now seems to be truncating my read scan line data somehow - it's most likely a regression as I have not seen this one before when I last tested HyperRAM hires graphics, so my chosen temp register may not be good to use or something new is going on. Then once that is restored I'll try to build up a demo binary that draws into one RAM while outputting from another and compare that against single RAM performance. It should be a useful test to exercise the feature.
Update: Thankfully a false alarm on the bug, it was just an invalid line buffer size passed into my driver from the test program.
So once I finally understood how these box drawing characters were meant to be used on the P1 (I'd forgotten it), I was able to get my 8x16 Propeller font tweaked a bit to support them. It looks okay and will be useful for text based UIs. The characters should be capable of basically doing the same things as available on the P1 (minus those 3d bevel effects with 2bpp output of course).
The characters to use to form a box/button shape are these:
0 12 8
10 11
1 12 9
The bottom character 12 can also be 13 instead to create an underscore below the character above it in the box as shown in the attached picture. This is useful for accelerator keys or perhaps to highlight focus etc. A mouse will be able to move over this and click it. The "mouse click down" state could be an inverse font or different text colour inside perhaps.
Just trying to get a handle (with: p2videodrv0_91b) on regions... Looks like you can specify the height of a region in pixels, but can you specify the region horizontally? I would like to build regions around user interface items that may be left-aligned somewhere other than pixel 0 on any line.
Yes Cluso is correct @dgately. The way it works is that you can only reload a different region mode one line a time, one scan line before the line starts - there is no way to have two regions side by side, only above/below each other.
Have you been able to get 800x480 working with some timing tweaks?
The newer code I am putting together fixes some of the text printing API issues which was incomplete/buggy in the beta version. In the meantime if you manage your own screen buffer contents it won't be an issue.
Have you been able to get 800x480 working with some timing tweaks?
640x480 is working well!
What areas of code would I need to mod, for HDMI for 800x400?
I see this:
' obtain the VGA's timing for a given resolution
'timing := vid.getTiming(VID#RES_1024x768)
'timing := vid.getTiming(VID#RES_800x600)
timing := vid.getTiming(VID#RES_640x480)
Also, I do notice that when I've tried to use either SmartSerial or JonnyMac's latest FullDuplexSerial to send text back to the terminal, that I'm not able to get good results. There's some kind of memory issue, I think... I get a few correct characters back, but then garbage. If I place the printStr(), out(), Tx(), Dec(), Hex(), etc... type statements before InitDisplay, they "kind of" work, but placing any terminal related output after that definitely results in 3-5 character of good text, then garbage. I've attached the demoHDMI.spin2 code. It's set to use FullDuplexSerial, but can be converted to use SmartSerial with a few mods.
Application "Wish" to activate'; exit 0
( Entering terminal mode. Press Ctrl-] to exit. )
Start????????????????x??x???|>??????x???9???9x?|?n??????9x?|?n??????9x?|?n?
Ok @dgately the terminal problems are baud rate mismatches because the P2 PLL clock frequency changes when the video is initialised and this affects the bit timing. You need to either start the serial object after you init video or restart the serial again at the same baud rate once the video is initialized (that works for me).
To get video tweaked, I would create a copy of the longs originally defined here for 800x600 with reduced blanking over DVI and experiment with that by playing with the sync values. As I don't have one of these LCD's I don't know what the best values are unfortunately, it would need some experimentation unless a proper data sheet is found.
svga_dvi_timing ' massively reduced blanking for 800x600 50Hz at 25.2MHz clk YMMV
long CLK252MHz
long 252000000
'_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
' 1 bit 7 bits 8 bits 8 bits 8 bits
long (SYNC_POS<<31) | ( 8<<24) | ( 8<<16) | ( 8<<8 ) | (800/8)
'_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
' 1 bit 8 bits 3 bits 9 bits 11 bits
long (SYNC_POS<<31) | ( 2<<23) | ( 2<<20) | ( 11<<11) | 600
long 10 << 8
long 0
long 0 ' reserved for CFRQ parameter
For the 800x480 LCD
refresh rate = pixel frequency / (total horizontal pixels * total vertical lines)
total horizontal pixels = horizontal front porch + horizontal sync + horizontal back porch + 800
total vertical lines = vertical front porch lines + vertical sync lines + vertical back porch lines + 480
The pixel frequency below is set to 25.2MHz (P2 clock=252MHz).
Ideally you want to keep the LCD refresh at or close to 60Hz. There are possibly other minimum values for syncs and blanking portions for this panel but I don't know them. My numbers below are just a starting point to play with but I have made the total width 824 pixels which is 800 active pixels + 24 pixels of horizontal blanking (8+8+8), and 510 lines which is 480 active lines + (5+3+22) of vertical blanking lines.
25.2Mpixels/s / (824 pixels x 510 lines) ~ 60Hz.
So you would just include this data timing format in the DAT section in your top application object and try to tweak the numbers of blanking pixels and blanking lines in the two longs below until it works (keeping the 800 active pixels and 480 lines constant while doing this):
DAT
custom_lcd_timing
long CLK252MHz
long 252000000
long (1<<31) | (8 << 24) | (8 << 16) | (8 << 8) | (800/8) ' example starting point only
long (1<<31) | (5 << 23) | (3 << 20) | (22 << 11) | 480 ' example starting point only
long 10 << 8
long 0
long 0
And also need to modify your initialisation code to now use the custom timing data instead of standard VGA 640x480 mode by changing this code:
' obtain the VGA's timing for a given resolution
timing := vid.getTiming(VID#RES_640x480)
The timing numbers above are actually pretty aggressive in terms of reduced horizontal blanking, which puts more load on the driver and could ultimately overload it once they are too low. It limits other things like drawing borders and mice and may cause timing failures if they are enabled. So in general it's nicer to reduce the vertical lines down more and give as much horizontal blanking time to the driver for its own per scan line overheads. You have 510 lines to play with which is a lot. My driver doesn't do very much during these blanking lines.
if this is the same type of panel and so does apply to your LCD module, then the timing numbers above may not work.
According to the data sheet you'd probably want to use a higher clock like the 270MHz one I defined in order to meet the 26.4Mpixel minimum. You could try this one... 882 total pixels, 510 total lines, ~60Hz refresh.
DAT
custom_lcd_timing
long CLK270MHz
long 270000000
long (1<<31) | (16 << 24) | (16 << 16) | (50 << 8) | (800/8) ' example starting point only
long (1<<31) | (7 << 23) | (3 << 20) | (20 << 11) | 480 ' example starting point only
long 10 << 8
long 0
long 0
EDIT: there were some incorrect values in the longs above that would have not worked, and also in the prior post! Fixed.
PS: What will happen with DIVP of /2 is the VCO taps out at about 400 MHz so then sysclock is around 200 MHz. I say around because the PLL can't get a lock to the crystal. And without the PLL locked, sysclock frequency then becomes die temperature dependent. As it warms up the VCO frequency will go lower, well below 400 MHz.
Sorry about the 270MHz, I forgot that wasn't already defined in the code you have and had left it to you to work out.
If that timing doesn't work for you another one to try might be this, which gives exactly 60Hz refresh with a faster 31.5MHz pixel clock (note that the P2 is running quite overclocked at 315MHz). Total pixels = 1000, total lines = 525. This gives lots of time in the horizontal blanking for mice/borders etc.
DAT
custom_lcd_timing
long CLK315MHz
long 315000000
long (1<<31) | (16 << 24) | (96 << 16) | (88 << 8) | (800/8) ' example starting point only
long (1<<31) | (33 << 23) | (2 << 20) | (10 << 11) | 480 ' example starting point only
long 10 << 8
long 0
long 0
Chip seemed to use the P2 @ 330MHz in his 800x480 HDMI demo in the PNut demo files. Whether or not that timing worked on your LCD panel (or some other monitor) I'm not sure, I've don't think I've seen that indicated 100% definitively from anyone. 330MHz would be too high for HyperRAM sysclk/1 operation though you could go down to half that.
@dgately In my newer version about to be released I am having success with better printing and you can use SEND redirection with ersmith's formatting and it works nicely in PNut and FastSpin now. Much easier than just writing single chars and calling printStr etc. Of course you can still manage the screen buffer independently with your own hub writes etc, but it's nice to have the screen region scroll for you and just use simple code like this:
OBJ
f : "ers_fmt" ' format utility from Eric Smith
vid : "p2videodrv"
PUB demo() : i, j
send := @vid.tx
send("Hello", f.nl())
repeat i from 0 to 10
j:= i*i
send(f.dec(i), 9, f.dec(j), f.nl())
I'm probably going to remove the inbuilt hex/dec printing stuff in the newer video driver API given this formatting capability exists now. No need to have a myriad of different driver versions of formatting APIs. If a common way is standardized it would be easier to port code to different output devices. SEND redirection is a good way to do this.
Comments
I'm also going to mull over the dual HyperRAM module thing a bit more. My HyperRAM driver was designed for multi-COGs, multi-banks, and multi-modules, and in my video driver software I do already have some infrastructure for interlaced source where it selects from different source locations in each field, though that is currently automatic while for HyperRAM we may also want manual control as to when the switching occurs. The dual HyperRAM thing also needs two different mailboxes. I do currently have two mailbox registers, and one is just a fixed offset from the other to accelerate the computation of my split up mailbox writes. If I can rework the code a bit I might be able to have a region control bit select between the two somehow. This would let us flip between two different mailboxes per display frame or even nominate them dynamically per region. It's probably asking to crash when abused but if done carefully it might let us have very high performances writes on one HyperRAM bus, while the video COG displays out of the second HyperRAM bus at the same time.
I have 2 instructions free for this. If I can make it fit it would be the icing on the cake.
The smaller fonts are very handy in lower resolutions to increase the number of rows. At high resolutions they can start to become microscopic however. I know a while back I tried a 6 scan line font which looks ridiculously tiny but gets a crazy amount of text on screen (up to 240x200 on the 1920x1200 monitor). I had posted an image of that on my original PASM2 gurus driver thread here:
https://forums.parallax.com/discussion/comment/1485247/#Comment_1485247
An 8x8 font there instead would be a lot easier to read and much easier to rotate for portrait mode use too. The possible 150x240 or 135x240 (@1080p) is convenient for file editing.
It's basically (f)unscii with approximations of the Parallax ROM characters added by me.
If you mess with the source, you can compile multiple styles, sizes and character sets
So for enabling multiple HyperRAM buses in my video driver, overnight I was able to come up with an idea that might work...
I already keep all my HyperRAM mailboxes in contiguous order over different driver instances. Each spawned HyperRAM driver gets its own instance of 8x3 longs for the mailboxes (3 longs per COG). Then the next instance follows on from the prior one. This is key.
I already have two mailbox address registers in my code. One points to the first mailbox long for the video driver COG to use, the other to the second mailbox long for the COG. These two addresses get used to burst write two request parameters and then to trigger the HyperRAM read request command and to read back the result if waiting for completion (the wait only actually happens when drawing a mouse, just so we don't start to render it before the scan line data has been returned).
My screen buffer parameter data in each region is currently maintained in this format:
I think I can modify it so the E+Rsvd bits above get instead re-claimed as a nibble to identify the instance of the HyperRAM driver. A zero nibble would get used to indicate internal memory accesses instead of external memory accesses so the driver instances would be based at 1 not 0 from the video client's perspective.
The current code to do external memory setup stuff for graphics regions is this:
gen_gfx mov save, ptrb 'preserve for fifo use later mov d, ptra 'preserve initial source pointer extm_test testb screenaddr1, #31 wz 'check for external memory usage testb modedata, #13 wc 'check transparent/sprite mode and if_c_and_nz mov save, ptra '...display from ptra if no ext mem if_z getnib a, screenaddr1, #6 'extract bank address if_z setnib ptra, a, #6 'copy into external request if_z setnib ptra, #EXTMEMREQ, #7 'add memory read request to address p6 if_z mov a, #COLS 'transfer column "units" of memory data if_z shl a, bppidx '...multiplied by bpp into HUB RAM if_z setq #2-1 'write 2 values if_z wrlong save, mailbox2 'setup memory request information if_z wrlong ptra, mailbox1 'initiate memory read request if_z add ptra, linebufsize 'increase ptra by this amount bitz mouseptr, #23 'remember for late mouse render if_c_or_z jmp #copy_done 'no need to do any copy this timeIf I can find a free temporary working register (my "xx" below) I think I can do this instead, by eliminating the old mailbox1 COG register (now leaving 3 COG RAM locations free for the new instructions) and only maintaining my mailbox2 as the parameter base address of the first real instance for this driver COG id - 96 (which I will still compute at COG init time). This allows the top nibble of each screen buffer parameter to index into the different HyperRAM drivers for this COG id which is ideal because it all remains together so changing it is atomic. Plus I was already using Z flag to differentiate internal/external access so I can still get that with the MUL instruction saving a further instruction which would not have fit otherwise. I think this might just work.
gen_gfx mov save, ptrb 'preserve for fifo use later mov d, ptra 'preserve initial source pointer getnib xx, screenaddr1, #7 'get ext-mem driver instance (0=hub only) extm_test mul xx, #96 wz 'scale by mailbox bytes per driver add xx, mailbox2 'compute mailbox2 address testb modedata, #13 wc 'check transparent/sprite mode and if_c_and_z mov save, ptra '...display from ptra if no ext mem if_nz getnib a, screenaddr1, #6 'extract bank address if_nz setnib ptra, a, #6 'copy into external request if_nz setnib ptra, #EXTMEMREQ, #7 'add memory read request to address p6 if_nz mov a, #COLS 'transfer column "units" of memory data if_nz shl a, bppidx '...multiplied by bpp into HUB RAM if_nz setq #2-1 'write 2 values if_nz wrlong save, xx 'setup memory request information if_nz sub xx, #4 if_nz wrlong ptra, xx 'initiate memory read request if_nz add ptra, linebufsize 'increase ptra by this amount bitnz mouseptr, #23 'remember for late mouse render if_c_or_nz jmp #copy_done 'no need to do any copy this timeIt doesn't have to actually be interlaced source material either. The auto-flipping will work for non-interlaced source material when you enable a region's interlaced mode. It will still just happen at the field rate (or entire frame in non-interlaced terminology).
To see it properly switching video from different HyperRAM boards in all its glory I would need a second HyperRAM board to test for real. Unfortunately we are still in lockdown for probably at least another month here so I can't even travel more than the 5km needed to visit the local Melbourne guys to test it with one of their own boards without the risk of an $1652 on the spot fine! To ship one any faster from Parallax would cost me $282 so that's not happening either.
I'm actually pretty happy about getting this final capability into my video driver. It's now going to allow us some serious P2 video write performance with two or more HyperRAM memories on different buses for those that really need the most performance. With this firmware you could even have up to 5 buses with all the P2 pins and different COGs working on different buses with no contention. Might make a good video pipeline if you can carve up the workload appropriately.
Can you give me some Code and simple instructions to test it for you?
Mike
Update: Thankfully a false alarm on the bug, it was just an invalid line buffer size passed into my driver from the test program.
The characters to use to form a box/button shape are these:
The bottom character 12 can also be 13 instead to create an underscore below the character above it in the box as shown in the attached picture. This is useful for accelerator keys or perhaps to highlight focus etc. A mouse will be able to move over this and click it. The "mouse click down" state could be an inverse font or different text colour inside perhaps.
Just trying to get a handle (with: p2videodrv0_91b) on regions... Looks like you can specify the height of a region in pixels, but can you specify the region horizontally? I would like to build regions around user interface items that may be left-aligned somewhere other than pixel 0 on any line.
dgately
Have you been able to get 800x480 working with some timing tweaks?
The newer code I am putting together fixes some of the text printing API issues which was incomplete/buggy in the beta version. In the meantime if you manage your own screen buffer contents it won't be an issue.
What areas of code would I need to mod, for HDMI for 800x400?
I see this:
Also, I do notice that when I've tried to use either SmartSerial or JonnyMac's latest FullDuplexSerial to send text back to the terminal, that I'm not able to get good results. There's some kind of memory issue, I think... I get a few correct characters back, but then garbage. If I place the printStr(), out(), Tx(), Dec(), Hex(), etc... type statements before InitDisplay, they "kind of" work, but placing any terminal related output after that definitely results in 3-5 character of good text, then garbage. I've attached the demoHDMI.spin2 code. It's set to use FullDuplexSerial, but can be converted to use SmartSerial with a few mods.
To get video tweaked, I would create a copy of the longs originally defined here for 800x600 with reduced blanking over DVI and experiment with that by playing with the sync values. As I don't have one of these LCD's I don't know what the best values are unfortunately, it would need some experimentation unless a proper data sheet is found.
svga_dvi_timing ' massively reduced blanking for 800x600 50Hz at 25.2MHz clk YMMV long CLK252MHz long 252000000 '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns ' 1 bit 7 bits 8 bits 8 bits 8 bits long (SYNC_POS<<31) | ( 8<<24) | ( 8<<16) | ( 8<<8 ) | (800/8) '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible ' 1 bit 8 bits 3 bits 9 bits 11 bits long (SYNC_POS<<31) | ( 2<<23) | ( 2<<20) | ( 11<<11) | 600 long 10 << 8 long 0 long 0 ' reserved for CFRQ parameterFor the 800x480 LCD
refresh rate = pixel frequency / (total horizontal pixels * total vertical lines)
total horizontal pixels = horizontal front porch + horizontal sync + horizontal back porch + 800
total vertical lines = vertical front porch lines + vertical sync lines + vertical back porch lines + 480
The pixel frequency below is set to 25.2MHz (P2 clock=252MHz).
Ideally you want to keep the LCD refresh at or close to 60Hz. There are possibly other minimum values for syncs and blanking portions for this panel but I don't know them. My numbers below are just a starting point to play with but I have made the total width 824 pixels which is 800 active pixels + 24 pixels of horizontal blanking (8+8+8), and 510 lines which is 480 active lines + (5+3+22) of vertical blanking lines.
25.2Mpixels/s / (824 pixels x 510 lines) ~ 60Hz.
So you would just include this data timing format in the DAT section in your top application object and try to tweak the numbers of blanking pixels and blanking lines in the two longs below until it works (keeping the 800 active pixels and 480 lines constant while doing this):
And also need to modify your initialisation code to now use the custom timing data instead of standard VGA 640x480 mode by changing this code: to this :
if this is the same type of panel and so does apply to your LCD module, then the timing numbers above may not work.
According to the data sheet you'd probably want to use a higher clock like the 270MHz one I defined in order to meet the 26.4Mpixel minimum. You could try this one... 882 total pixels, 510 total lines, ~60Hz refresh.
EDIT: there were some incorrect values in the longs above that would have not worked, and also in the prior post! Fixed.
I'll give this some time in the next or two. I'll report my results.
dgately
I'm a bit lost on creating the 270 MHz... Gave it a try, though!
Not getting video with the attached version of the demo (for 800x480)
A bit over my head...
PS: What will happen with DIVP of /2 is the VCO taps out at about 400 MHz so then sysclock is around 200 MHz. I say around because the PLL can't get a lock to the crystal. And without the PLL locked, sysclock frequency then becomes die temperature dependent. As it warms up the VCO frequency will go lower, well below 400 MHz.
If that timing doesn't work for you another one to try might be this, which gives exactly 60Hz refresh with a faster 31.5MHz pixel clock (note that the P2 is running quite overclocked at 315MHz). Total pixels = 1000, total lines = 525. This gives lots of time in the horizontal blanking for mice/borders etc.
Chip seemed to use the P2 @ 330MHz in his 800x480 HDMI demo in the PNut demo files. Whether or not that timing worked on your LCD panel (or some other monitor) I'm not sure, I've don't think I've seen that indicated 100% definitively from anyone. 330MHz would be too high for HyperRAM sysclk/1 operation though you could go down to half that.
That was, of course, correct!
Working 800x480 sample code attached...
dgately
OBJ f : "ers_fmt" ' format utility from Eric Smith vid : "p2videodrv" PUB demo() : i, j send := @vid.tx send("Hello", f.nl()) repeat i from 0 to 10 j:= i*i send(f.dec(i), 9, f.dec(j), f.nl())I'm probably going to remove the inbuilt hex/dec printing stuff in the newer video driver API given this formatting capability exists now. No need to have a myriad of different driver versions of formatting APIs. If a common way is standardized it would be easier to port code to different output devices. SEND redirection is a good way to do this.