OK. I think we have a solution for the 2000 & 040 & Picasso II
problem. What I'm going to propose works at least for 2000 & Zeus &
Picasso.

Markus:
> Yes 64K, and by adding 0xfff (not 0xffff as stated in the doc) you will
>get a byte-swapped address after it was passed through the 040 to Zorro
>interface.  Call that black magic :-)

Mighty weird definition for byte swapping. For example 0x3c9+0xfff ==
0x13c8. But my Zeus is pretty weird in other ways also - it won't work
at 28MHz (the clock rate it was shipped with), but works OK at 25MHz
and also at 33MHz (with extra cooling :)

But anyway - to which addresses should this offset be applied?
Apparently not to all register addresses as the driver is almost
working without the offset. Well - according to my experimentation, it
should be applied to VDAC_DATA. Nowhere else as far as I can tell.

So here's a patch to try with the current grfcl:

*** grf_clreg.h~	Tue Apr 25 13:16:04 1995
--- grf_clreg.h	Mon Jun 12 10:07:29 1995
***************
*** 261,267 ****
  #define VDAC_ADDRESS_W		0x03c8
  #define VDAC_ADDRESS_R		0x03c7
  #define VDAC_STATE		0x03c7
! #define VDAC_DATA		0x03c9
  #define VDAC_MASK		0x03c6
  #define HDR			0x03c6	/* Hidden DAC register, 4 reads to access */
  
--- 261,269 ----
  #define VDAC_ADDRESS_W		0x03c8
  #define VDAC_ADDRESS_R		0x03c7
  #define VDAC_STATE		0x03c7
! extern int cpu040, cltype;
! #define VDAC_DATA		((cpu040 && cltype == PICASSO) \
!                                  ? (0x03c9 + 0xfff) : 0x03c9)
  #define VDAC_MASK		0x03c6
  #define HDR			0x03c6	/* Hidden DAC register, 4 reads to access */
  
If there are 040 boards for 2000 which work OK without the kludge, we
should come up with something else that cpu040 of course.

>> #if 1
[..]
>> #endif
[..]
> Interesting piece of code.  Did you set "1" to something?  Is the compiler
>supposed to use the stuff inside the if-endif?

Umm.. are you joking again the way you were when you asked "what's
emacs?"? It's an ordinary #if check. As one is the boolean true for C,
the code is compiled.

>For I believe a black
>screen means:  not initialized at all and a white screen:  not initialized
>correctly, you seem to be on the right trace.

The problem is apparently colormap initialization. For some reason
VDAC_DATA appears at address base+0x13c8 instead of base+0x3c9. At
least for writing. I haven't checked reading. The reason why I was
able to see something was the fact that the framebuffer went to 15/8
mode.

>> Are the sources for the various X servers available from somewhere?
>
>You don't need them?!

Oh? I would like to take a look at the sources. To educate myself if
nothing else. And having the sources available at some FTP site
reduces the risk of them getting lost the way DaggeX for AmigaDOS did :(