On 5/1/05, Patrick McNamara <[EMAIL PROTECTED]> wrote: > > > >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. > > > > > > > Yes, I have considered this as well, and I think it is quite workable, > 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. > > >>One 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? > > > > > > > We can fake it, but we have to fake it correctly and give the same > 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. 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? > >>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. > > >But, 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 > > > > > > > Pretty simple, now consider what happens if the next write to memory > 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. > > >Dealing 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 > > > > > > > The idea of having a nanocontroller of some sort seems like the right > 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)
