Another jaguar bug?

[Another jaguar bug?]

I've included the log code and I get this, as you can see I upload the same palette for both images, but I get different result, the good one it's with the dark blue sky, the other one I got a black sky (sometimes with vertical blue lines WTF!?!?).

 

Sorry for the bad quality of the images.

first picture
palette 144 (16)
1302 0ac2 0c06 1f0e 472d def6 2608 2649 2fca 2f49 2588 c9b2 0081 09c2 1304 1c86 
palette 160 (16)
0000 0981 00c0 ffff 0040 12c1 1241 0000 f800 12c2 1302 cfc0 fe80 fc00 f800 f81f 

second picture
palette 144 (16)
1302 0ac2 0c06 1f0e 472d def6 2608 2649 2fca 2f49 2588 c9b2 0081 09c2 1304 1c86 
palette 160 (16)
0000 0981 00c0 ffff 0040 12c1 1241 0000 f800 12c2 1302 cfc0 fe80 fc00 f800 f81f

 

 

 

 

[Another jaguar bug?]

What I don't understand its that I call that code at the beginning of the game to upload the palette, I have a 128 color palette and some 16 colors palette, the same code it's called with the same values at the start, but sometimes I get some colors wrong (usually it works fine). WTF!?

 

I change the correct color index but sometimes the RGB color it's wrong.

 

Tomorrow I'll try to log all palette changes to see what happened, but the code it's too simple to be wrong.

[Another jaguar bug?]

Just to avoid to open a new topic.

 

Sometimes when I load a partial CLUT I got some colors wrong, anyone has the same problem? Sometimes it works, others it fails. This is the source code.

 

void set_palette(int16_t index, int16_t items, uint16_t *color)
{
	volatile uint16_t *clut = (uint16_t *)CLUT + index;
	while ( items-- )
		*clut++ = *color++;
}

Maybe it's better to update the CLUT on the vbl interrupt?

[Object Processor scaled sprites]

The scaling it's done from the left & top corner (right & top if the sprite it's flipped), If you need to scale the sprite from the center you must "move" the sprite so the center will be located at the same screen position. 

[Clone Jaguar console - maybe one day?]

18 minutes ago, CyranoJ said:

Well, I haven't done that since I wrote my library in 2012... so... It's something you only need to do once... and isn't that complicated anyway.... being one of the few fully documented parts of the system.

true... so you are 8 years ahead of me XD

[Clone Jaguar console - maybe one day?]

On 12/25/2020 at 7:09 AM, CyranoJ said:

- The console was hard to develop for (myth)

 

I find a bit annoying that if you write a wrong Object List you can hang the console, I doubt that if you write random values to the SNES/MD tile map or sprite memory you can hang the console, or if you send a wrong command list to the PSX GPU. IMHO it takes a bit more when you code from scratch.

[The History of the Atari 7800 ProSystem]

I got this in my recommendations, I hope that you're interested.

 

 

[Balancing the Bus and Mastering Jaguar Performance - Tips, Tricks, Questions and Beyond - Open Discussion]

16 hours ago, Clint Thompson said:

It was intended more as a simple graphic representation in Layman's Terms than a technical deep dive of timing, fetch and division. With that said and in the programming sense, I am able to pull music from RAM and ROM at the same time, as I do the same with graphics being pulled from both RAM and ROM at the same time. If you try to do the same thing all from RAM only, you run into serious trouble. Explaining beyond is probably buried deep in timing cycles, etc. and is far more technical than I was setting out to convey for the purpose of gaining a better general understanding on how to increase end performance and avoid bottlenecks, specifically for any newcomers to rB+

 

The real bus master!

Because if you fetch all from RAM you'll have more DRAM page misses, and that means slower access.

[question about CRY]

I've never tried but if you set bit 8 in VMODE you can mix RGB & CrY pixels.

 

oops, I don't know how to do it in raptor.

[Atari 7800 Prototypes]

The bigger ones with a connector on the upper side are development carts?

[TechRef/JagDox vs Mame source]

From tech ref.

[Double Dragon Game Guide]

