After getting the VGA to work I've started to come up with a plan to
created a device that would show wither shapes or images to the screen.
I've decided that all the objects would exist as data on BRAM
At first I thought of using a "pixel matrix" which was a 640 by 480
std_logic_vector. It was huge and synthesis too an extremely long
time. I am not sure how long it would have taken because I did not
let it finish. After 2 hours of letting it freeze and go. I had to quit it.
If it was this complicated for the machine then it means I am doing
something really inefficient.
So then I thought of using bram. I was hesitant because i remembered
that memory took a long time to synthesis too. But BOY was a wrong.
It only took a few minutes to synthesize a memory of my choosing.
first I made a a bram 1 by 307200. It worked but this method would
only allow black and white. I tried 8 by 307200 , but unfortunately
I hit my constraint. There wasn't enough ram in my device to do this.
Several ideas bounced around in my head. maybe i could use some sort
of mux that would play with an FPGA object.
I scrapped that idea because it would lead to something rigid. If I
wanted to add shapes via UART, then I would need to think of a
different plan.
The new plan was to get rid of the pixel matrix idea. The idea was
to use opcodes to specify what shape it was or what image it was.
It would include the coordinates, the dimensions and/or some other pixel
data. The rest of it would be generated by the fpga using a fancy
algorithm. An algorithm that I haven't thought of at this moment.
There are two categories, shapes and images. Images take up quite a lot of
space because each pixel needs to be accounted for. Shapes don't take up
much space at all. A square would probably take at most two words
to describe.
The header for both would have the same format. The opcode would
differ in order to tell the control what it is dealing with.
Below is a pictorial version of what I am talking about:
| upper left corner |
opcode | scale | rotate | x coord | y coord |
4 bit | 3 bits | 5 bits | 10 bits | 10 bits |
A header would be one word and would contain the upper left corner,
the rotation factor and the scale factor. These three pieces of information
are extremely value able and would be used in the matrix transformations.
These three pieces would have to affect the pixel data what would come
after it. Remember how I said that a square would take as little as two
lines? well the next line would be its pixel data. One way i can do it
is by specifying the width and the height. However, if I want a shape
that is more custom I would have to specify the coordinates of the points.
Here is a new idea that might be better.
What if I wanted to make a parallelogram? The width and the height
would be used to set the dimensions of the "plate" that the shape
will be on. The points would exist in relation to the "plate"
if it was a 10 by 10 plate then I would specify the points as if I was
drawing on a 10 by 10 grid.
ie. a triangle on the 10 by 10 grid p1(2, 4) p2(0,10) p3(10,10)
When I move the triangle all I have to do is move the plate. the points
would not have to change. They are in relation to the plate, so if the plate
moves, the points move with it. Everything would be in relation to that
upper left corner. So theoretically, I should be able to rotate everything
and scale it.
images would be a similar story.except that all the pixels of the image would
be considered a point. it would be a point on the "plate". the points
would exist in relation to the upper left corner. The side effect is that they
take up a lot of space.
in order to deal with this i needs to separate the shapes from the
images. the images would have a larger page and the shapes would
have a smaller page.
I believe the limit is 900000 bits so i have to divide it up in a way that
can help share the ram.
for shapes
32*(8)*(2**6) = (wordsize)(shape _lines)(shape pages)
each word is 32 bits. the number of lines it is allowed is 8. the number
of pages allowed is 64. that would take 16k bits.
for images
32*(2**10)*(2**3) = (word size)(image_lines)(image pages)
each word is 32 bits. The number of lines it is allowed is 1024.
The number of pages allowed is 8. That would take about 262144 bits
======
before i forget, the line right after the header should be about the
dimension of the plate. it will always be a rectangle.
So tell me again about how the pixel data is suppose to look like?
I have two choices
choice 1
opcode | color | relative x | relative y |
4 bits | 8 bits | 10 bits | 10 bits |
choice 2
opcode | | color | | color | | color |
4 bits | 2 | 8 bits | 1| 8 bits | 1 | 8 bits |
choice two would be ideal for space saving. It might be good
for images. It would be as if I am naming each color of pixel
from left to right; top to bottom.
The first choice would name a spot on the plate to color.
This would be best for shapes. but it can also be used for images.
This would be a good choice because everything would be similar
and require less components to decipher it. it also brings ups the
possibility of shading it in a polygons.
=====
Eventually I'll have to decide on which one to pick in order flesh everything out.
Once I have it I can start fleshing out the components that I will need in order to make this dream a reality. Gosh, I never thought I'd be diving in to operating system concepts
just to do this. I'm glad that i am thought. It makes me think
as a computer scientist. I'm glad that this very important class
is coming back up. It lets me practice the idea of paging.
HA! maybe this is a step toward making an of run onto of the
FPGA after i get a cpu to start running on it. I could probably use
the BOOK's code and from there I dunno I haven't thought that
far out.
No comments:
Post a Comment