Subject: Re: Colour X server for AGA/ECS
To: Gary Henderson <firstname.lastname@example.org>
From: Eduardo E. Horvath email@example.com <firstname.lastname@example.org>
Date: 01/27/1995 09:08:21
On Fri, 27 Jan 1995, Gary Henderson wrote:
> I'm working on a colour X server for X11R6. I've ported X servers to other
> hardware platforms before but don't know a great deal about the amiga custom
> hardware. In my quest to get the thing running at reasonable speeds when
> using deep displays, I have a few questions:
> i) Is it worth investing any effort in trying to use the blitter or can 68030
> perform the same area copying/filling operations faster ?
Depends on the operation. Pure unshifted copying can be done faster with
the CPU. The advantage of the blitter is the barrel shifter, three
source inputs, full combinatorial logic, parallel processing, and
hardware line draw/area fill.
> ii) Does the blotter only operate on a single plane at a time, so to copy
> an 8 bit deep image around on the screen the blitter copy operation would
> have to be performed 8 times ?
> iii) Is anyone working on a device driver for the blitter ?
Yes, and it works rather well except for some wild pointer that
periodically seems to stomp on some of the blitter registers.
> iv) Server performance can be boosted somewhat by using a sprite for the mouse
> pointer rather than using the server's internal software pointer code. Is
> there currently any way to get a sprite on the screen and move it around
> from a process or is a new device driver required? Would a kernel-loadable
> do the trick, and if so, anyone volunteering to write one ?
The problem with the Amiga sprites is that (at least under ECS) they are
lo-res only and therefore do not have the accuracy most X applications
expect. Most of the stubs for sprites seem to be in the kernel already.
> I thought trying to mmap the sprite control registers into server address
> space but a forest fire of flames would ensue if anyone else saw the code !
First of all, all of the CC registers are in the same area so if you
write to or even read from the wrong address you can blow away the
kernel. Secondly, as I stated previously, we already seem to have a wild
pointer in the kernel, so if you're not careful your blits can go wild
and trash all of chip RAM.