On Sunday 25 June 2006 10:13, John Culp wrote: > I've finally completed a quick-n-dirty EPP driven framebuffer. The full > design, Linux driver code, design documents, and some misc pictures are > posted at www.johnculp.net. This is a new hosting account, so DNS may > or may not resolve. Also try http://0087a8d.netsolhost.com/. I am > placing everything in the public domain. >
Hey cool. Hardware & all. very nice. > This design takes up about 42% of a Xilinx spartan XC2S200E FPGA and is > currently driven by a 50Mhz clock. I don't think reaching 100Mhz is out > of the question, but this was not a design goal. > > If I had the time to work more on this in the short term I would: > > Fix the display bugs. Row 0 of the framebuffer is displayed near the end > of the screen?! The display then wraps over and looks almost normal. > There is also some misc trash on the screen that I have not tracked down. > > Fix whatever bug exists in writing single pixels, the problem is seen in > the line drawing picture on the diagonal lines. > > Improve the EPP performance. This would be a half hardware/half > software solution. > > Implement Bresenham's Algorithm in hardware. > I've been posting one to the list with improvements as I learn more about verilog. The thing it doesn't do is actually render pixels. I'll pull your code & see about integrating my bresline module into your design & see how far I get. > Modify the MCU to provide pixel read/modify/write operations for Memory > Users and to add unaligned accesses. (probably the toughest improvement) > Why bother with unaligned accesses? (I take it you mean the host CPU reading a byte/word at an odd address. > Add block fill. > > Add a hardware cursor. > > Add a bit-blit. > OK... I'll pick up some of that, just to learn more about verilog (Even if noone else likes my code :) > None of the above are very difficult modifications, I think another > month of work would do it, but I do not have the time right now. After > the above changes, I think re-targeting it to a PCI/PCI-Express board > would not be difficult and would result in a pretty competent 2D solution. > > I think a full 3D (depth buffering and texture mapping) core could fit > ?easily? in a webpack supported FPGA. Performance (of everything) > pretty much depends on available memory bandwidth. This is probably > another 3-4 months of work. > > In an ideal world other folks would pick this code up and retarget it to > other dev kits (preferably with sdram on board) with other types of > computer connections. As I've said before I am a ME, not an EE, so to > do this I've had to (partly) learn VHDL over the past few weeks. This > is by far the most complex digital design I've done, and beyond flashing > a LED a few years ago, this is the first successful FPGA project I've > implemented. > Hmm... I'd love to have a devkit. Not sure I could afford one though, I'm saving (OK, my company is saving :) for an OGD1 board when they roll out the door. Hamish.
pgp8ylrYBa6PQ.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
