On 2002.05.05 19:41 Frank C. Earl wrote:
...
I plan to build a test case for this, but I would like to hear
preliminary
opinions about this, in case I'm missing something. Frank, have you
tested
this before?
Yes, pretty extensively, but I didn't have time to set up tests for
On Friday 03 May 2002 11:08 am, you wrote:
I think the reason for the alias is that the card increments the
GUI_TABLE_ADDR @ BM_GUI_TABLE as it consumes descriptors, so writing to
BM_GUI_TABLE could disrupt a DMA pass in progress. Using the alias
ensures that the commands already in the
On Friday 03 May 2002 09:49 am, you wrote:
As I was studying the specs and code to be able to understand and reply to
Leif's previous post (which I haven't completed yet..), I noticed at the
same time a bug and a feature which could mean that blind client buffering
could be insecure after
As I was studying the specs and code to be able to understand and reply to
Leif's previous post (which I haven't completed yet..), I noticed at the
same time a bug and a feature which could mean that blind client buffering
could be insecure after all.
The bug is that we should be using
On Fri, 3 May 2002, José Fonseca wrote:
As I was studying the specs and code to be able to understand and reply to
Leif's previous post (which I haven't completed yet..), I noticed at the
same time a bug and a feature which could mean that blind client buffering
could be insecure after
On 2002.05.03 17:08 Leif Delgass wrote:
On Fri, 3 May 2002, José Fonseca wrote:
As I was studying the specs and code to be able to understand and reply
to
Leif's previous post (which I haven't completed yet..), I noticed at
the
same time a bug and a feature which could mean that blind
On Fri, 2002-05-03 at 18:08, Leif Delgass wrote:
On Fri, 3 May 2002, José Fonseca wrote:
btw, I also noticed that HOST_CNTL has a bit for big-endian translation of
host data. At 15 and 16bpp, it swaps bytes within each word and at 32bpp
it reverses the order of the 4 bytes within each
