PM overlap question

[texacala]

Looking over an A8 memory map, the 53275/D01B location, PRIOR, allows the option of setting bit 5 to enable "overlap" of players 0 and 1, or 2 and 3 to display a third color. Anyone know if this is true for the associated missiles? For example, if missile 1 overlaps Player 0, do I get an extra color? I can't seem to find any documentation that specifies how this works.

Thanks in advance,

 

Alex

[Rybags]

Also applies to the Missiles unlees the "5th Player enable" bit is set, then missiles will have the PF3 colour.

 

In the overlap mode the resultant colour of overlapping pixels is the actual colour of PM0 ORed with PM1.

So, e.g. colours PM0 = 84, PM1 = 48, the resulting colour would be CC.

 

If the lower 4 bits of PRIOR are left empty, then the ORing also applies betwen players and playfield, so allowing 23 onscreen colour combinations.

[texacala]

Woah... ORing between players and playfield?? But would that mean no priorities are set for whether players appear in front of playfield colors or visa versa? I assumed you would need to set one of the first four bits automatically, very interesting...

[phaeron]

In the hardware, "priority" really means some layers disabling others. By default, PM0 turns off PM1, so that's how you see PM0 on top of PM1. When multicolor players are enabled, though, that doesn't happen and so PM0+PM1 just combine instead. Similarly, when you set one of the four lower bits, you're selecting a combination of signals to cross-disable between the playfield and the players. You're only supposed to turn on exactly one of the bits, but if you turn on more than one, you get the cross-disables from both -- which gives you some cases where conflicting signals turn on and nothing is left, giving black -- or in the case of no bits, none of the cross disables turn on and you get mixing between the playfield and the players. You can't get all of the combinations, as PF0/PF1/PM0/PM1 still have priority over PF2/PF3/PM2/PM3.

 

There are a couple of other weird anomalies in the priority logic. The fifth player bit routes all of the missiles into the PF3 input and has that priority relative to players and missiles, but it actually has priority over PF0-PF2. The fifth player also mixes interestingly with GTIA modes 9/11. Finally, anything hires (mode 2/3/F) bypasses all of the priority logic, so its luma overrides everything regardless of priority settings.

[Rybags]

ORing when enabled for PM/PF occurs among PM0/1 and PF0/1, PM2/3 and PF2/3. Priorities still exist among unpaired players and non-ORed players/playfield. PM0/1 on top of everything, PM2/3 under everything when ORing doesn't occur.

[texacala]

Thanks guys for the clarifications. I've been reading through Chadwick's Mapping The Atari book and I haven't found as comprehensive a description of priorities. This is very helpful, and I have to say more complex than I imagined! But I guess that's par for the course with the A8, lots of hidden power...