According to the AT070TN92 spec, HBlanking (HSync + HBackPorch) = 46 always, therefore
custom_lcd_timing
'800 x 480, option 1
long CLK270MHz
long 270000000
long (1<<31) | (36 << 24) | (16 << 16) | (30 << 8) | (800/8) ' 882 pixels
long (1<<31) | (7 << 23) | (3 << 20) | (20 << 11) | 480 ' 510 lines
long 10 << 8
long 0
long 0
or
custom_lcd_timing
'800 x 480, option 2
long CLK270MHz
long 270000000
long (1<<31) | (16 << 24) | (16 << 16) | (30 << 8) | (800/8) ' 862 pixels
long (1<<31) | (19 << 23) | (3 << 20) | (20 << 11) | 480 ' 522 lines
long 10 << 8
long 0
long 0
Option 2 tests minimum pixels/line and is slightly closer to 60.0Hz, but Option 1 might be preferable as 20 extra pixels/line means a little more time to do things.
EDIT:
After testing, these two options do not work with the Parallax 7" HDMI display.
Yeah TonyB_ option 1 is nicer on the driver, but interestingly the original values of horizontal sync width and back porch that don't add up to 46 pixels still did work for dgately so perhaps that data sheet is not 100% applicable to that panel, not really sure there.
Fiddling about with my Dell monitor over DVI, I can also get it to sync at 800x480 settings that dgately used.
I can also hit 800x600 over DVI at ~50Hz with the P2 @252MHz using this:
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
Also I then pushed it up to ~60Hz refresh with this (824 x 623) @ 308MHz:
svga_dvi_timing ' massively reduced blanking for 800x600 60Hz at 30.8MHz clk YMMV
long CLK308MHz
long 308000000
'_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) | ( 4<<23) | ( 2<<20) | ( 17<<11) | 600
long 10 << 8
long 0
long 0 ' reserved for CFRQ parameter
Not sure how many DVI monitors will like that fairly extreme reduced blanking but it worked for me. Of course it can be tweaked further and/or use other P2 clock rates to gain more horizontal blanking which is nicer for the driver if you wanted a mouse sprite or borders to operate in its spare cycles. But at least 800x600 is possible at 60Hz over DVI which is quite handy.
Update : 1024x600 output at ~50Hz is also achievable at 320MHz over DVI with my driver. This is another common panel size. 320MHz is probably just asking too much from the overclocked HyperRAM though. Of course for lower panel refresh we can go higher resolutions, I know Chip was able to get HD (1280x720) going at low refresh too. The good thing is this is all programmable and easy to play around with to see what works and what doesn't.
Ok, stick with what worked dgately. I tried your working timing on my Dell monitor with my latest driver and found it still is able to get a mouse sprite rendered too over coloured text and still runs the demanding 8 bit LUT mode. Even with up to 48 pixel border width at the sides all modes seemed to work and allow the mouse to be rendered. At some point it should fail if the border gets too big but I didn't push it. I also didn't try multiple regions with text and the mouse enabled, I suspect that might also eventually hit a wall.
The really good thing with DVI modes is that it always gives you a 10x P2 clock, so there are typically plenty of cycles to go around.
Sorry, could not get TonyB_'s or rogloh's latest to work on the 7 inch LCD...
Thanks for trying my two options. I've edited my post to say they don't work with the Parallax 7" display, which obviously doesn't agree totally with the AT070TN92 spec posted earlier.
I'm very impressed that rogloh's 270MHz suggested values (reproduced below) worked first time!
DAT
custom_lcd_timing
long CLK270MHz
long 270000000
long (1<<31) | (16 << 24) | (16 << 16) | (50 << 8) | (800/8) ' 882 pixels
long (1<<31) | (7 << 23) | (3 << 20) | (20 << 11) | 480 '510 lines
long 10 << 8
long 0
long 0
In the code for the next release I've added a couple of enhancements to the custom timing setups which I was testing out today.
The sixth long in the timing structure above (ie. the first "long 0" shown) was redefined to allow for its 16 LSBs to extend the range of all the horizontal timing settings. They increase the range up to 12 bits for horizontal sync and back porch, and up to 15 bits for horizontal front porch (way more than needed for each, but easier to simply work with nibble sized arguments instead of splitting into less bits). This was in response to finding out that the 1600x1200 mode needed a wider back porch than what the prior 8 bits supported. The 720p modes needs a very wide front porch although this was already supported before.
The full expanded definition of this long is now this:
' '_Breezeway__C-Burst__FrontPorchHi__SyncWidthHi__BackPorchHi
' ' 8 bits 8 bits 8 bits 4 bits 4 bits
' long 0 ' Optional timing extension/mode dependent parameters.
' ' Bits 15:0 extend the horizontal timing range further.
' ' This increased range enables support for wider front
' ' porches used in 720p50 modes etc.
' ' bits 3:0 become bits 11-8 of horizontal back porch
' ' bits 7:4 become bits 11-8 of horizontal sync width
' ' bits 15:8 become bits 14-7 of horizontal front porch
' ' Additionally, for PAL/NTSC composite/S-video output:
' ' bits 23:16 hold colour burst size (pixels)
' ' bits 31:24 hold colour burst breezeway size (pixels)
I also made it so that if the clock mode timing parameter (CLK270MHz above) is set to 0, the video driver can automatically determine the PLL settings for the requested frequency using the second long that follows it - and in addition, if that second long is also zero, then this means the application is responsible for configuring the PLL not the driver. This should allow plenty of flexibility as to who sets up the PLL and when. It also lets you set finer clocks, I think to 500kHz granularity right now. The following are the current defaults used in the PLL calculations but these can also be tweaked if required. My code will try to find an exact match, and if none are found then it will pick the closest found to meet the tolerance parameter.
' parameters used when automatically determining PLL settings
TOLERANCE_HZ = 500000 ' pixel clock accuracy will be constrained by this when no exact ratios are found
MAXVCO_HZ = 350000000 ' for safety, but you could try to overclock even higher at your own risk
MINVCO_HZ = 100000000
MINPLLIN_HZ = 500000 ' setting lower can find more PLL ratios but may begin to introduce more PLL jitter
Thought I'd post a crazy little drawing demo of 640x480x8bpp graphics I was testing out while doing some USB mouse+keyboard integration with my graphics driver. I have another one that works with 1080p 8bpp with HyperRAM, that is coming soon, but this demo works with just HUB RAM only.
Uses @garryj USB driver (the original one that is hardcoded to pins & freq, I still need to get the new one integrated and tested).
Fit the VGA breakout board on P0-7. Demo uses VGA port.
Fit the USB breakout board on P48-P55 - this demo needs a USB mouse, the USB keyboard is optional, can fit these in either USB port.
Runs at 252MHz (to allow DVI testing) but in VGA mode this application could probably run as low as 50MHz (just needs at least 2x pixel clock for mono text) or whatever the USB driver allows.
Responds to left, middle and right button click hold and drag. L+R click clears display.
Keyboard also responds to space, "," and "." for size adjustments and can be held down while moving.
Try drawing some coil spring shapes or your name and have some fun.
@"Ken Gracey" and others:
I have created a new text driver API layer that simplifies the setup my video VGA/DVI/TV driver when all you want is a just a single 16 colour text screen to be output over VGA or DVI at a given resolution. This should now be very easy to use and also works with PropTool.
Four SPIN2 demos using this are included in the attached zip file along with an updated P2 video driver. You can adjust the CON block constants as required to suit your particular HDMI or A/V breakout board pin configuration. The demos are:
helloworld.spin2 - very simple hello world example showing easy setup of the text driver with VGA output
helloworld_dvi.spin2 - same as helloworld.spin2 demo but with DVI output instead of VGA
textdemo.spin2 - a demonstration to show the text driver's features (VGA & DVI selectable)
widefont.spin2 - an example of using a 16 pixel wide font (outputs VGA)
In DVI mode the P2 video driver is able to output up to 800x600 at 50Hz, as well as 800x480 and 640x480 with the default timings for those. It should work with the Parallax WVGA LCD panel over HDMI with the provided timing (based on some previous results from @dgately) but I have not got one of those LCD panels to test it out for myself. The driver API does also support creating your own custom video timings which is functional now but these demos are not yet making use of that particular feature. You can always try that out to see what is possible.
Note that by default the text driver is setup to store text at up to 1920x1200 resolution with a 6 scan line font (240 columns x 200 rows!), because that can potentially be setup as part of the provided demos when experimenting with them and I didn't want it to run out of memory if people tried that so I just maxxed it out. In practice this can and should be reduced down more realistic size to save on screen buffer memory in a real application that does not require that high an overall screen resolution.
Just adjust MAXPIXELS, MAXLINES and MINFONTHEIGHT to suit your own requirements if you intend to use this p2 text driver more efficiently in your own applications.
The P2 text driver API is very solid at this stage for displaying text from a P2, but I am still experimenting a little and testing it and optimizing its performance and I may add a couple more features in time. This is not final released software but considered part of a beta release 0.92b. I'll try to keep the API names stable but can't guarantee there won't be any more changes there. Work on further demos for the new external memory framebuffer capabilities this updated video driver now supports with the HyperRAM/HyperFlash external memory breakout board needs to happen along with the proper documentation and more code tidyup.
I've tested this out with PropTool and these demos work with that toolchain now. They also each successfully compiled and loaded using an older version of fastspin 4.3.1 that I had lying about. I haven't downloaded and tried it on the latest version of flexprop yet but intend to try that out soon and can further update the demos if required but hopefully it should just work (TM). Perhaps someone can try it out for me with flexprop. EDIT: just tried it and it worked with FlexProp version 5.0.8 on my Mac.
Some features of this driver:
easily setup to output via VGA/DVI at different resolutions
automatic HW cursor control (hidden/block/underline/flashing/solid/colour) and positioning
window scrolling, clearing to end of line, or screen
an independent foreground and background colour per character
driver can process CR/LF/BS/TAB/FF and scrolls screen automatically
optional flashing text attribute, double high, double wide pixels are options
configurable fonts and height, 8 pixels wide, or 16 pixel wide with a 128 character set
can be readily coupled to SEND()
the P2 PLL and clock speed is automatically setup for you, no extra config is required
To begin to use this driver to output VGA in 800x600 resolution, for example, its now as simple as this (I don't think I could make it very much simpler to use):
CON
BASE_PIN = 0 ' set to the base VGA pin group (HSYNC pin number)
VSYNC_PIN = BASE_PIN + 4 ' VSYNC pin number for A/V board wiring
OBJ
vid: "p2textdrv"
PUB start()
vid.initVga(-1, BASE_PIN, VSYNC_PIN, 0, vid.SVGA) ' choose VGA, SVGA, XGA, etc
send := @vid.tx
send("Hello World")
Yeah there are other nice things that can be done with VGA's VSYNC that already are part of the underlying video driver. It can do SoG and RGBS as well (so you can have either 3,4,5 pin VGA). For now this text driver just uses regular RBGHV for simplicity (I'm trying not to confuse people yet with a zillion options right now).
The video driver is also able to output text via component in both SDTV and HDTV formats as well as s-video and composite in PAL and NTSC. I just haven't exposed the init APIs for those yet in the text driver wrapper...but I likely will in time (it's only a few other init APIs to include).
I'm looking at the output at the moment, it looks correct eg color sequence of text is
Black - Blue - Green -- Cyan - Red - Magenta - Brown - White (then same pattern for higher intensity)
@Cluso99 said:
I’m not at my computer atm, but isn’t it BGRHV pin sequence as P2 standard?
In the P2 HW the first pin the group is always the HSync, followed by the 3 colour pins, and VSync can be any pin. From a software perspective the colours are all treated the same and can be remapped in the palette if ever required.
So for the A/V breakout it actually maps like this:
@Cluso99 said:
I’m not at my computer atm, but isn’t it BGRHV pin sequence as P2 standard?
In the P2 HW the first pin the group is always the HSync, followed by the 3 colour pins, and VSync can be any pin. From a software perspective the colours are all treated the same and can be remapped in the palette if ever required.
So for the A/V breakout it actually maps like this:
IOBase HSYNC
IOBase+1 BLUE
IOBase+2 GREEN
IOBase+3 RED
IOBase+4 VSYNC
Yes forgot H was the other end. I recalled RGB was reversed to my expectation. Of course the colors can be changed but its better to keep it the right way around if possible, or at least consistent.
The CSC could also swizzle the colors if necessary - that'd also work for truecolor modes.
Also, @rogloh , I think there's some errors in that timing selection logic you got there, In particular, this section
if flags & INTERLACED <> 0
syncFlags |= %0_0_010000
if flags & PAL <> 0
syncFlags |= %0_0_001000
timing := @int576_timing
else
timing := @int480_timing
else ' progressive
if output == COMPONENT_SDTV
if flags & PAL <> 0
syncFlags |= %0_0_001000
timing := @prog576_timing
else
timing := @prog480_timing
else ' CVBS/S-video
if flags & PAL <> 0
syncFlags |= %0_0_001000
timing := @prog288_timing
else
timing := @prog240_timing
non-interlaced COMPONENT_SDTV should be 240p/288p, not 480p/576p. Those are called EDTV and should be their own thing. (There's lots of SDTV-only component inputs on US sets)
PAL does not mean 50Hz, that should be separate flags. PAL60 is generally more useful than normal PAL. Also weird variants like PAL-M are a thing.
These can of course be worked around with a custom timing, but having the defaults be useful and consistent would help with making video output runtime-configurable (or well, load-time configurable) (which seems fairly necessary with the variety of supported video modes and types)
You could well be right Wuerfel_21. The various SDTV and EDTV modes are possibly some of the least well tested parts of the driver at this stage. That is why I haven't linked them into the higher lever text driver wrapper, though they are still possible to enable in the lower driver with the appropriate settings. It will be helpful to have people try it out and help me find the problems....
Another issue is that overscan can cause loss of text at the sides in some modes (you lose some active pixels). An outer black border can be setup in the driver to help alleviate this so the text starts further inside the visible part of the screen, but you can sometimes end up with less than your 80 columns that way.
I think I am also missing the 50Hz timing for the FULL HD 1080i signaling. It still needs to be added in. It is just 60Hz right now.
@rogloh said:
Another issue is that overscan can cause loss of text at the sides in some modes (you lose some active pixels). An outer black border can be setup in the driver to help alleviate this so the text starts further inside the visible part of the screen, but you can sometimes end up with less than your 80 columns that way.
Overscan is just how TVs roll. If you actually want 320/640 fully visible pixels the pixel clock has to be higher (see any retro computer designed for TV output). That gives you non-square pixels and isn't great for graphics (just better when the screen is filled))
When my VGA to USB video capture device arrives this week I'll be able to post proper video and screen captures; the static pictures don't do this justice. I'm looking forward to getting this part resolved.
@rogoloh, tag me for future releases and I'll update the Quick Byte.
When my VGA to USB video capture device arrives this week I'll be able to post proper video and screen captures; the static pictures don't do this justice. I'm looking forward to getting this part resolved.
@rogoloh, tag me for future releases and I'll update the Quick Byte.
Ken Gracey
That's great you got it working Ken and managed to put this out so quickly. I'll be keeping the thread alive and update it more with further releases and try to let you know when they happen.
@dgately said:
Yes, the driver works with the Parallax WVGA LCD panel over HDMI...
dgately
>
Really good to hear. You were able to helpfully also test out those timings in a previous effort so I was confident it should still work, but without that panel myself I didn't know for sure.
By the way, Tubular just let me know that DVI output did actually work for him with resolutions configured above 800x600@50Hz on some of his displays. Right now he's building up a nice table of results. All that happens is the refresh rate drops. At first I couldn't figure out why this worked with my code because it should require P2 clocks at 10x the pixel rate which exceed the P2 maximum frequency, but what is happening internally is the resolution selected is still assuming a P2 clock for VGA pixel generation at these resolutions and it then simply divides that number by 10 in my PASM driver whenever DVI is chosen. This overrides the normal pixel clock divider setting in the timing structure and as a side effect of the 10x divider it lets the coloured text work too. Double bonus!
Outputting higher resolutions at lower frame rates is still useful and it opens up a lot of possibilities, the issue is probably how many displays can support the low refresh (you can't be sure one will until you try it - though with HDMI inputs these days if you use an HDTV display I'd say you can't be sure of very much beyond accepting the standard TV timings).
I know other people in the past including Chip have had success in running their HDMI displays less than 50Hz so we can possibly add more modes like 720p24 etc directly into the driver for people who have displays that can use that. This can already be tested out by setting up fully custom timings, but having a single "vid.HD" type of constant to pass in to get 720p output makes it easier. I'll look into that. There are actually an enormous number of other resolutions that this driver can generate, they are just too numerous to test and include as "standards" right now. I've just selected a fairly common subset of PC type resolutions to build in, but there are heaps more and you can invent your own. This site is always a good resource for video timings: http://tinyvga.com/vga-timing
Yes confirming this low-refresh DVI works great with Philips Brilliance 288P6, nice and sharp. Whopping 240 characters across by 75 lines, using 8x16 font. Who even guessed this was possible with the P2? Did someone declare it impossible already?
It also works great with a JVL 32" TV, which was super cheap. Less sharp. No luck with other monitors at low refresh, yet, just these two.
The full color of the characters is a super good bonus, too. Very impressive work, Rogloh
I'm hearing some high pitched buzz on the audio output of the Edge audio/video card when using the latest version of this driver.
Am I the only one?
RJ
Maybe it's cross talk on the A/V board or power supply noise if video and audio are being output together? The RCA outputs on that breakout board are shared with the VGA pins and can therefore be driven by this driver so if you are using those connectors for your audio that would explain it. If not and you are using the 3.5mm output instead does the noise depend on the resolution selected? Some of the video modes crank the P2 up to a very high frequency which will draw a lot more current. Also the driver will modify the PLL so if any audio application you also run in parallel with the video needed a particular P2 clock frequency to work right, the fact that the video driver goes and changes the P2 clock frequency might also somehow impact the sound quality there. The PLL clock setting is a global thing so video and audio will need to co-operate together.
I'll go connect the audio out to an amp on my own A/V board shortly to see if I hear anything too.
Update: I'm not hearing noise from the 3.5mm jack when I tried it myself and cranked up the amp volume. Maybe you have a short on your board linking some of the pins together, or it's something else? Be sure the audio plug is all the way in and you've not got DVI configured to output to that group of pins - it needs to go to another group of 8 pins.
I'll go connect the audio out to an amp on my own A/V board shortly to see if I hear anything too.
I'm using the 3.5mm output to the monitor. My monitor is an ACER 19" with VGA/Audio
Getting a high pitch with both demos.
Update: I'm not hearing noise from the 3.5mm jack when I tried it myself and cranked up the amp volume. Maybe you have a short on your board linking some of the pins together, or it's something else? Be sure the audio plug is all the way in and you've not got DVI configured to output to that group of pins - it needs to go to another group of 8 pins.
Comments
or Option 2 tests minimum pixels/line and is slightly closer to 60.0Hz, but Option 1 might be preferable as 20 extra pixels/line means a little more time to do things.
EDIT:
After testing, these two options do not work with the Parallax 7" HDMI display.
Fiddling about with my Dell monitor over DVI, I can also get it to sync at 800x480 settings that dgately used.
I can also hit 800x600 over DVI at ~50Hz with the P2 @252MHz using this:
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 parameterAlso I then pushed it up to ~60Hz refresh with this (824 x 623) @ 308MHz:
svga_dvi_timing ' massively reduced blanking for 800x600 60Hz at 30.8MHz clk YMMV long CLK308MHz long 308000000 '_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) | ( 4<<23) | ( 2<<20) | ( 17<<11) | 600 long 10 << 8 long 0 long 0 ' reserved for CFRQ parameterNot sure how many DVI monitors will like that fairly extreme reduced blanking but it worked for me. Of course it can be tweaked further and/or use other P2 clock rates to gain more horizontal blanking which is nicer for the driver if you wanted a mouse sprite or borders to operate in its spare cycles. But at least 800x600 is possible at 60Hz over DVI which is quite handy.
Update : 1024x600 output at ~50Hz is also achievable at 320MHz over DVI with my driver. This is another common panel size. 320MHz is probably just asking too much from the overclocked HyperRAM though. Of course for lower panel refresh we can go higher resolutions, I know Chip was able to get HD (1280x720) going at low refresh too. The good thing is this is all programmable and easy to play around with to see what works and what doesn't.
The really good thing with DVI modes is that it always gives you a 10x P2 clock, so there are typically plenty of cycles to go around.
Thanks for trying my two options. I've edited my post to say they don't work with the Parallax 7" display, which obviously doesn't agree totally with the AT070TN92 spec posted earlier.
I'm very impressed that rogloh's 270MHz suggested values (reproduced below) worked first time!
The sixth long in the timing structure above (ie. the first "long 0" shown) was redefined to allow for its 16 LSBs to extend the range of all the horizontal timing settings. They increase the range up to 12 bits for horizontal sync and back porch, and up to 15 bits for horizontal front porch (way more than needed for each, but easier to simply work with nibble sized arguments instead of splitting into less bits). This was in response to finding out that the 1600x1200 mode needed a wider back porch than what the prior 8 bits supported. The 720p modes needs a very wide front porch although this was already supported before.
The full expanded definition of this long is now this:
I also made it so that if the clock mode timing parameter (CLK270MHz above) is set to 0, the video driver can automatically determine the PLL settings for the requested frequency using the second long that follows it - and in addition, if that second long is also zero, then this means the application is responsible for configuring the PLL not the driver. This should allow plenty of flexibility as to who sets up the PLL and when. It also lets you set finer clocks, I think to 500kHz granularity right now. The following are the current defaults used in the PLL calculations but these can also be tweaked if required. My code will try to find an exact match, and if none are found then it will pick the closest found to meet the tolerance parameter.
' parameters used when automatically determining PLL settings TOLERANCE_HZ = 500000 ' pixel clock accuracy will be constrained by this when no exact ratios are found MAXVCO_HZ = 350000000 ' for safety, but you could try to overclock even higher at your own risk MINVCO_HZ = 100000000 MINPLLIN_HZ = 500000 ' setting lower can find more PLL ratios but may begin to introduce more PLL jitterUses @garryj USB driver (the original one that is hardcoded to pins & freq, I still need to get the new one integrated and tested).
Fit the VGA breakout board on P0-7. Demo uses VGA port.
Fit the USB breakout board on P48-P55 - this demo needs a USB mouse, the USB keyboard is optional, can fit these in either USB port.
Runs at 252MHz (to allow DVI testing) but in VGA mode this application could probably run as low as 50MHz (just needs at least 2x pixel clock for mono text) or whatever the USB driver allows.
Responds to left, middle and right button click hold and drag. L+R click clears display.
Keyboard also responds to space, "," and "." for size adjustments and can be held down while moving.
Try drawing some coil spring shapes or your name and have some fun.
Binary in zip file.
Cheers!
@"Ken Gracey" and others:
I have created a new text driver API layer that simplifies the setup my video VGA/DVI/TV driver when all you want is a just a single 16 colour text screen to be output over VGA or DVI at a given resolution. This should now be very easy to use and also works with PropTool.
Four SPIN2 demos using this are included in the attached zip file along with an updated P2 video driver. You can adjust the CON block constants as required to suit your particular HDMI or A/V breakout board pin configuration. The demos are:
In DVI mode the P2 video driver is able to output up to 800x600 at 50Hz, as well as 800x480 and 640x480 with the default timings for those. It should work with the Parallax WVGA LCD panel over HDMI with the provided timing (based on some previous results from @dgately) but I have not got one of those LCD panels to test it out for myself. The driver API does also support creating your own custom video timings which is functional now but these demos are not yet making use of that particular feature. You can always try that out to see what is possible.
Note that by default the text driver is setup to store text at up to 1920x1200 resolution with a 6 scan line font (240 columns x 200 rows!), because that can potentially be setup as part of the provided demos when experimenting with them and I didn't want it to run out of memory if people tried that so I just maxxed it out. In practice this can and should be reduced down more realistic size to save on screen buffer memory in a real application that does not require that high an overall screen resolution.
Just adjust MAXPIXELS, MAXLINES and MINFONTHEIGHT to suit your own requirements if you intend to use this p2 text driver more efficiently in your own applications.
The P2 text driver API is very solid at this stage for displaying text from a P2, but I am still experimenting a little and testing it and optimizing its performance and I may add a couple more features in time. This is not final released software but considered part of a beta release 0.92b. I'll try to keep the API names stable but can't guarantee there won't be any more changes there. Work on further demos for the new external memory framebuffer capabilities this updated video driver now supports with the HyperRAM/HyperFlash external memory breakout board needs to happen along with the proper documentation and more code tidyup.
I've tested this out with PropTool and these demos work with that toolchain now. They also each successfully compiled and loaded using an older version of fastspin 4.3.1 that I had lying about. I haven't downloaded and tried it on the latest version of flexprop yet but intend to try that out soon and can further update the demos if required but hopefully it should just work (TM). Perhaps someone can try it out for me with flexprop. EDIT: just tried it and it worked with FlexProp version 5.0.8 on my Mac.
Some features of this driver:
To begin to use this driver to output VGA in 800x600 resolution, for example, its now as simple as this (I don't think I could make it very much simpler to use):
CON BASE_PIN = 0 ' set to the base VGA pin group (HSYNC pin number) VSYNC_PIN = BASE_PIN + 4 ' VSYNC pin number for A/V board wiring OBJ vid: "p2textdrv" PUB start() vid.initVga(-1, BASE_PIN, VSYNC_PIN, 0, vid.SVGA) ' choose VGA, SVGA, XGA, etc send := @vid.tx send("Hello World")Enjoy!
Roger.
Looks really good (again!), Roger. I'll check it out in a moment. I see what the capture devices think of it too
Excellent work Roger!
Had a quick look at the code and looks good. Haven't had time to try it out yet but I like that I can set VSync on any pin.
Yeah there are other nice things that can be done with VGA's VSYNC that already are part of the underlying video driver. It can do SoG and RGBS as well (so you can have either 3,4,5 pin VGA). For now this text driver just uses regular RBGHV for simplicity (I'm trying not to confuse people yet with a zillion options right now).
The video driver is also able to output text via component in both SDTV and HDTV formats as well as s-video and composite in PAL and NTSC. I just haven't exposed the init APIs for those yet in the text driver wrapper...but I likely will in time (it's only a few other init APIs to include).
I’m not at my computer atm, but isn’t it BGRHV pin sequence as P2 standard?
I'm looking at the output at the moment, it looks correct eg color sequence of text is
Black - Blue - Green -- Cyan - Red - Magenta - Brown - White (then same pattern for higher intensity)
In other words the display end seems correct
In the P2 HW the first pin the group is always the HSync, followed by the 3 colour pins, and VSync can be any pin. From a software perspective the colours are all treated the same and can be remapped in the palette if ever required.
So for the A/V breakout it actually maps like this:
Yes forgot H was the other end. I recalled RGB was reversed to my expectation. Of course the colors can be changed but its better to keep it the right way around if possible, or at least consistent.
The CSC could also swizzle the colors if necessary - that'd also work for truecolor modes.
Also, @rogloh , I think there's some errors in that timing selection logic you got there, In particular, this section
if flags & INTERLACED <> 0 syncFlags |= %0_0_010000 if flags & PAL <> 0 syncFlags |= %0_0_001000 timing := @int576_timing else timing := @int480_timing else ' progressive if output == COMPONENT_SDTV if flags & PAL <> 0 syncFlags |= %0_0_001000 timing := @prog576_timing else timing := @prog480_timing else ' CVBS/S-video if flags & PAL <> 0 syncFlags |= %0_0_001000 timing := @prog288_timing else timing := @prog240_timingThese can of course be worked around with a custom timing, but having the defaults be useful and consistent would help with making video output runtime-configurable (or well, load-time configurable) (which seems fairly necessary with the variety of supported video modes and types)
You could well be right Wuerfel_21. The various SDTV and EDTV modes are possibly some of the least well tested parts of the driver at this stage. That is why I haven't linked them into the higher lever text driver wrapper, though they are still possible to enable in the lower driver with the appropriate settings. It will be helpful to have people try it out and help me find the problems....
Another issue is that overscan can cause loss of text at the sides in some modes (you lose some active pixels). An outer black border can be setup in the driver to help alleviate this so the text starts further inside the visible part of the screen, but you can sometimes end up with less than your 80 columns that way.
I think I am also missing the 50Hz timing for the FULL HD 1080i signaling. It still needs to be added in. It is just 60Hz right now.
Overscan is just how TVs roll. If you actually want 320/640 fully visible pixels the pixel clock has to be higher (see any retro computer designed for TV output). That gives you non-square pixels and isn't great for graphics (just better when the screen is filled))
Perfect! I could hardly go to bed last night after I read about the compatibility update for Prop Tool.
This driver will become the baseline for P2 Quick Bytes.
I should be able to get started today! Update: been running the examples, and indeed, these are EASY to use (and I'm not a programmer).
Ken Gracey
Now posted as a P2 Quick Byte: https://www.parallax.com/dvi-vga-text-driver-demo/
When my VGA to USB video capture device arrives this week I'll be able to post proper video and screen captures; the static pictures don't do this justice. I'm looking forward to getting this part resolved.
@rogoloh, tag me for future releases and I'll update the Quick Byte.
Ken Gracey
Yes, the driver works with the Parallax WVGA LCD panel over HDMI...
Video of the text demo:
https://youtu.be/j6e--quQ58s
dgately
That's great you got it working Ken and managed to put this out so quickly. I'll be keeping the thread alive and update it more with further releases and try to let you know when they happen.
>
Really good to hear. You were able to helpfully also test out those timings in a previous effort so I was confident it should still work, but without that panel myself I didn't know for sure.
By the way, Tubular just let me know that DVI output did actually work for him with resolutions configured above 800x600@50Hz on some of his displays. Right now he's building up a nice table of results. All that happens is the refresh rate drops. At first I couldn't figure out why this worked with my code because it should require P2 clocks at 10x the pixel rate which exceed the P2 maximum frequency, but what is happening internally is the resolution selected is still assuming a P2 clock for VGA pixel generation at these resolutions and it then simply divides that number by 10 in my PASM driver whenever DVI is chosen. This overrides the normal pixel clock divider setting in the timing structure and as a side effect of the 10x divider it lets the coloured text work too. Double bonus!
Outputting higher resolutions at lower frame rates is still useful and it opens up a lot of possibilities, the issue is probably how many displays can support the low refresh (you can't be sure one will until you try it - though with HDMI inputs these days if you use an HDTV display I'd say you can't be sure of very much beyond accepting the standard TV timings).
I know other people in the past including Chip have had success in running their HDMI displays less than 50Hz so we can possibly add more modes like 720p24 etc directly into the driver for people who have displays that can use that. This can already be tested out by setting up fully custom timings, but having a single "vid.HD" type of constant to pass in to get 720p output makes it easier. I'll look into that. There are actually an enormous number of other resolutions that this driver can generate, they are just too numerous to test and include as "standards" right now. I've just selected a fairly common subset of PC type resolutions to build in, but there are heaps more and you can invent your own. This site is always a good resource for video timings:
http://tinyvga.com/vga-timing
Nice VGA driver!
I'm hearing some high pitched buzz on the audio output of the Edge audio/video card when using the latest version of this driver.
Am I the only one?
RJ
Yes confirming this low-refresh DVI works great with Philips Brilliance 288P6, nice and sharp. Whopping 240 characters across by 75 lines, using 8x16 font. Who even guessed this was possible with the P2? Did someone declare it impossible already?
It also works great with a JVL 32" TV, which was super cheap. Less sharp. No luck with other monitors at low refresh, yet, just these two.
The full color of the characters is a super good bonus, too. Very impressive work, Rogloh
Maybe it's cross talk on the A/V board or power supply noise if video and audio are being output together? The RCA outputs on that breakout board are shared with the VGA pins and can therefore be driven by this driver so if you are using those connectors for your audio that would explain it. If not and you are using the 3.5mm output instead does the noise depend on the resolution selected? Some of the video modes crank the P2 up to a very high frequency which will draw a lot more current. Also the driver will modify the PLL so if any audio application you also run in parallel with the video needed a particular P2 clock frequency to work right, the fact that the video driver goes and changes the P2 clock frequency might also somehow impact the sound quality there. The PLL clock setting is a global thing so video and audio will need to co-operate together.
I'll go connect the audio out to an amp on my own A/V board shortly to see if I hear anything too.
Update: I'm not hearing noise from the 3.5mm jack when I tried it myself and cranked up the amp volume. Maybe you have a short on your board linking some of the pins together, or it's something else? Be sure the audio plug is all the way in and you've not got DVI configured to output to that group of pins - it needs to go to another group of 8 pins.
Here's a picture of WUXGA (1920x1200) DVI text on the Philips 288P monitor
I'm using the 3.5mm output to the monitor. My monitor is an ACER 19" with VGA/Audio
Getting a high pitch with both demos.
Update: I'm not hearing noise from the 3.5mm jack when I tried it myself and cranked up the amp volume. Maybe you have a short on your board linking some of the pins together, or it's something else? Be sure the audio plug is all the way in and you've not got DVI configured to output to that group of pins - it needs to go to another group of 8 pins.