Author Topic: FPGA video format conversion  (Read 17349 times)

0 Members and 1 Guest are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18961
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #25 on: July 28, 2017, 10:01:36 pm »
Check out Altera's MAX10 devices.  No bootprom and plenty of ram for 8 bit grey, multiple lines, or you can oversample and not worry about the PLL phase fine tuning, an all in 2.5 chip solution.  1 Max PLD, 1 Video ADC, + DAC, or parallel digital out to panel.
Too many IOs for your needs, 144 pin TQFP,
https://www.digikey.com/product-detail/en/altera/10M02SCE144C8G/544-3098-ND/5284822
If you go that route it is much easier to buy a readily made VGA to TFT scaler board. One of the problems is that you'll need to phase align the ADC's sampling clock with the input signals to prevent sampling at a point which is half way a pixel. Otherwise straight vertical lines will look funny.

In my experience it is better to go from digital to digital and don't mess with the analog display signals.
« Last Edit: July 28, 2017, 10:21:44 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 3555
  • Country: ca
Re: FPGA video format conversion
« Reply #26 on: July 29, 2017, 12:05:24 am »
Check out Altera's MAX10 devices.  No bootprom and plenty of ram for 8 bit grey, multiple lines, or you can oversample and not worry about the PLL phase fine tuning, an all in 2.5 chip solution.  1 Max PLD, 1 Video ADC, + DAC, or parallel digital out to panel.
Too many IOs for your needs, 144 pin TQFP,
https://www.digikey.com/product-detail/en/altera/10M02SCE144C8G/544-3098-ND/5284822
If you go that route it is much easier to buy a readily made VGA to TFT scaler board. One of the problems is that you'll need to phase align the ADC's sampling clock with the input signals to prevent sampling at a point which is half way a pixel. Otherwise straight vertical lines will look funny.

In my experience it is better to go from digital to digital and don't mess with the analog display signals.

Arrrrrgggg, you haven't been reading my post & MattHollands posts.  Matt intends to use the TVP7002 as it was designed to sample video, generate a pixel clock, do black level restoration and has built in antialiasing filters & pixel phase adjustment.  The MAX10 would take in the monochrome 8 bit video (1 channel from the TVP7002 RGB digitizer) and PLL 2x clock of the video, delayed 1 line, driving 2 copies out at 2x speed including the HS signal.  Voila, line doubled video.  Nothing more than an input counter on DP ram fed 8 bit video + 1 bit h-sync, with counter reset on low to high transition of h-sync, running the input, and an output counter at 2x driving the output data and output h-sync with the same counter reset on that side reset at that h-sync.  Every new input line cycles a MSB address line on the input side of the ram while a 2 line DFF delay of that MSB address is send to the output side clocked by the transition of the output sync.  You are looking at a design using around 80 logic elements + 2kx9bit dual-port ram.  The smallest MAX 10 will be effectively empty.
A 2 year old can logic this one up in Altera's Quartus in the graphic editor consuming half of 1 single top-hierarchy page.  Not a single line of verilog or VHDL code is needed.
__________
BrianHG.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18961
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #27 on: July 29, 2017, 02:32:59 pm »
And where is the microcontroller + software needed to configure the TVP7002? Again, if you got his route then a pre-made board will be easier and cost less. Also in many cases you can use the monochrome information and map this onto colors to provide a display which is easier to read. I did this on an Advantest R3261A and a Lecroy LW420A.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #28 on: July 30, 2017, 10:34:42 pm »
And where is the microcontroller + software needed to configure the TVP7002? Again, if you got his route then a pre-made board will be easier and cost less. Also in many cases you can use the monochrome information and map this onto colors to provide a display which is easier to read. I did this on an Advantest R3261A and a Lecroy LW420A.

Well this project is largely for learning purposes. Hence I want to try spinning my own FPGA board, capture and process the signals myself etc. I am planning on remapping colours!  :)
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #29 on: July 31, 2017, 09:23:00 pm »
Having done a couple of FPGA video format conversions, I thought I'd contribute a few ideas. Unlike nctnico or BrianHG, I'm not going to give OP a solution, but rather a few points to consider:

1) Have you clearly defined the input and output of the design, and other constrains?

For the input, you would need to get to the bottom of it, measure the pixel clock frequency and all the timing parameters in the unit of pixel clock (horizontal total, active, sync width, front and rear porch, and the same for vertical).

