s18: VDP/S16 graphics layer priority
Opened this issue · 10 comments
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
Is scene simulations are supported in this core?
Write NVRAM writes only a 4k file, it's not the full vram/objram.
+need VDP RAM, too...looks it's too complicated.
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.
+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.
I will check this and let you know what I can find
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?
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
I have updated the schematics in d7a8e17 with pin 5 identified as /SA and object wires labeled as OBJPRIO
@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.
I have written a custom firmware to test the video signals (path: cores/s18/custom). It works on MAME and simulation but when I tried to test it on the real PCB I found out that all of my EPROM chips are too slow for this board. I ordered faster ones. The issue is on halt until the chips arrive.