Shop OBEX P1 Docs P2 Docs Learn Events
VGA 800x600 4bpp driver with text & graphics support + XGA 1024x768 4bpp — Parallax Forums

VGA 800x600 4bpp driver with text & graphics support + XGA 1024x768 4bpp

ozpropdevozpropdev Posts: 2,791
edited 2016-10-11 23:55 in Propeller 2
Hi All
Here's a VGA driver for 800x600 @72Hz with 16 color palette.
Text uses the Prop1 16x32 font and supports foreground & background color.
Rotated text mode is also supported (90 degrees left).
Basic graphics support of plot line, circle and rectangle is included.
Plot text string, hex string and decimal signed and unsigned string too.
Demo code attached.


Version 7 here - More modes and improved performance
«1345

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    ozpropdev wrote: »
    Hi All
    Here's a VGA driver for 800x600 @72Hz with 16 color palette.
    Text uses the Prop1 16x32 font and supports foreground & background color.
    Rotated text mode is also supported (90 degrees left).
    Basic graphics support of plot line, circle and rectangle is included.
    Plot text string, hex string and decimal signed and unsigned string too.
    Demo code attached.

    Sweet, when I fire up my P2 I will try this out.

  • RoadsterRoadster Posts: 209
    I just tried it, nice demo
  • TubularTubular Posts: 4,622
    Yes very nice OzPropDev

    Look forward to doing stuff with this.
  • ozpropdevozpropdev Posts: 2,791
    Added 16x16 font mode - see first post
  • TubularTubular Posts: 4,622
    We need a way to capture images back onto a PC. Doesn't really matter if it takes a few seconds (over serial), though I guess it'd be nice to pause the video while it transfers.

    Or... external capture with a gaming capture device
  • RaymanRayman Posts: 13,900
    I posted some code that does that...
    Would need adjustments to work with this resolution and bpp though...
  • TubularTubular Posts: 4,622
    Ah yes that's right, would it take much to add the new svga mode?
  • potatoheadpotatohead Posts: 10,254
    With all the COGS and the serial (when it's finally sorted) doing virtual displays will make a lot of sense! For most drivers, the color engine will get used, meaning the virtual display can know what the colors are. Nice!

    @ospropdev: Looks great! Nice work man.

    (goes back to project, tries to avoid shiny things...)

  • ozpropdevozpropdev Posts: 2,791
    I've been playing with a serial capture function on the driver.
    I was running it @ 3M baud with mixed success.
    I switched over to a Ft2232H and pushed up to 8M baud with instant stability!
    If we had fractional bit rate control maybe 12M baud might be within reach. Looks encouraging. :)
    cap_01.jpg
    800 x 600 - 263K
  • TubularTubular Posts: 4,622
    So ~0.24 seconds to transfer a 800x600x4bpp frame?

    That's pretty impressive
  • jmgjmg Posts: 15,148
    ozpropdev wrote: »
    I was running it @ 3M baud with mixed success.
    Which serial device ?

    ozpropdev wrote: »
    I switched over to a Ft2232H and pushed up to 8M baud with instant stability!
    If we had fractional bit rate control maybe 12M baud might be within reach. Looks encouraging. :)
    Yes, & fractional support would be nice.
    I think the HW needed for USB, where the Baud-NCO-adder resets on edges, can give fractional baud 'for free'.**

    I've found FT232H/2232H are ok here at 12MBd PC-Tx only, but in loop-back my system tests drop some chars at 12MBd, ok at 8MBd


    ** With USB on every 2nd pin, that does raise a detail question over BAUD control (which can be on all pins).
    I guess simplest is to have that Baud-NCO-adder reset on edge available on all Baud generators ?
  • ozpropdevozpropdev Posts: 2,791
    jmg wrote: »
    Which serial device ?
    I'm using the FT231x on the P123-A9 board.
    Intermittently @ 3M it drops a block of data, works fine @ 2M though.
    I haven't seen the same behaviour with the Ft2232H, no dropped data @8M.

    One experiment I might try is using both channels of the Ft2232H and splitting the
    data into 2 chunks. Dual Tx @8M would be interesting if it works!
  • jmgjmg Posts: 15,148
    ozpropdev wrote: »
    One experiment I might try is using both channels of the Ft2232H and splitting the
    data into 2 chunks. Dual Tx @8M would be interesting if it works!

    Sounds a good test.

    There is also a Fast Serial mode (Clocked Async) in FT2232H, that can test faster :

    FSCLK Driven by P2, allowed up to 50MHz in specs.
    P2 polls FSCTS, and sends a byte when High (FSCTS pulses low for each byte in)

    Diagrams show FSCLK as continuous, and it samples an Async-framed FSDI on the rising edge. (FSDI cannot change on that edge)

    80M/4 clock & slower should be comfortable, with maybe 80M/3 and 80M/2 possible.
    This would require the CLK and TxD overflows stay in sync, once started, and that Tx is always paced from Baud-rate.

    I think PC-> P2 at 80M/2 may not be supported, even tho it is a Sync signal ?
    Chip has said before Async limit is SysCLK/3, but maybe SysCLK/2 can work with a CLK signal (Still Async, not Sync, but no sampling issues )



  • TubularTubular Posts: 4,622
    edited 2016-03-02 04:24
    We need to look at this new FT260Q as well.

    It also claims 12MBaud, but using HID class. Pricing is sharp at ~$1.53 in 100 off qtys, significantly cheaper than FT231X, and QFN package is 5x5mm

    Could make for a nice high speed prop plug revision
  • ozpropdevozpropdev Posts: 2,791
    OK experiment worked nicely. :)
    I was able to split the pixel data and send it via two serial channels @ 8M baud.

    Here the code snippet of the TX code. 
    'send pixels over two serial channels @8M baud
	
