Timothy Miller wrote:
Hrm, if programs think we meet the spec, doesn't that mean we do, at least in some manner? :)On 5/1/05, Patrick McNamara <[EMAIL PROTECTED]> wrote:
Yes, I have considered this as well, and I think it is quite workable,The idea I have in mind is to point the memory apertures at raw graphics memory. The reads and writes are, therefore, always valid. Then the emulator reads the VGA data and translates it to a viewable framebuffer that the host doesn't know about.
though I think (think mind you) it would be atrociously slow. While
speed isn't our goal here, we do want it to perform reasonable well.
It's not going to be any slower than any other PIO access to memory, which really isn't all that slow. Also, even if it's slow, we simply don't care. But it's not slow. Mind you, it won't be as fast as TROZ, but TROZ was optimized to do PIO memory accesses very efficiently.
We can fake it, but we have to fake it correctly and give the sameOne thing I am pretty sure about though. We have to care about timings and such. The VGA cards are desinged to give the programmer direct access to all manner of the internal hardware and do whatever they want with it.
Can we fake it? Let's say they want access to a "current scanline" number. What if we lie? Who cares?
results under the same conditions and those results have to meet the VGA
spec or at least the expected results from a real VGA card.
We're not trying to meet the VGA spec. We're tying to FAKE meeting
the VGA spec well enough that (a) programs think we meet the spec, and
(b) you see basically what you're supposed to see.
I was taking the "it just works" approach. If we really aren't that worried about VGA compatibility the we can cut corners with a lot of the VGA control registers. They won't necessarily have a lot of meaning. We just need to make sure they are initialized to a valid valid when we switch modes and then we can pretty much ignore what is written to them so long as we return it for any subsequent reads.
I haven't read the VESA specs yet so I don't know what they say about such stuff, but how my effort do we want to put into conforming to them?
So, if some DOS-based game doesn't sync to frames correctly... well, what the heck are you doing running DOS-based games on this thing anyhow?
People do some really strange things.
I do agree that we should re-use as much of the hardware as possible. We should certainly be able to user the video controller and all downstream hardware. And, I think with proper on the fly translation, perhaps using a microcontroller as described, we can use a 32bpp framebuffer and provide the neccessary emulated RAM buffers for the various VGA modes.
Here are some things we can use...
Look at the model in the Pattern2D section. There's a mechanism for loading a 32x32 stipple and then applying it to the drawing. When translating a charcter to pixels, we could read the character, then use that to decide where in the font to read, and then push that data down into the the Pattern2D unit.
I definitely think the text modes can be emulated and take advantage of the BitBlt hardware we have available. Viktor's "nanocontroller" concept is very useful here... And then I started thinking about this, perhaps the "dual buffer" concept works better here.... See notes below.
Pretty simple, now consider what happens if the next write to memoryBut, depending on how capable this nanocontroller is, we might be better off just giving it memory read and write instructions, with whatever else logic is necessary to make the translation.
Here's how to translate 80x25:
char_loop: - Compute character address - Read character and its color info - If it's blinking and it's the right part of the blink cycle, keep going, otherwise, do something else - From the character number, compute an offset into the font table - Add the font table offset - Also compute framebuffer offset for image font_loop: - Read a byte from the font - Iterate over the bits, selecting between foreground and background colors - Write pixels to framebuffer - continue with font_loop - continue with char_loop
happens while in the middle of the font loop. Using a "nanocontroller"
becomes problematic since you now have to support program interrupts.
Or, you have to have multiple nanocontroller cores, one which handles
incoming read and write requests and one which updates the frame buffer
from the VGA memory buffer. This is getting complex.
Next write to what? This isn't complicated at all. We expect that data will change in the middle of the loop. So what? So if the font table changes in the middle of using it, then for one frame, half a character isn't right. This is no different from any other VGA hardware. It's exactly what you'd expect.
No interrupts necessary.
And as I say, graphics memory reads are just like any other graphics
memory reads. The only problem is when someone reads a VGA control
register, and that's supposed to be dynamic. Again, I think we can
just fake it... either that or put in the hardware to provide the
correct result. Depends on what we need to produce.
Yeah, I was still in the dynamic translation mindset instead of buffer and transfer. In a buffer and transfer setup, we don't have to worry. The nanocontroller can run asynchronously to everything else and just translation the VGA memory space into the frame buffer.
I never have wrapped my head around FPGA internals. I'll let you experts handle that. I'll just keep tossing ideas out and seeing what sticks. :)
The idea of having a nanocontroller of some sort seems like the rightDealing with VGA 640x480x16 would be something like this:
- Compute VGA offsets - Read each of the four bitplanes for 32 pixels - Assemble pixels into 4-bit words - Look up colors in color table (could be in framebuffer!) - Write pixels to framebuffer - loop
idea to me, though I'm still not sure how we would go about it. The
main goal is to keep the gate/cell count to less than it would be just
to put a VGA core in place.
Well, what we're doing is trading off logic cells for memory cells. We'll design a minimalist processor and have it execute out of a RAM
block.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
