swapd0

None, I prefer original games or remakes not just a port. Although some Atari ST ports are great.

Yes, also the DSP has 8KB cache and 4KB for the GPU instead of 2KB each one... well scratchpad memory, not a real cache.

You should show the message from the image converter tool.

But nobody insulted you...

Just try with different sizes until the performance increment it's not too big vs silicon price. But with a 8Kb cache on TOM shared for the blitter, OP, GPU and external device (68000 or DSP), this means 4 read/write ports, you'll get a huge improvement. The blitter could texture map pixels at one bus cycle (13MHz) per pixel if you make it run at 26MHz (1 cycle read, 1 cycle write). Now each pixel takes 10 bus cycles (or it was 11?). Also the 68000 could run in parallel if you don't miss the cache.

Here is the problem. Really? So if I have a different opinion that makes me miserable? ...

If I don't want to worry about performance I'll code for PC.

16bits, 32bits, 64 bits... that's pure bullshit. Today, you could build a 16bits console that can wipe out Saturn, PSX or N64. It's more important the bandwidth with the memory, the slow bus (13Mhz) and the lack of cache kills the Jaguar performance. I can't believe that no body at Atari realized that.

You'll see it in the menu for Classic Kong, Chrismas Craze & Burger Time

Yeah... some times I would like to take a time machine and go to Atari or Flare in 1991 and tell them to include a cache in TOM, write buffer in the blitter, rearrange the blittter registers, more transparency modes, put a real sound chip, etc...

Can't use the OP, I am doing alpha blending into the GPU with a 2bits bitmap and a 16bits bitmap, the idea of using a 2bits bitmap it's to save bandwidth on each memory access I got 16pixels. The OP RMW it's almost useless, at least in RGB mode.

I don't understand all the complains, SainT is not a big company as Sony, Apple, Microsoft, Nintendo, etc.

You need pre-shifting if you are working with a 2bit per pixel bitmap and you want to do a distort.

Yes, I know that I've a bit of overflow but I'll fix that later. It's weird because I have the glitch on some positions, 0 it's ok, 1 wrong, 2 ok.

I never wait for the blittter because the code it's running into the 68000, and it has the lowest bus priority. I've used the blitter on several projects, never waited for it and they work.

it draws the bitmap at position 0, 64, 128 192, on the second iteration (I == 1) the bitmap will be drawn at 1, 65, 129, 193.. and so on. I need to create a "matrix" 4x16 (256x1024 pixels) with the 64x64 bitmap, on each row the bitmap must be shifted one pixel to the right.

Sorry but it doesn't run in the emulator, but if you look at the lower part of the blue square you can see some vertical lines, that lines should be drawn about 8 pixels to the left. It's like instead of writing 0123456789 it writes 1234567890.

I don't know, when I moved all the assets to the cartridge the game runs flawlessly, and the code was the same. It's going to be released as physical cartridge but first I need to finish the menu (almost done), polish some parts and check all the levels.

I'm trying to pre-shift a 2bits bitmap with the blitter. The source bitmap it's 64x64 pixels, the destination it's 256x1024, it looks ok but some shifted values look wrong, with some columns in the wrong order. Any idea what I'm doing wrong? By the way, it's possible to read in phrase mode and write also in phrase mode but with the data shifted one pixel? I doubt. Here it's the code. int16_t x, y; y = 0; for ( int16_t i = 0; i < 16; ++i ) { x = 0; for ( int16_t j = 0; j < 4; ++j ) { *A2_BASE = (uint32_t)src->data; *A2_FLAGS = PIXEL2|XADDPIX|WID64|PITCH1; *A2_PIXEL = 0; *A1_BASE = (uint32_t)dst->data; *A1_FLAGS = PIXEL2|XADDPIX|WID256|PITCH1; *A1_PIXEL = (y << 16) | x + i; *A1_STEP = 1 << 16 | (-64 & 0xffff); *B_COUNT = (64 << 16) | 64; *B_CMD = LFU_S|SRCEN|DSTEN|UPDA1; x += 64; } y += 64; }

Yesterday I was coding the f*cking menu for the game selection, I've done it three times because it was too slow.

I've been looking at the documentation but I haven't found it, it's possible to undefine an equr?

With BJL I never could upload the native demo until I wrote my own uploader that split the file in chunks and if one of them it's wrong uploads it again. Try to get a skunk-board.

Maybe you can convert it to C, use the cc65 compiler and have a look at the source code.

I would prefer a small fpga with another GPU with cache than a 68000 or 68020 processor.

From my experience it's the other way, the 68000 has the lower priority so usually the other processors don't leave free cycles to let it run.