I was having a chat with Timothy this evening on the IRC channel and we
were discussion the VGA core design. In an effort to get many eyes, and
to make sure other people have the info too, I figured it would just be
easiest to dump the chat IRC transcript directly and send it out to the
list. So, here it is, unedited even for typos.
Patrick M
-----
<SecretSquirrel> Here is an FPGA question for you...
<SecretSquirrel> How complex would it be to implement using a register
as lookup into card memory for reads and writes?
<SecretSquirrel> logically something like this:
<SecretSquirrel> host write: CARDMEMPTR=(BASEPTR & 0xF0) + REG_VALUE
<SecretSquirrel> or something like that.
<SecretSquirrel> I'm puzzling over how to implement the VGA read and
write pipes.
<SecretSquirrel> It is a pipelined system that will need to read and act
on various register contents.
<SecretSquirrel> I keep wanting to do it as a nanocontroller, but I
don't know whether that would take more or less gate realestate
<SecretSquirrel> than just implementing the pipeline stages and muxes
--> voosuz_ ([EMAIL PROTECTED]) has joined #opengraphics
<-- voosuz has quit (Read error: 60 (Operation timed out))
--- voosuz_ is now known as voosuz
<SecretSquirrel> MMMmmmm..... pointers to pointers to dynamically
allocated objects. Gotta love it.
<theosib> I have a feeling that just implementing the VGA controller
directly would be best. Of course, it won't be efficient, and we still
need to do the translation to pixels the video controller can handle,
but as for the interface to the host...
<SecretSquirrel> Alright. Then is it better to try and use card memory
for the registe arrays or to define them as an actual array of registers
in the FPGA
<theosib> Well, how many have to be used at any one time? And how many
are there?
<SecretSquirrel> for example the CRTC registers are actually 32, one for
addressing and 31 that are written to based on the address register when
you write to the CRTC data IO port
<theosib> Hey, I gotta run. I don't think it'll be that many, but I
need to know more about the nature of the pipeline first.
<SecretSquirrel> Later. If you could the DAC palette registers (of
which there are 768) you are over 840.
<SecretSquirrel> 864 total, including the pallete.
<SecretSquirrel> of that, 11 are direct access registers (either used
for as addresses or bitmaps)
<SecretSquirrel> 768 are the palette entries (256 entries x R G B)
<SecretSquirrel> That leaves 85 other registers that are access via a
single data port with an associated address register.
<theosib> Palette may be best stored in RAM, in part because there has
to be some sort of processor to do the translation anyhow.
<SecretSquirrel> so much for being gone. :) I wasn't expecting a
response, just musing.... But the you're right, the palette is
certainly a good candidate.
<theosib> I am back for about 5 minutes. :)
<SecretSquirrel> I was wrong, there are only 24 CRTC registers
<SecretSquirrel> I think the CRTC registers are also a good RAM
candidate as they are only used (by us) during the generation of the
video frame.
<SecretSquirrel> Things like what line the cursor begins and ends on,
what line the underline starts on, etc.
<theosib> I've got to put some thought into it. There's the host
interface, and there's some logic that lets the host interface talk
directly to graphics memory. I could insert the VGA logic in between
there so that it does translations of addresses to put/get registers.
If some are shadowed in the chip because they're really important,
that'll be okay.
<theosib> We still need some sort of processor to read video parameters
and perform the translation.
<SecretSquirrel> Some will have to be if we implement an actual VGA
pipeline for reads and writes.
<SecretSquirrel> Yes, I think the processor idea for generating the data
for the 3d pipe is a great idea.
<SecretSquirrel> BTW, this is what the pipeline looks like for write
mode 3: http://www.supersecret.org/images/VGA_pipe_3.png
<SecretSquirrel> I don't have which registers the fields come from on
the image yet.
<SecretSquirrel> and here is write mode 0:
http://www.supersecret.org/images/VGA_pipe_0.png
<theosib> Forget the 3D pipeline. It would be must simpler to just
write code to perform the translation direct to pixels.
<SecretSquirrel> If the nanoprocessor is allowed to write directly to
the framebuffer, then it's possible.
<theosib> Cool diagrams. I don't understand them just yet, but cool
diagrams. :) I'll have to look at them carefully later. NOW, I
REALLY need to bolt. :)
<SecretSquirrel> However, then the nanoprocess must know things about
the screen size. I was thinking along the lines of the nano pr....
<theosib> I want to have VGA working before the 3D engine is in anyway.
<SecretSquirrel> later. I'll continue my thoughts
<SecretSquirrel> I was thinking along the lines of the nano processor
converting the VGA buffer to texture memory, then submitting a "draw
rectangle" command with the texture being the translated VGA buffer
contents.
<SecretSquirrel> The nanoprocessor still has to know what the VGA screen
size is suppose to be, so it can properly define the rectangle and the
texuture coords.
<SecretSquirrel> However, it doesn't have to do any math beyond the
translation.
<SecretSquirrel> Though as I think about it, it shouldn't be any
different writing directly to the framebuffer either.
<SecretSquirrel> It just defines the screen size to the video controller
which then interprets the frame buffer accordingly.
<SecretSquirrel> So, we should be able to do the VGA without needing the
3d pipe.
<SecretSquirrel> See, talking to one's self does help.
<SecretSquirrel> As an interesting aside, one the 3d pipe is working, an
alternate nanocontroller program could be uploaded that only translated
the VGA buffer to texture memory. The host could then theoretically
apply this texture to anything in a 3d scene. You could have a 3d
spinning cube that had a side that was a completely dynamic VGA display
at almost no overhead to the host CPU.
<SecretSquirrel> Totaly pointless, but really cool.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