For the output, you need to know your goal. Is it an analog, industrial-standard VGA-compliant output, or something acceptable by a PC monitor, or a digital video signal acceptable by an LCD panel? They are three quite different goals, although they overlap in certain areas.

In terms of other constrains, would you mind tapping into the pixel clock in the original video circuit, and perhaps the digital signals that generate the analog video via a video DAC or resistor network, or you are strictly limited to the signals available on the interface cable?
What about power and mechanical constrains, such as, do you plan to install an LCD panel in the original unit replacing the CRT? If so, the output format will be further limited by the resolution and size of available LCD panels.

2) The solution depends on what you have, and what you want to do.

For example, if you have access to the original pixel clock, things can be much easier. Do the math, and you'll find out if you can convert the original pixel clock into the new video format pixel clock using the PLL or DCM in an FPGA - they often have limited M, N and reference frequency range. If you maintain the exact frame rate, you can live without a frame buffer. How many line buffers you need depends on the vertical active-to-total ratio of the input vs output formats. Draw diagrams of input and output video format in 2D and compare them side by side, and you'll understand what I meant.

If you don't have access to the original pixel clock, you would need a PLL to recreate the pixel clock in order to sample the video signal properly. Not just any PLL, a PLL with KHz reference input and multiplication factor in the hundreds to the thousands. There are dedicated IC for that purpose, and fortunately Video ADCs often come with one built-in.
 
Do you really need a Video ADC, aside from the built-in PLL? You don't if you have access to the digital video signals in the original circuit, or if the original video has very few intensity levels (let's say 8 or less). By the way, using an ADC does not prevent you from doing grey scale to color mapping.

3) Don't let the recipe limit your creativity.

Both nctnico and BrianHG's solutions have their merits. You don't have to take one and drop the other. Instead, understand your requirement and take the parts from their solutions that meet your needs. For example, MAX10 seems nice, even if you don't use a Video ADC. On the other hand, there are plenty of open-source soft-core CPUs that you can integrate into an FPGA to do housekeeping things such as configuring a Video ADC via I2C.

Line doubling works. True. But does the line-doubled video exactly what you wanted from the beginning? How much off is it from the industrial-standard VGA? What will the picture look like on an LCD panel installed in the original chassis, if that's your goal? If you need more than the most basic image scaling, there are at least 20 different algorithms, and someone developed a program that allows you to compare them side-by-side.

My point is, a lot of planning can be done on the drawing board before you jump in and start writing RTL or drawing schematics.
Hope that helps your learning experience, and good luck ;)
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #30 on: July 31, 2017, 11:11:42 pm »
Quote
For the output, you need to know your goal. Is it an analog, industrial-standard VGA-compliant output, or something acceptable by a PC monitor, or a digital video signal acceptable by an LCD panel? They are three quite different goals, although they overlap in certain areas.
Originally I wanted to make it a true, industrial standard VGA, but having tested out a lot of monitors and found that they will lock onto a less "standard" signal, I'm happy to settle for any signal acceptable by a PC monitor. I  don't want a digital video signal because I want to be able to easily change the panel etc or have an external display.

Quote
In terms of other constrains, would you mind tapping into the pixel clock in the original video circuit, and perhaps the digital signals that generate the analog video via a video DAC or resistor network, or you are strictly limited to the signals available on the interface cable?

I do not want to modify the electronics at all.

Quote
What about power and mechanical constrains, such as, do you plan to install an LCD panel in the original unit replacing the CRT? If so, the output format will be further limited by the resolution and size of available LCD panels.

I do intend to rip out the old display and replace it. The LCD panel that I have found seems to be the perfect size. The original display was about 10" diagonal with 8" of actual display. I am replacing this with a 16:9 10.1" LCD display running in 4:3 mode (black bars).

Quote
Line doubling works. True. But does the line-doubled video exactly what you wanted from the beginning? How much off is it from the industrial-standard VGA? What will the picture look like on an LCD panel installed in the original chassis, if that's your goal? If you need more than the most basic image scaling, there are at least 20 different algorithms, and someone developed a program that allows you to compare them side-by-side.
Although it's not quite what I wanted from the beginning (non-standard video signal rather than true VGA), I think that it is just because I did not understand exactly how VGA worked. Also, could you specify what you mean by the image scaling thing? A link to the program you are talking about for example.