fixed link, I think...

[The arcade classic “Popeye” is coming to the Atari 7800!]

wow

 

I hope to leave my days of procrastination and start to code the Atari 7800, at least I've downloaded Atari Dev Studio.

 

[sd cartridge for 7800?]

Which SD cart will have an USB connector for development?

[RMAC and external variable]

1 hour ago, Cyprian_K said:

I have the skunk but at that moment I use VirtualJag and COF files. It's easier and faster to do some simple tests

 

 

Until you test on real hardware and doesn't work... I almost never use emulators.

[RMAC and external variable]

2 hours ago, Zerosquare said:

In addition, code also runs faster from RAM.

I was thinking about that, RAM is faster than ROM.

[RMAC and external variable]

ops, ok, you don't need to put the org in the 68000 area, I forgot that.

 

35 minutes ago, Cyprian_K said:

  

In that case, I have no problem with that limitation. I'd like to place the only BSS segment in the RAM, and the 68000 code can be placed in the ROM area.

Why? put everything together in RAM. You won't save a lot of memory doing that, all the assets will take a lot more memory, and if you are coding with the real hardware it's a lot faster to upload each version to the RAM than flashing the skunk (if you are using a skunkboard)

[RMAC and external variable]

Put the .org directive at the start of the 68000 code, not at the .bss zone.

		.include        "jaguar.inc"

		.text
		.68000
		.org $4000


Start:

	lea	Start,A0
	lea	v_bmp_lowl,A0
	lea	a_hde,A0
	...

	.bss
	.dphrase

main_obj_list:  .ds.l    16*2
v_bmp_height:     .ds.w    1
v_bmp_highl:      .ds.l    1
v_bmp_lowl:       .ds.l    1


a_hdb:          .ds.w   1
a_hde:          .ds.w   1
a_vdb:          .ds.w   1
a_vde:          .ds.w   1
width:          .ds.w   1
height:	 	.ds.w   1

		.end

 

how do you generate COF then? rmac with -fb flag gives me only .O file.?

 

I'm coding with gcc, it generates a .elf file, although I write some parts in asm.

 

[Graphics Processor Object]

My idea was to make the code more simple not to save RAM, in my sprite routines when I've to draw a scaled bitmap I've to align it to 32 bytes and change the link address of the last object.

 

But maybe there's a better approach.

 

 

[Graphics Processor Object]

All objects have different sizes (STOP, BRANCH & GPU 8 bytes, BITMAP 16 bytes, SCALEDBITMAP 32bytes), with my scheme (STOP, BRANCH & GPU 8 bytes, BITMAP & SCALEDBITMAP 16 bytes).

 

If you are following the list to calculate the offset, you'll do the same but if you find a BITMAP or SCALEDBITMAP object you know that the next one is 16 bytes behind.

 

 

[Graphics Processor Object]

Yes, but if you remove the LINK field you could fit the scaled bitmap object into 16 bytes, and you won't need to align them to 32 bytes.

[Upcoming Jaguar Game Drive Cartridge]

#60 here

[Graphics Processor Object]

9 hours ago, CyranoJ said:

Height sorting objects into horizontal bands to reduce Object Processor load.

But to do that, you create a tree with branch objects at the start, then each node points to an array of objects, you should never use the link address of an object to point to an object of a different band.

 

Or maybe there are a different approach? 

 

This is in my TODO list, because many times I have no free cycles for the 68000.

 

[RMAC and external variable]

14 hours ago, Cyprian_K said:

@swapd0

that variable is defined in makefile

rln $(ALNFLAGS) -o gpuint.cof $(OBJ) -i jaguar.bin jagbits

 

I don't use rln but, this means that jaguar.bin it's defined as jagbits? you can remove that parameter and do an incbin in your source code, although it looks like the error it's before the linker pass.

[RMAC and external variable]

The code IMO has no meaning, you are not defining the value of jagbits, it's an address (defined like a label) or a constant, what it should be?.

 

You must have somewhere something like this

jagbits  equ $1234

or this one

jagbits::   dc.l $1234