Hello everyone,

So, frustrated with the dumb frame buffer I set to work a long ago to
convert from the Xfree86 s3_virge driver a working CV3D driver for
NetBSD/Amiga X, pretty much the same way as CV driver was done. I modelled
my work closely after the CV driver and, well, finally maybe a week ago I
was able to build Xamiga executable with CV3D support.

Oh, of course it didn't work.

I've now spent endless hours trying to find out what is wrong. I wanted to
come out with finished, working product, but seems I can't do that...

What I have at the moment is a shakily working implementation of CopyArea,
and a few friends. I have the same accelerated functions as the CV driver
has but I had to throw FONTCACHE and many others away, since they completely
failed to work. Only CopyArea and CopyPlane (and that calls always cfb
function) work,
And even with them the X does not always draw everything correctly or at
all.

So, help, please. I have a few questions and I'll today or maybe tomorrow
throw necessary diffs and the s3v files to my web page for better gurus to
hack at and other people to try.

Questions:

1.	Why indeed the kernel driver gave access to the hardware register
from the position it did. There was no way to access ImageTransfer, because
it was below the start of the register area? (I had to change the kernel
driver, too, now it gives access to the area 500 0000 - 500 ffff, instead of
500 8000 + 64*1024 bytes, from the point of view of the CV3D board.) My
problem here was, that I was trying to make the FontCache work and there the
ImageTransfer was used. Amazingly, once I hacked the kernel so that I could
use the ImageTransfer area the FontCache code completely locked the X server
and nothing worked at all (the font transfer idea: set up blitting
registers, move data to imagetransfer, wait, reset blitter to CMD_NOP. If
nothing is moved to ImageTransfer there I don't see fonts but otherwise
everything works, if I move to ImageTransfer the WaitIdle() locks).
2.	Because for example Line drawing does not seem to work at all and
the blitting functions are very shaky (PolyFillRect fills not even the
damnest thing) I suspect two things: a) kernel driver sets the board and gfx
chip in such a way, that not all the available functions will work. I tried
looking into the Xfree86 code and see if things were done differentely
there: they were but with my knowledge of gfx chips I didn't understand a
thing :-( b) I also suspect that the problem maybe caching (I run 68040).
Could it be so that some/much/all of the data depending on the situation I
write to Virge hangs around in the CPU caches? I tell virge to clip here and
blit here and tell it to blit, and the blit area still gathers dust in the
CPU and Virge thinks I'm crazy? Could this be, and how to disable caches or
set them to write-through (in kernel? With some kernel call outside kernel?)

So, anyone knowledgeable, please help. I grew tired of not knowing
anything...

And to wrap up, what do I see on screen: hardware cursor works, images, such
as icons, are drawn correctly, I can see windows with borders, move them
around, scroll xterm, do things etc. Only 8bpp tested. And this is just with
FillSpans, CopyArea and CopyPlane, backing store and CopyWindow accelerators
in use. If I use polyfillrect all sorts of fills are not done at all, font
caching locks up the whole thing...

And, once I put the files available (also the patched kernel driver) please
understand that I got into this thing knowing NOTHING about X or about Virge
for that matter. Considering, I've made good progress. (But as a Finnish
sports commentator said in hockey world championship games: that was almost
there, but almost doesn't count!)

Arto Huusko

 Ah, I really love writing my E-Mail with Exchange. You decide if there is a
joke somewhere here...