Hi Dave,
> This was one of the ideas Gavin Nichol and I thought about earlier on this
> year - we actually thought it was a good way to go although it sacrifices a
> fair amount of performance. When I actually came to start work on the
> bitblt code though I found that as we only blitted data onto the screen and
> did all of the raster ops in system RAM it wasn't too much of a problem to
> just do the bank switching as we transfered the blt buffers to the video RAM.
> FWIW I think that using a flat space would be a neater solution as most new
> devices allow a flat linear mapping anyway :-)
Our video cards which are QVision compatible can do this. You can map the
frame buffer to between 1Meg and 4Gig on 1Meg boundaries. I may actually
look at doing this. What I'm playing with is for my own amusement and
isn't intended to be distributed, so I don't mind introducing hardware
dependencies at the lowest level.
A question though. Enabling the hardware is a piece of cake. A few bits
get toggled and everything is set. Can I then just mmap the address that
I mapped the frame buffer to or do I also need to notify the memory manager
of the range I'm using? Or is this a stupid question and mmap does that
for me? My problem is that I have a mainly DOS background where I can
do whatever the hell I want.
> I wouldn't have thought anyone else will have implemented this as it
> requires the intervention of the kernel page handler. I just took a quick
> look at the code and I'm pretty sure there's no mechanism there for a
> user-installed page fault handler (eg no way to tell the faulting process
> where we faulted, etc).
That's what I was worried about.
thanks,
eddie
-- .__o Ed McCreary "The Information Superhighway, sanitized _-\ <,- Compaq Computers for your protection." (*)/ (*) edm@twisto.compaq.comReceived on Wed Nov 23 11:47:26 1994
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:10 PDT