I appreciate your thoughts!!!
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #31 on: August 01, 2017, 06:56:39 am »
With a 10.1" 16:9 panel you are most likely dealing with LVDS or more advanced interface. Also part of the active display area that falls into the CRT viewing window could end up with X and Y pixel counts not integer multiples of the CRT pixel count. For instance, you may need to scale the 500x240 CRT image to something like 1170x760 to fill up the window just right. Now you'll need an image scaling algorithm that fits your expectations of complexity and image quality.

The software (open source) I talked about is at:
https://code.google.com/archive/p/2dimagefilter/
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: FPGA video format conversion
« Reply #32 on: August 01, 2017, 03:19:44 pm »
Indeed, directly interfacing a LVDS LCD is not a piece of cake.  It's more difficult and complex than interfacing  old 5" STN LCDs and modern TFT little 4.3"-5" LCDs by five orders of magnitude at least.

I suggest you to interface a VGA-LCD, thus you have to deal only with VGA signals.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #33 on: August 01, 2017, 03:31:11 pm »
The display I am buying does come with a VGA controller board so I will be using VGA
Read about my stuff at: projects.matthollands.com
 

Offline marshallh

  • Supporter
  • ****
  • Posts: 1462
  • Country: us
    • retroactive
Re: FPGA video format conversion
« Reply #34 on: August 03, 2017, 03:41:52 am »
LVDS is trivial as long as your fpga supports serialization (and basically all do). The hardest part is packing your bits into the laneformat. It's 100% identical to parallel RGB apart from that. I converted a design in 30mins and it worked second try.
Verilog tips
BGA soldering intro

11:37 <@ktemkin> c4757p: marshall has transcended communications media
11:37 <@ktemkin> He speaks protocols directly.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18961
  • Country: nl
    • NCT Developments
Re: FPGA video format conversion
« Reply #35 on: August 03, 2017, 03:04:14 pm »
LVDS is trivial as long as your fpga supports serialization (and basically all do). The hardest part is packing your bits into the laneformat. It's 100% identical to parallel RGB apart from that. I converted a design in 30mins and it worked second try.
The easiest option is to use a Serdes chip from (for example) TI which converts parallel RGB + sync into an LVDS stream.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #36 on: September 20, 2017, 10:15:21 pm »
Ok so I have since bought the display I am going to use.

Unfortunately, when I line double to signals from the logic analyser, it takes up only a small portion of the screen. (see attachment) The monitor is locking onto a 1280x768 resolution.

It looks like the original pixel frequency of the logical analyser is about 17.375MHz with a line time of 40us. It looks like simple line doubling won't get me a reasonable image. I may have to resort to buffering the frame and outputting at a different resolution.
« Last Edit: September 20, 2017, 10:20:07 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 3555
  • Country: ca
Re: FPGA video format conversion
« Reply #37 on: September 21, 2017, 10:00:44 am »
For vertical, It looks like you might have the space for line trippling.  Depending on how the original scope centers it's raster image, you will loose a few lines.

As for multiplying the vertical by 2.5x, you will need 5 lines of video cache to do this, but with monochrome, you should have space in your FPGA.  Not when scaling by a fraction, you need shades of grey on the output for a smear effect. 

For the horizontal, drive the LCD with a full 1280 pixels, but, for the TVP sampler, you can cheat by changing the horizontal PLL to sample more pixels than there actually are.  This will horizontally stretch the image by any number you like.  HOWEVER, for this to look good, you will need to set the TVP ADC to it's lowest RGB bandwidth filter setting (this softens the edges making a simulated filtered scale) and you will want at least 16 shades of grey support when imputing and outputting your video signal to get soft anti-aliased rounded edges on your pixels.  Otherwise, you will need to do this horizontal scale in FPGA code which isn't too terible since you scaling factor is fixed, but, it now becomes a question of configuring your PLL to multiply by 5, divide by 2.
__________
BrianHG.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 3555
  • Country: ca
Re: FPGA video format conversion
« Reply #38 on: September 21, 2017, 10:06:33 am »
With the scoped video output, how many lines of video actually has video content.  If it is only 240 of them, multiplying each line coming in by 3 gives you 720.  You will only have an extra 24 lines on the top and 24 line on the bottom of you LCD display.  This would be fairly good.  If your LCD screen is a 1280x720, this would fill out perfectly.

