Sprite multiplexing on Amiga

[ross]

I've a solution, using only sprites and no copper tricks or dual playfields or more colors:

Blinky (red)
Pinky (pink)
Inky (cyan)
Clyde (orange)
eyes: blu, white

COLOR registers:
16 null
17 red
18 blue (normal +ATT)
19 white (normal +ATT)
20 cyan (null for Pinky) (+ATT)
21 pink
22 blue
23 white
24 black (+ATT)
25 black (+ATT)
26 black (+ATT)
27 black (+ATT)
28 orange (+ATT)
29 null
30 null
31 null

sprite 0 Blinky
sprite 1 black tunnel at right (ATT bit)
sprite 2 Pinky
sprite 3 null
sprite 4/5 Inky (ATT bit)
sprite 6/7 Clyde (ATT bit)

So main idea:
- use sprite 1, ATT=1, DATA=0, DATB=$FFFF, position right of screen (tunnel)
- use sprite 4/5 and 6/7 as 16 colors sprites
- COLOR24,25,26,27=0 to make Blinky disappears when 'overlaid'/'mixed' by the tunnel (other ghosts disappear in tunnel by sprites auto-priority)

EDIT: but i guess this has nothing to do with sprite multiplexing, this question and answer should be moved to your Pacman thread

[jotd]

I'm not too familiar with attached sprites but I get it now. It looks a lot like my original idea, only better

It's however complicated and non-symmetric. I'd have to redo everything sprite from the start, where it works perfectly now, except for that clipping part.

I have enough CPU power to shift sprite images.

Thanks anyway.

[mcgeezer]

Another way to do it would be to use one of your in game colours for the clipping, but horizontally change the colour to Black at the borders.

Geezer

[jotd]

I was planning to do that, but problem is: the color I'm changing to black and which must be restored is variable too (depending on the enemy state). So I'm going to have to write to 16 words each time the enemy changes state (only the enemy using the other sprite though)

In the end, shifting the data is simple & generic. I'll go for that.

[phx]

Due to a recent discussion I need confirmation for this statement again:

Originally Posted by Toni Wilen

They have fixed positions but if DMA channel is not needed for current line (even if DMA channel is enabled), it's slot(s) can be used by other lower priority channels, including CPU.

The last two words still surprise me. Even the HRM states that the 68000 can only use every second cycle for memory access. Let's call them "odd cycles". Most custom chip DMA is peformed during even cycles - including Sprite DMA we were talking about.

How can such an unused DMA slot, which is on an even cycle, ever be used by the 68000? I don't get it...

[roondar]

Originally Posted by phx

Due to a recent discussion I need confirmation for this statement again:


The last two words still surprise me. Even the HRM states that the 68000 can only use every second cycle for memory access. Let's call them "odd cycles". Most custom chip DMA is peformed during even cycles - including Sprite DMA we were talking about.

The HRM simplifies things a bit for clarity, but the CPU can actually access any cycle on the bus - it just can't access two bus cycles in a row.

How can such an unused DMA slot, which is on an even cycle, ever be used by the 68000? I don't get it...

Normally, the 68000 gets pushed into the 'odd' cycles, but if you use a 68000 instruction that has a cycles count that is not divisible by 4, you can actually get CPU cycles on the 'even' cycles as well.

This is usually not permanent, as DMA sources tend to push the CPU back onto the 'odd' cycles shortly afterwards, but it's still possible.

[phx]

Originally Posted by roondar

Normally, the 68000 gets pushed into the 'odd' cycles, but if you use a 68000 instruction that has a cycles count that is not divisible by 4, you can actually get CPU cycles on the 'even' cycles as well.

Ok, I see.

This is usually not permanent, as DMA sources tend to push the CPU back onto the 'odd' cycles shortly afterwards, but it's still possible.

There are quite some instructions and addressing modes, which have a cycle count which is not divisable by 4. Does it mean that the CPU is constantly blocked and pushed back into the odd cycles? That would be less than ideal.

[ross]

Originally Posted by phx

There are quite some instructions and addressing modes, which have a cycle count which is not divisable by 4. Does it mean that the CPU is constantly blocked and pushed back into the odd cycles? That would be less than ideal.

No, it depends on DMA bus usage.
The CPU cycle is 'delayed' only if Agnus requires it for its purposes.

Odd cycles are usually the most used by DMA channels because they have priority in the fixed allocations (refresh, audio, disk, sprites, bitplanes..), but, for example, copper (or blitter or >4bpls) use possibly even cycles.

So in the 'grand scheme' of bus usage, it doesn't really matter if the CPU requests a 'misaligned' cycle.

EDIT:
If I'm not mistaken this is one of the big differences between Amiga and AtariST (but I ask the ST experts for confirmation!) where what you said always happens.
For instance, an instruction like

lsl.w #4,d0

is often two cycles faster on the Amiga .

[phx]

Originally Posted by ross

So in the 'grand scheme' of bus usage, it doesn't really matter if the CPU requests a 'misaligned' cycle.

Agreed. Although for me this is still a shock, because I was always convinced that the CPU would never be blocked from Chip RAM access, as long as I don't use blitter, copper or more than four bitplanes.

Thanks for the explanation.

[Steam Ranger]

Personally I've never used sprites, I usually have everything in memory and just use the blitter (I have a kind of multitasking interface for the blitter that I've developed).

[hooverphonique]

Originally Posted by ross

For instance, an instruction like

lsl.w #4,d0

is often two cycles faster on the Amiga .

This example only uses the bus for fetching the instruction, so how would it take longer on an ST? Is it because the following instruction is delayed to 2 cycles (for alignment), so it isn't actually this instruction that takes longer?

[ross]

Originally Posted by hooverphonique

Is it because the following instruction is delayed to 2 cycles (for alignment), so it isn't actually this instruction that takes longer?

This.
It is only an indirect effect of the 'delay' on next fetch.