swapd0

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

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.

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?

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.

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

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.

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

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

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.

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

From tech ref.

fixed link, I think...

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

Which SD cart will have an USB connector for development?

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

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

ops, ok, you don't need to put the org in the 68000 area, I forgot that. 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)

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.

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.

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.

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.

#60 here

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.

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.

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