But, it your output picture is 384 lines, 25Khz x 416 lines = 60hz.  416 lines - 384 = 32 lines, 6 lines for v-front porch, 6 for v-sync, 20 for v-back-porch (These figures sound about right), then on your double, you need to double 384 lines, not 240 lines and your LCD should fill the picture completely vertically.  384x2=768 active lines of video.  Note that 512x384 is a natural old VGA video mode.
« Last Edit: September 21, 2017, 10:15:56 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #39 on: September 21, 2017, 12:08:37 pm »
I have yet to try the 2.5x multiply, but won't be able to do so for a few days.

I tried the 3x multiply and the display now locks onto a 1280x960 video and so it no longer fills the display  |O. (see attached)

The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240)
« Last Edit: September 21, 2017, 12:27:21 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 3555
  • Country: ca
Re: FPGA video format conversion
« Reply #40 on: September 22, 2017, 04:39:14 am »
I have yet to try the 2.5x multiply, but won't be able to do so for a few days.

I tried the 3x multiply and the display now locks onto a 1280x960 video and so it no longer fills the display  |O. (see attached)

The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240)

Ohhhhhhh, 1024x600, that's an oddball...  500x240 at 2.5x Y res would scale great.  Here is the trick:

Source video:  Fill these 4 in sequence...
Line buffer1
Line buffer2
Line buffer3
Line buffer4
loop...

Video output sequence, delayed after 3 previous line buffers have been filled.
Show Line buffer1
Show Line buffer1
Show Line buffer2
Show Line buffer2
Show Line buffer2 averaged with Line buffer3  (Just add the 7LSB of each buffer together to get a new 8 bit sum)
Show Line buffer3
Show Line buffer3
Show Line buffer4
Show Line buffer4
Show Line buffer4 averaged with Line buffer1
.....
You get the point...

If you use this cheap average trick, this will give you nice sharp, but still rounded edges on the odd half extra lines.
Without the average, it will be a little chunky in places.

A smooth linear transformation process is possible, but, you will need (for monochrome) 3x2 multiply add with a rotating 5 sets of 3 factor table  (this can be calculated on the fly, but there is only 15 of them.  Putting these 3x5 numbers in a table rom would work best as you can play with them).  This one is the smoothest, but, eats up HW multipliers in the FPGA.  The coefficients in the table will control the vertical sharpness, giving you a linear filter, or cubic filter, or a hard sharp pixel clump filter.
« Last Edit: September 22, 2017, 04:48:13 am by BrianHG »
__________
BrianHG.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 3555
  • Country: ca
Re: FPGA video format conversion
« Reply #41 on: September 22, 2017, 04:47:26 am »
I'm glad you are still working on this project even though you won that Oscilloscope in the contest from Dave.
__________
BrianHG.
 
The following users thanked this post: MattHollands

Online ebastler

  • Super Contributor
  • ***
  • Posts: 3418
  • Country: de
Re: FPGA video format conversion
« Reply #42 on: September 22, 2017, 02:34:44 pm »
The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240) ´

Yes -- but how do you actually convince the display to work at its native resolution? When you tried 2x scaling (in X and Y, I assume) in your post further above, you mentioned that the display scaled to 1280*768 -- although 1024*600 should have worked nicely to display that?! 

Worth a try to use 2x scaling horizontally and 2.5x vertically. But the display might still have its own ideas about the mode it sets?
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #43 on: September 22, 2017, 02:46:58 pm »
The screen's native resolution is 1024x600, so the 2.5x might work nicely. (the original resolution is 500x240) ´

Yes -- but how do you actually convince the display to work at its native resolution? When you tried 2x scaling (in X and Y, I assume) in your post further above, you mentioned that the display scaled to 1280*768 -- although 1024*600 should have worked nicely to display that?! 

Worth a try to use 2x scaling horizontally and 2.5x vertically. But the display might still have its own ideas about the mode it sets?
Yep I agree it might be an issue. I will have to try it to see what it locks onto but I am away for a few days
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #44 on: September 22, 2017, 02:49:45 pm »
I'm glad you are still working on this project even though you won that Oscilloscope in the contest from Dave.
[emoji846] this has always been more of a learning project and this logic analyzer/scope has features that the rtb2004 doesn't anyway e.g. 50 ohm input, 64 channel logic analyzer etc
Read about my stuff at: projects.matthollands.com
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12111
  • Country: gb
    • Mike's Electric Stuff
