search

mamedev / mame

MAME
https://www.mamedev.org/
Other
8.04k stars 2k forks source link

SideArms refresh rate #7043

Open jotego opened 4 years ago

jotego commented 4 years ago

SideArms timing seems wrong. I don't have the PCB but I have simulated the schematics for the timing circuit (sheets 8 and 9)

vertical timing is 16.384ms (61.03 Hz vs 60Hz in MAME). The interruption rate is twice of that: 122.07Hz

image

Find the verilog simulation attached. timing.zip

rb6502 commented 4 years ago

Thanks! Do you also know the pixel clock and total horizontal and vertical counts?

jotego commented 4 years ago

Yes, I have that information:

Pixel clock is 8MHz. Previous CAPCOM games with lower resolution used 6MHz, including Section Z and its family.

256 horizontal lines, of which 32 are blank. The vertical counter crosses zero in the middle of the blank, but I guess that is of no interest from an emulator stand point.

512 points per line, of which 128 are blank.

There are two interrupts per line, one at Vcounter=0x6F and the other at 0xEF. Note that the cabinet input (the byte that contains the coin and start button inputs, also have the blanking status in bit 3 (high means V-blanking) and an active low signal at bit 2 meaning a failure in a palette write, because palette writes are gated by the vertical blanking signal in real hardware.

The CPU can clear the palette error bit by accessing location 0xC8?3, where ? means don't care.

Street Fighter seems to follow the same frame rate from what I can judge of the OSSC reading and also because SF video PROMs are virtually identical to those of Side Arms, except for a slight shift in the HINIT signal -related to the OBJ circuit. But I have not extracted the SF circuit so there is a change -if small- I could be wrong

angelosa commented 4 years ago

256 horizontal lines, of which 32 are blank. The vertical counter crosses zero in the middle of the blank, but I guess that is of no interest from an emulator stand point.

Technically we are interested in this kind of information. If HW doesn’t have any readback over counters then it can still be read out in debugger (beamx/beamy in integer format), plus from your wording I’m gonna assume video layer alignment should shift i.e. most drivers treats position 0,0 as first displayed pixel in top left corner, which is wrong but that’s hardly something provable or documented without actual HW testing.

jotego commented 4 years ago

In this case there are schematics available and the only custom chip used has already been reverse engineered too so all information is there. The counters are relevant to the graphic circuits but as you do it in software it probably isn't important. Still, you can fine tune the time at which interruptions occur with the information I've given above.

It's fine how the current MAME driver gets along with just one interruption per frame. I guess in real hardware the mid-frame interrupt may just check the blanking value and wait for the next interrupt which should happen within the blanking period.