Another jaguar bug?

[Welshworrier]

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

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 December 29, 2020 by Welshworrier

[LinkoVitch]

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

[swapd0]

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.

 

[Zerosquare]

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:

[swapd0]

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.

[LinkoVitch]

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)

[dilinger]

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.

[matmook]

Ohh I did not have this version, only the v8 one.

The file could be found there: http://www.larshannig.com/jag_dev_manual.php

Edited December 29, 2020 by matmook
Typo

[Seedy1812]

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

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;