*BOGGLE* This is cooler than liquid helium. :)
I have pondered things like this too, and I would really like to do it this way, because it makes for more things for hackers to play with. Ok, there are three ways (that I can think of right off) to go about this, in terms of how to emulate VGA. First of all, the common thing is that we need to have the bitmaps and text buffer/font stored in graphics memory and readable. Doing that won't be hard. The question is how we turn that into an image. One is to have the video controller do it, but that's the thing I would like to avoid, especially if it saves logic. Interesting approach #1: Periodically, scan the VGA data and translate/scale it to another buffer that is read by the video contoller. Interesting approach #2: Catch writes to VGA memory and convert them immediately. Each one has advantages, although #1 has the advantage that if it's really slow, it doesn't slow down the host's ability to get data there, it won't hold up the bus, and it won't lose any events. BTW, scaling is okay, but I consider it to be optional. Plenty of notebook computers center the text display on the screen, rather than scaling to the full resolution. As long as it's readable, why care? Even centering is optional. On 5/1/05, Viktor Pracht <[EMAIL PROTECTED]> wrote: > Hi all, > > I thought a bit about the VGA controller, and here are the results: > > The design goal is to implement a VGA controller with as little hardware as > possible. Since this won't be a standalone controller, we should use the > existing 3D pipeline, video controller and RAM. The most obviously useful > part is the video controller: if we somehow manage to get the VGA image into > a 32 bpp framebuffer, then we don't have to worry about timings or any > real-time aspects at all (we're doing VGA for compatibility, not for speed). > The second obvious part is the RAM, which should be used as VGA RAM and as > framebuffer for the video controller. With 256 KB of VGA RAM + 800*600*4 > bytes of framebuffer, we're using less than 2% of the available 128MB. > > The traditional way to reduce hardware usage is to replace the hardware with > a smaller CPU + ROM (see PICs, microcoded CPUs). Since we have lots of RAM, > the CPU can be pretty small. Attached is the smallest design I could come up > with. For every read or write to a mapped I/O or memory address, the CPU > executes a program from a fixed address (the methods in(), out(), read() and > write()). The execution stops when the last instruction doesn't have the > MASK_NEXT bit set. There are 2 registers: A[ddress] and V[alue]. They are > used as input to the executed program, and V is also used as output of > read() and in(). As the absolute minimum, we need 4 instructions: > - FETCH reads a byte from RAM into V. > - STORE writes a byte from V into RAM. > - JUMP performs an unconditional branch. > - 3D sends the contents of V to the rest of the chip as if it were a byte > from a privileged DMA stream. We already decided to have an I/O interface > for that, hopefully it can be reused here. It will be used to setup > resolutions and timings. Maybe for bitblts in text mode. > > The fun starts with the address modes: the address for a read, write or jump > is a combination of a 27 bit immediate operand and the two registers A and > V. Bits 7-0 of the operand can be replaced with contents of V and bits 23-8 > can be replaced with contents of A. This allows to use the FETCH instruction > and big chunks of RAM to perform following calculations: > > MASK_USE_V | OP_FETCH: a 256 bytes block of RAM is used as a function that > takes V as parameter and places the result in V. > > MASK_USE_A | OP_FETCH: a 16 MB block of RAM is used as up to 256 different > functions that take A as parameter and place the result in V. > > MASK_USA_A | MASK_USE_V | OP_FETCH: a 16 MB block of RAM is used as a > function that takes A and V as arguments and places the result in V. > > We have a total of 7 16 MB blocks at out disposal. (The 8th block is used > for framebuffers, VGA RAM, smaller lookup tables and code.) That should be > enough to implement the whole VGA functionality. If we allow a backdoor for > arbitrary writes to RAM, then it's even runtime-hackable, which can be used > to emulate any kind of old video hardware. > > The attached files are an abstract C++ class implementing the hardware only. > Subclasses are supposed to implement the methods write_3d() and draw(). As > minimum functionality, write_3d() must remember the video settings > (framebuffer position and dimensions etc.) and draw() must update the real > output with the contents of the framebuffer. Also, the subclasses are > supposed to initialize the RAM with something useful. The four entry points > CODE_* should be filled with JUMP instructions to the actual code. > > Next weekend, I'll try to program this thing. > Does anybody know any professional BrainFuck programmers? ;) > > - Viktor Pracht > > -- > +++ Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
