Jump to content
swapd0

Another jaguar bug?

Recommended Posts

1 hour ago, LinkoVitch said:

IIRC with pointer maths (it's been a while :) ) but whilst a pointer is itself 32bit, an increment with ++ will increment the pointer by it's type size (assuming it's a typed pointer).  So a Uint16_t* will increase by 2 bytes irrespective of if the pointer itself is 32 or 64bit.

 

I *think* that's correct :D

That's correct *but* when it's assigned the initial value in this code:

volatile uint16_t *clut = (uint16_t *)CLUT + index;

it's an addition of a 16 bit (index) to 32 (CLUT)

 

Edited by Welshworrier

Share this post


Link to post
Share on other sites
2 minutes ago, Welshworrier said:

That's correct *but* when it's assigned the initial value in this code:

volatile uint16_t *clut = (uint16_t *)CLUT + index;

it's an addition of a 16 bit (index) to 32 (CLUT)

 

I don't think that should matter?  It is adding a 16bit to a 32bit value, but the point of the addition CLUT is a value (I am assuming it is a #define for the CLUT memory address?) the result of the addition of a 32bit and 16bit values is then cast to a uint16_t pointer, so the addition is made prior to it becoming a pointer.

 

Well, that's how I read it :)

Share this post


Link to post
Share on other sites

CLUT it's taken from jaguar.h, it's defined like this, by the way I think that it should be a short * or int16_t*

 

#define BASE 0xF00000 /* TOM Internal Register Base */

#define CLUT  (long *)(BASE+0x400) /* Color Lookup Table */

 

Anyway, it doesn't matter if the addition it's with a 16bit integer or a 32bits integer because there are no overflow. The palette is written by the 68000.

 

The values that I shown before was the ones that I wrote to the CLUT, the source palette or *color values if you like, I didn't read the CLUT. Later I can try to compare each write with the source value and log if there are a different value.

 

Share this post


Link to post
Share on other sites

I'm pretty sure LinkoVitch's interpretation of the pointer rules is correct, and that it's not where the problem is.

 

The documentation has an interesting paragraph about the CLUT:

image.thumb.png.a8bab654c16dde7c3912205e88b8037a.png

  • Like 2

Share this post


Link to post
Share on other sites

My Jaguar doc don't have the last sentence, and I have some objects with the release bit. That's the problem for sure, and why it works if I change  CLUT into the vbl irq.

Share this post


Link to post
Share on other sites

I've just checked the 3 versions I have of the Jag Tech Ref.  ONLY the printed copy I have that came with my Alpine has that line in! The PDF scan and the V8 ref don't have it!!  (My printed copy is dated June 7, 1995).  Is there a PDF (preferably OCR'd version of this out there, or should I look to fire up the scanner?  I'd rather not as I have had it spiral bound and that might be a right pain to reset)

Share this post


Link to post
Share on other sites
42 minutes ago, LinkoVitch said:

I've just checked the 3 versions I have of the Jag Tech Ref.  ONLY the printed copy I have that came with my Alpine has that line in! The PDF scan and the V8 ref don't have it!!  (My printed copy is dated June 7, 1995).  Is there a PDF (preferably OCR'd version of this out there, or should I look to fire up the scanner?  I'd rather not as I have had it spiral bound and that might be a right pain to reset)

A Version 2.4 (June 7, 1995) exists in a scanned form and break into small PDF files.

I remember the filename is "jaguar_dev_manual.zip" but I do not remember where I find it.

Share this post


Link to post
Share on other sites
On 12/29/2020 at 4:20 PM, LinkoVitch said:

IIRC with pointer maths (it's been a while :) ) but whilst a pointer is itself 32bit, an increment with ++ will increment the pointer by it's type size (assuming it's a typed pointer).  So a Uint16_t* will increase by 2 bytes irrespective of if the pointer itself is 32 or 64bit.

 

I *think* that's correct :D

That is correct , both address1 and 2 will point to the same entry / memory location

 

uint16 array[256];

uint16 *address1 = &array[index];

 

uint16 *first = &array[0];
uint16 *address2 = first + index;

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...