On Wed, Oct 1, 2008 at 6:57 AM, Mark Marshall <[EMAIL PROTECTED]> wrote: > The problem was that the routine that passed the completed bitmap to X used > a height of 480.
Ah. My mistake. > Anyway, I've been playing around with bochs. I've removed the standard VGA > emulator plugin and have started to write my own. It appears on the PCI bus > with the correct BAR's and I think I've emulated everything in the PCI > interface OK. I've dropped in you text converter code and written a whole > load of "glue". > > I am now back where I was last week. I can boot DOS and run most text > modes. Very nice! > I've needed to write quite a bit of C that I think will go in HQ eventually, > but I'm still not sure on how much hardware acceleration you are planning to > give HQ. I'm guessing that the code in poll_pci that decodes the IO reads > and writes will probably be over 500 instructions? I think adding some > hardware that decoded the register reads/writes and exposed the raw > registers to HQ would help a lot. While we can expand the program memory for HQ, I'm hoping that we can fit all of poll_pcI (which just forwards PCI access to memory) and the conversion code (we need a name for that) will fit into 512 instructions. When switching modes (say, to VGA 640x400x16), we can reload the whole program. But we may expand the program file just so we can load one program and go. > > I will try to post what I have, but I'm not sure of the format people would > like - I've made quite a few changes to bochs. How about a uni-diff from > the 2.3.7 release? I don't know. Bochs is Free Software, so theoretically, you could check in the whole thing, although I'm not sure if the mplayer people would appreciate you checking in that much code. :) What would be really cool is a script that would download bochs, download your patch, and apply the patch. Also, if any of your changes are more generally useful, see if the Bochs project would like to incorporate them. > Now for some specific questions? > > 1) > How many different HQ programs do you envisage? I suspect that three at > least would be OK (maybe a couple more). One for all text modes, one for > VBE modes (maybe more) and one for VGA graphics modes. Maybe if we get > round to doing all of the VGA graphics modes we will need different programs > for the very weird modes (the more CGA like ones). This is certainly one reasonable way of doing it. It's the way I had anticipated doing it anyhow, and being conservative about the number of instructions per program is probably a good idea. > It would be nicer if we only need one HQ program, but I think that might be > too big. > I'm currently working on the assumption that for the VGA modes we will have > only one video controller program. That will rasterize a 720x480 32-bpp > image. HQ will put the correct thing in the centre of this bitmap. Ultimately, it would be nice to find the native or preferred res of the monitor and use that. We could have HQ programs that know how to scale (by integer factors) text and graphics modes. > > 2) > How hard is the limit on the size of the HQ program. Would it be possible > to increase this? What is the reasoning behind it only being 512 words? 512 is the number of words in one static block RAM in the XP10. It seems to be a common size in general across FPGAs. I think the last ASIC I developed for used that size too. (To be precise, it's 18K bits, configurable to different widths and depths.) > > 3) > How should we map the VGA memory onto the S3 memory. If we want to emulate > the VGA properly I think that we should end up interleaving the four banks, > so each uint32 of S3 memory contained one octet from each bank. This makes > most operations much easier - especially with the graphics modes. If we > then treat the other address bits in the same way that the VGA does we end > up needing to read quite a bit more memory when building a text mode display > - is this going to be a problem? I presume you're talking about VGA planar 16-color graphics mode. It does sound like a sensible idea to interleave 32-bit words from each plane. That would make pci_poll only slightly more complicated (shift and add on the address) while simplifying the converter. If the planes were stored consecutively, that would simplify pci_poll, but then the converter would have to perform more complex fetches from memory to get good performance. > (In text mode, the characters are stored in plane 0. The even addresses are > used for the first n/2 pages and the odd addresses are used for the second > n/2 pages. If we use the scheme I suggest this means that the second > character is in the 8th octet of s3 memory?) We can customize the memory layout for the mode. pci_poll has complete control over how PCI addresses map to graphics memory addresses. For text mode, a flat format is probably simplest. For graphics, I think your idea of interleaving is best. > > 4) > How complete an emulation do we think we can get? I'm asking because I want > to know how many features I should be thinking about. For instance, do we > want to support 9 pixel wide characters? I don't think we should bother with that. > Do we think that we can get mode-X > programs working eventually? I'm sure we can, but this should not be a priority in the short term. > We could make a decision that any program that > plays with the CRT registers isn't supported, but this seems overly > restrictive. Accesses to CRT registers are handed off to HQ, which can deal with them however it wants. > On the other hand, programs that try to switch between text > mode and graphics mode are obviously broken, and I can see little point in > supporting them. The first priority is to be able to boot Linux. That means 80x25 text mode. Once a kernel graphical console kicks in, VGA is switched off and we're using a native driver. Even VESA isn't important. A later priority is to be able to boot Windows, if only as a baseline for minimal functionality. I think that means 80x25, 640x480x16, 320x480x256, and some VESA modes. > > > I'll try to post a bochs diff if people are interested, but it will be > tomorrow. Did you get an SVN account yet? -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
