Yet Another Graphics Controller

I've developed a simple graphics controller:

http://www.frank-buss.de/yagraphcon/index.html

Currently it needs twice as much block RAM as the resolution requires,
because the architecture is very simple, with two read ports and one write
port. I've developed it to see how difficult it is to develop a graphics
controller (it was easy, I needed about 3 days for it) and to test a new
FPGA module. Maybe implementing a GPU core would be better, because then
you can implement the graphics acceleration you need, instead of being
restricted to the available functions and then it is possible to implement
more complex functions, like triangle shading. And a fast external SRAM or
SDRAM interface is missing, because internal block RAM of inexpensive FPGAs
is too small for higher resolutions.

BTW: are there any other interesting concepts than framebuffers? Many
gaphics controller have text modes, but this is only a special case. Do you
think it is possible to define a general functional graphics output device?
E.g. you upload the function sqrt(x*x+y*y)<10=white and the FPGA evaluates
this function for each x/y pair on the fly with pixel clock and shows a
circle. But the calculation needs to be really fast, if you define multiple
combined functions.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Aug 23, 6:53=A0pm, Frank Buss <f...@frank-buss.de> wrote:
> I've developed a simple graphics controller:
>
> http://www.frank-buss.de/yagraphcon/index.html
>
> Currently it needs twice as much block RAM as the resolution requires,
> because the architecture is very simple, with two read ports and one writ=
e
> port. I've developed it to see how difficult it is to develop a graphics
> controller (it was easy, I needed about 3 days for it) and to test a new
> FPGA module. Maybe implementing a GPU core would be better, because then
> you can implement the graphics acceleration you need, instead of being
> restricted to the available functions and then it is possible to implemen=
t
> more complex functions, like triangle shading. And a fast external SRAM o=
r
> SDRAM interface is missing, because internal block RAM of inexpensive FPG=
As
> is too small for higher resolutions.
>
> BTW: are there any other interesting concepts than framebuffers? Many
> gaphics controller have text modes, but this is only a special case. Do y=
ou
> think it is possible to define a general functional graphics output devic=
e?
> E.g. you upload the function sqrt(x*x+y*y)<10=3Dwhite and the FPGA evalua=
tes
> this function for each x/y pair on the fly with pixel clock and shows a
> circle. But the calculation needs to be really fast, if you define multip=
le
> combined functions.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
tems.de


did you check the genode-FX?

they have full gui and graphics library support also, all free to use

Antti

Antti.Lukats@googlemail.com wrote:

> did you check the genode-FX?
> 
> they have full gui and graphics library support also, all free to use

Thanks, the high-level part is interesting. But I have browsed the VHDL
files and it seems that they don't implement any graphics acceleration,
except fast screen clear, and it is a standard framebuffer concept, but
still very complete with the software graphics library. Drawbacks are, that
it is available as GPL or commercial, only and very Xilinx specific. My
system is BSD, which might be better for small commercial projects and
should work on FPGAs from other vendors, too.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Aug 23, 8:59=A0pm, Frank Buss <f...@frank-buss.de> wrote:
> Antti.Luk...@googlemail.com wrote:
> > did you check the genode-FX?
>
> > they have full gui and graphics library support also, all free to use
>
> Thanks, the high-level part is interesting. But I have browsed the VHDL
> files and it seems that they don't implement any graphics acceleration,
> except fast screen clear, and it is a standard framebuffer concept, but
> still very complete with the software graphics library. Drawbacks are, th=
at
> it is available as GPL or commercial, only and very Xilinx specific. My
> system is BSD, which might be better for small commercial projects and
> should work on FPGAs from other vendors, too.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
tems.de

yes, GPL is real bad thing, one latest example is OpenOCD project
they can not distribute compiled binaries if those support FTDI
drivers
due to GPL restrictions.

recompiling OpenOCD from sources for windows is sure possible
but having precompiled version would make live much more easier
well, GPL prevents that...

Antti

Frank Buss <fb@frank-buss.de> wrote:

>Antti.Lukats@googlemail.com wrote:
>
>> did you check the genode-FX?
>> 
>> they have full gui and graphics library support also, all free to use
>
>Thanks, the high-level part is interesting. But I have browsed the VHDL
>files and it seems that they don't implement any graphics acceleration,
>except fast screen clear, and it is a standard framebuffer concept, but
>still very complete with the software graphics library. Drawbacks are, that
>it is available as GPL or commercial, only and very Xilinx specific. My
>system is BSD, which might be better for small commercial projects and
>should work on FPGAs from other vendors, too.

Did you even look into a Yamaha VG9938? This chip has acceleration for
copying and line draw. AFAIK it is available as HDL source. There is
also a VG9958 which is better & faster. These chips where used in MSX
home computers.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

"Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com> wrote:

