Timothy Normand Miller wrote:
On Wed, Sep 24, 2008 at 4:44 AM, Mark Marshall
<[EMAIL PROTECTED]> wrote:
Timothy Normand Miller wrote:
This is ready for an initial release.
unsigned int s3_memory[258048];
This array isn't big enough (and seg-faults on my box).
This is the minimum:
unsigned int s3_memory[2048+640*480];
Odd. The display is only 640x400.
Hi.
The problem was that the routine that passed the completed bitmap to X
used a height of 480.
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.
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.
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?
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).
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.
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?
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?
(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?)
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? Do we think
that we can get mode-X programs working eventually? We could make a
decision that any program that plays with the CRT registers isn't
supported, but this seems overly restrictive. 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.
I'll try to post a bochs diff if people are interested, but it will be
tomorrow.
MM
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