send_pixels	loc	ptra,#@video_buffer	'txa data ponter
		mov	ptrb,ptra
		add	ptrb,##w*h/4		'txb data pointer
		rep	@.loop,##w*h/4
		rdbyte	adra,ptra++		'txa data
		rdbyte	adrb,ptrb++		'txb data
		pinsety	adrb,#txb_pin		'send txb data
		pinsety	adra,#txa_pin		'send txa data
		waitedg				'wait for txa completion
		pinack	#txa_pin	
.loop
    Getting a big chunk of data into the PC that fast is great but is limited by how fast the PC can deal with it.
    Has some interesting application though. :)


  • TubularTubular Posts: 4,622
    nice work, Brian. Gotta be happy when the multi ghz PC becomes the bottleneck

  • ozpropdevozpropdev Posts: 2,791
    edited 2016-03-02 13:08
    After a few more tests the figures i'm getting aren't quite as expected.
    The issue is I can't get the data out of hub quick enough to feed the FT2232H.
    For example the expected "best case" for a 120k block @8M baud should be 150mS.
    The best I can do with tight code is 198mS.
    Of course the real silicon will improve these figures.
    Still good though. ;)

    Edit: BTW The code above takes 264mS to blast 240k out.
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    After a few more tests the figures i'm getting aren't quite as expected.
    The issue is I can't get the data out of hub quick enough to feed the FT2232H.
    For example the expected "best case" for a 120k block @8M baud should be 150mS.
    The best I can do with tight code is 198mS.
    Of course the real silicon will improve these figures.
    Still good though. ;)

    Can you do a RDFAST, then RFBYTE instructions for getting the data out? You'd have to interleave it afterwards on the PC side.
  • cgraceycgracey Posts: 14,133
    edited 2016-03-02 13:09
    Hey, maybe there should be some sub-modes where you can hand the serial transmitter 4 bytes, at once, via PINSETY.
  • ozpropdevozpropdev Posts: 2,791
    That would be sweet!
  • RamonRamon Posts: 484
    The FT2232H (and FT232H) has a fast 245 synchronous mode that allows around 40 MBYTES per second.

    The FT2232H allows this mode ONLY on the first channel. The FT232H only has one channel and also supports this fast mode.

    When the FTDI is configured in this mode it sources a 60 MHz clock and transfer 8 bits per clock.

    I am waiting for the P2 documentation about the serial SYNC modes. I want to use two UM232H modules to transfer data between P2/FPGA and computer using two USB channels.
  • jmgjmg Posts: 15,148
    cgracey wrote: »
    Hey, maybe there should be some sub-modes where you can hand the serial transmitter 4 bytes, at once, via PINSETY.
    12MBd should be possible with fractional baud (coming?)
    If dual 8MBd is showing signs of saturation, 4 bytes at once would help.

    If doing that, you should look at FTDI mode of FAST SERIAL mode too. Gives50MBd.

    I THINK P2 can mostly do that now?
    Needs up to 50MHz clk continuously from P2, and there is a FSCTS handshake line.
    Data is ASYNC framed, start bit = L
    There is a optional 9th bit to signal channel- that could complicate 32b blocks?

    TX needs to stay phase locked with clk, even with FSCTS and multi bytes & pauses.
    RX support to Sysclk /2 is needed (no phase jitter can occur, as P2 generates the CLK.
  • jmgjmg Posts: 15,148
    Ramon wrote: »
    The FT2232H (and FT232H) has a fast 245 synchronous mode that allows around 40 MBYTES per second.

    The FT2232H allows this mode ONLY on the first channel. The FT232H only has one channel and also supports this fast mode.

    When the FTDI is configured in this mode it sources a 60 MHz clock and transfer 8 bits per clock.

    I am waiting for the P2 documentation about the serial SYNC modes. I want to use two UM232H modules to transfer data between P2/FPGA and computer using two USB channels.

    The FT600 has a similar FIFO mode, ftdi generates clk.
    Choices are 16 & 32 wide.
    The streamer should manage the data rates, but could need some handshake support.

  • cgraceycgracey Posts: 14,133
    Ah, the streamer. I forgot that I need to add some sub-byte modes. THIS would be the best way to handle QSPI data.
  • jmgjmg Posts: 15,148
    edited 2016-03-02 23:29
    cgracey wrote: »
    Ah, the streamer. I forgot that I need to add some sub-byte modes. THIS would be the best way to handle QSPI data.
    Yes :)
    4b : manages the main-bandwidth side of QuadSPI
    2b : There is a Dual-SPI, which could also cover JTAG (needs 1b Rx), and I'm not sure if x1 is already in streamer modes ?
    1b : Is a useful way to send the address/command fields for many QuadSPI parts, which lack a Sticky-Quad mode.
    Some flash parts can be set to take address in Quad, but the SRAMs out there now, seem to have 1 bit link for the address/command, then they flip to Quad IO.

    With the above, JTAG uses 2b Streamer out, for encode of TMS and TDO, and TDI is 1b streamer in.
    User preloads the data and selects N clocks.

    QuadSPI RAM use 1b out for Address.Command, then flip modes ? to 4b IO
    2x QuadSPI, could use 2 streamers, but they need to be in-sync ?

    Addit:
    Checking SRAM :
    Microchip have a Sticky-mode on their 20MHz QuadSPI RAM, needs one byte sent to set, and stays in Quad until reset. One set, Commands and Address are sent Quad.
    VLSI have faster 36MHz QuadSPI RAM, but that needs 32 clocks in 1b to send command/address, then it flips to Quad for that packet.
  • RaymanRayman Posts: 13,900
    edited 2016-03-02 23:44
    Think I have the monitor working with this mode now, see bmp

    Oops, something is wrong (just looked at actual output).
    bmp
    bmp
    SVGA8_Capture.bmp
    1M
  • TubularTubular Posts: 4,622
    Looks like the blue channel is missing, but looks mighty impressive otherwise!
  • RaymanRayman Posts: 13,900
    Thanks. I see the problem now...
    There is a difference between format of Windows BMP color entries and P2 palette entries.
    Windows BMP has alpha byte on MSByte and P2 has zero on LSByte.
    So, I think I need to lie or cheat by one byte to make it work right...
  • TubularTubular Posts: 4,622
    Ok.

    Can't just offset the hub reading by one byte? Guess it would need a non zero alpha too
  • RaymanRayman Posts: 13,900
    Got it now. Will post in other thread so as not to appear to be highjacking...
Sign In or Register to comment.