>On Aug 23, 8:59=A0pm, Frank Buss <f...@frank-buss.de> wrote:
>> Antti.Luk...@googlemail.com wrote:
>> > did you check the genode-FX?
>>
>> > they have full gui and graphics library support also, all free to use
>>
>> Thanks, the high-level part is interesting. But I have browsed the VHDL
>> files and it seems that they don't implement any graphics acceleration,
>> except fast screen clear, and it is a standard framebuffer concept, but
>> still very complete with the software graphics library. Drawbacks are, th=
>at
>> it is available as GPL or commercial, only and very Xilinx specific. My
>> system is BSD, which might be better for small commercial projects and
>> should work on FPGAs from other vendors, too.
>>
>> --
>> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
>tems.de
>
>yes, GPL is real bad thing, one latest example is OpenOCD project
>they can not distribute compiled binaries if those support FTDI
>drivers
>due to GPL restrictions.

Fortunately you can also use the free USB drivers for the FTDI chips.
Not much is lost.

>recompiling OpenOCD from sources for windows is sure possible
>but having precompiled version would make live much more easier
>well, GPL prevents that...

Indeed. That pissed me off as well.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

On Aug 24, 8:04=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> Frank Buss <f...@frank-buss.de> wrote:
> >Antti.Luk...@googlemail.com wrote:
>
> >> did you check the genode-FX?
>
> >> they have full gui and graphics library support also, all free to use
>
> >Thanks, the high-level part is interesting. But I have browsed the VHDL
> >files and it seems that they don't implement any graphics acceleration,
> >except fast screen clear, and it is a standard framebuffer concept, but
> >still very complete with the software graphics library. Drawbacks are, t=
hat
> >it is available as GPL or commercial, only and very Xilinx specific. My
> >system is BSD, which might be better for small commercial projects and
> >should work on FPGAs from other vendors, too.
>
> Did you even look into a Yamaha VG9938? This chip has acceleration for
> copying and line draw. AFAIK it is available as HDL source. There is
> also a VG9958 which is better & faster. These chips where used in MSX
> home computers.
>
> --
> Failure does not prove something is impossible, failure simply
> indicates you are not using the right tools...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg=
er hammer!"
> --------------------------------------------------------------

MSX source is available (was) YES, so whatever is used there
should be there too

Antti

Nico Coesel wrote:

> Did you even look into a Yamaha VG9938? This chip has acceleration for
> copying and line draw. AFAIK it is available as HDL source. There is
> also a VG9958 which is better & faster. These chips where used in MSX
> home computers.

I've found some datasheet for V9938. Why do you think it is worth to take a
look at it? It looks like other graphics chips from this time, e.g. the MOS
6567 from the C64, but with some more features, like bitblitting and better
sprites.

Of course, my YaGraphCon has less features, but it is my first graphics
controller, so the main goal was that it works at least :-) Maybe I'll
enhance it with some microcode. Then it should be possible to implement
text mode or sprites with different microcode instead of hardwired hardware
and it would need less block RAM.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Aug 24, 8:37=A0pm, Frank Buss <f...@frank-buss.de> wrote:
> Nico Coesel wrote:
> > Did you even look into a Yamaha VG9938? This chip has acceleration for
> > copying and line draw. AFAIK it is available as HDL source. There is
> > also a VG9958 which is better & faster. These chips where used in MSX
> > home computers.
>
> I've found some datasheet for V9938. Why do you think it is worth to take=
 a
> look at it? It looks like other graphics chips from this time, e.g. the M=
OS
> 6567 from the C64, but with some more features, like bitblitting and bett=
er
> sprites.
>
> Of course, my YaGraphCon has less features, but it is my first graphics
> controller, so the main goal was that it works at least :-) Maybe I'll
> enhance it with some microcode. Then it should be possible to implement
> text mode or sprites with different microcode instead of hardwired hardwa=
re
> and it would need less block RAM.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
tems.de

cheer up!
great!

dont get upset on replies, most of us have not made a grpachical
controller
with hardware accelerated features in 3 days!

I havent.
MOST of the readers havent.
except YOU :)

the double RAM requirement is kinda nasty of course
its always too little of them, well Altera has more than X in low cost
families, hum, but i have no cyclone3s :(

Antti

Antti.Lukats@googlemail.com wrote:

> cheer up!
> great!
> 
> dont get upset on replies, most of us have not made a grpachical
> controller
> with hardware accelerated features in 3 days!
> 
> I havent.
> MOST of the readers havent.
> except YOU :)

Thanks! I'm not getting upset. Maybe Nico has some good ideas he wants to
show me with the V9938. Do you have a link to VHDL source code for it?

> the double RAM requirement is kinda nasty of course
> its always too little of them, well Altera has more than X in low cost
> families, hum, but i have no cyclone3s :(

Yes, this is the main drawback. But this was the reason why it was so easy
to implement it: One exclusive read path for the graphics output, and one
read/write path for the accelerator, all clocked with the pixel clock. The
generic bit depth of the RAM is equal to the pixel depth. And I wrote
already the VGA output some years ago in Verilog (but I rewrote it for the
VHDL implementation, because the code was too messy). Bitblitting and line
drawing is trivial with such a simple structure.

I think when I'll add SRAM, which would need caching, bus arbitration etc.,
and maybe register configurable bit depth, it will be a lot more complex.
Maybe I can avoid some of the complexity with a microcode architecture, or
at least reduce the turnaround time for testing new code.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de