Re: FPGA video format conversion
« Reply #45 on: September 22, 2017, 06:28:06 pm »
Something that may be worth a try is a simplistic method using a single dual-port BRAM  framebuffer.
You will probably get some tearing artifacts as the output frame will sometimes contain elements from multiple source frames, but it may be acceptable, at least as a first attempt.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #46 on: September 22, 2017, 09:18:24 pm »
Something that may be worth a try is a simplistic method using a single dual-port BRAM  framebuffer.
You will probably get some tearing artifacts as the output frame will sometimes contain elements from multiple source frames, but it may be acceptable, at least as a first attempt.

If the current approach of keeping the input and output frames in sync doesn't work then I'll probably resort to using a frame buffer. I am prototyping on a Xilinx Artix-7 FPGA  dev board which will have enough BRAM for multiple frames, but I plan to use a Lattice MachXO for the final design to save on cost (of the programmer and the FPGA) which only has enough BRAM for a few lines. However, with a pixel clock of ~17.375MHz I can probably get away with only two (if not one)  £0.50 SPI RAMs to handle the frame buffers.
« Last Edit: September 22, 2017, 09:20:33 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #47 on: September 22, 2017, 09:36:14 pm »
It may also be possible to compress the frames using RLE seeing as there are so few colours and each line generally only has a few colour transitions.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #48 on: September 26, 2017, 01:05:38 pm »
For vertical, It looks like you might have the space for line trippling.  Depending on how the original scope centers it's raster image, you will loose a few lines.

As for multiplying the vertical by 2.5x, you will need 5 lines of video cache to do this, but with monochrome, you should have space in your FPGA.  Not when scaling by a fraction, you need shades of grey on the output for a smear effect. 

For the horizontal, drive the LCD with a full 1280 pixels, but, for the TVP sampler, you can cheat by changing the horizontal PLL to sample more pixels than there actually are.  This will horizontally stretch the image by any number you like.  HOWEVER, for this to look good, you will need to set the TVP ADC to it's lowest RGB bandwidth filter setting (this softens the edges making a simulated filtered scale) and you will want at least 16 shades of grey support when imputing and outputting your video signal to get soft anti-aliased rounded edges on your pixels.  Otherwise, you will need to do this horizontal scale in FPGA code which isn't too terible since you scaling factor is fixed, but, it now becomes a question of configuring your PLL to multiply by 5, divide by 2.

Unfortunately, when I 2.5x the image, the resolution switches to a 1280x960 resolution (see attachment).

I discovered that I can do full 1024x600 (native resolution) with a clock of 48.875MHz from this document: https://www.kernel.org/doc/Documentation/fb/viafb.modes
This is obviously not a nice multiple of the 17.375MHz clock of the original image and so will eventually go out of sync. I can change the clock to be 48.65MHz (2.8x) and the display will lock on, but we are no longer at 60Hz frame rate so will loose sync. Adjusting the length of the porches to make it 60Hz causes the display to detect a weird resolution.

At this point, I think my best bet is to use two completely separate clock domains and a frame buffer in between. Sure, line doubling (or whatever) may WORK, but it won't give me the best image.
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #49 on: September 26, 2017, 07:44:49 pm »
Because you have an LCD driver board in between, you may or may not be able to use the native resolution of the LCD panel. It depends on what formats are pre-programmed in the driver board. You can generate an LCD panel native timing with the FPGA and give it a try.

I would ditch the LCD driver board and drive the panel directly with FPGA. I don't trust its scaler to give the best result, nor do I like the automatic detection and adaptation of video timings from the LCD driver board.

If you look at the LCD datasheet, the clock frequency is not strict (it has an acceptable range), the horizontal and vertical timing are not strict, either. With that flexibility you may be able to get away with frame buffer. Just need to do your math and find out. You loose that flexibility to a certain extent because the LCD driver board may apply additional restrictions.

Like I said, you should fully know your input, set a firm target for your output, and then work on the implementations to bridge the input and the output. It seems now you are limited by the choice of implementation and as a result have an ever changing output target. Well, that may be what most hobby projects look like.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf