s18: VDP/S16 graphics layer priority

[gyurco]

The VDP/S16 rgb output is mixed by an analogue switch. The mixing is controlled by the 315-5373 custom chip.

The PLD content translated to Verilog:

vdp_sel = vdp_en & vsp_ysn & (!vid16_en
    | (vdp_prio[2] & vdp_prio[1] & vdp_prio[0])  // 7
    | (tilemap[1] & vdp_prio[2] & vdp_prio[1])   // 6,7
    | (tilemap[4] & vdp_prio[2] & vdp_prio[1])   // 6,7
    | (obj_prio[0] & tilemap[1] & vdp_prio[2])   // 4,5,6,7
    | (obj_prio[0] & tilemap[4] & vdp_prio[2])   // 4,5,6,7
    | (!obj_prio[1] & vdp_prio[2] & vdp_prio[1]) // 6,7
    | (!tilemap[0] & vdp_prio[2] & vdp_prio[1])  // 6,7
    | (obj_prio[0] & tilemap[3] & tilemap[1] & vdp_prio[1]) // 2,3,6,7
    | (obj_prio[0] & tilemap[3] & tilemap[4] & vdp_prio[1]) // 2,3,6,7
    | (obj_prio[0] & !obj_prio[1] & vdp_prio[2] & vdp_prio[0]) // 5,7
    | (obj_prio[0] & tilemap[3] & tilemap[2] & tilemap[1]) // all
    | (obj_prio[0] & tilemap[3] & tilemap[2] & tilemap[4]) // all
    | (obj_prio[0] & !tilemap[0]& vdp_prio[2]) // 4,5,6,7
    | (obj_prio[0] & tilemap[3] & !obj_prio[1] & !tilemap[0] & vdp_prio[1]) // 2,3,6,7
    | (obj_prio[0] & tilemap[3] & !tilemap[0] & vdp_prio[1] & vdp_prio[0]) // 3,7
    | (obj_prio[0] & tilemap[3] & tilemap[2] & !obj_prio[1] & !tilemap[0])); // all

[gyurco]

Is scene simulations are supported in this core? Write NVRAM writes only a 4k file, it's not the full vram/objram.

[gyurco]

+need VDP RAM, too...looks it's too complicated.

[jotego]

S16B core supports scene simulations so it would be possible to implement it here too but it is currently not done. If the scene you want does not take long to get to, you can simulate the core with custom inputs to get to that point and save data once it's closed. It is time consuming (CPU time) but requires much less thinking that implementing scene simulations.

[jotego]

+need VDP RAM, too...looks it's too complicated.

Maybe VDP internal registers are needed too. That can be really complicated to do with a netlist like that.

[rp-jt]

I will check this and let you know what I can find

[gyurco]

Some observations: objcolor0 and 1 don't make much sense. Maybe they're numbered oppositely on the schematics? Then they'll be objcolor[11:10], which matches the real priority bits. The 5 tilemap signals can be the 3 normal + 2 shadow layers?

[jotego]

Then they'll be objcolor[11:10], which matches the real priority bits.

Yes, the sch name is misleading. We are connecting the priority bits in the core.

I have measured IC65 for two images on an Alien Storm board.

Fix layer active

Pins 5,6,7 are stuck high Pins 4,8,9 toggle

pin 4

pin 8

pin 9

Fix layer and scroll 1 active

Scroll 1 shows SEGA WORLD

Pins 6,7 are stuck high Pins 3,4,5,8,9 toggle

Pin 5

Pin Meanings

• pins 4,5,8 seem active low
• pin 5 is S16's SA (scroll A), active low
• pins 6,7 might be the obj priority, instead of pins 3,6 in the sch (review PCB connection)
• pin 9 could be active high

[jotego]

I have updated the schematics in d7a8e17c with pin 5 identified as /SA and object wires labeled as OBJPRIO

[jotego]

@rp-jt the fix for mwalk broke some of the pseudo 3D levels in astorm. If you watch the attract demo, it happens in all levels except the first one.