7seg outputs regression @ Commit fda18d3

[ToBul]

Before Commit fda18d3.
The player 2 segs are slightly out of time in-game but seem to work better when run from the test screen.

Before.mp4

After Commit fda18d3
Segs stalling, p1 segs not functioning

After.mp4

NOTE:

I'm using a Google AI python script made when network outputs were added. It may not be totally robust and may even add it's own latency.
To be honest I don't fully understand the python stuff, I just tweaked the html viewer as AI's css skills are worse than mine. 😆
Hopefully it's good enough to demonstrate what looks like a regression.

Here's the file so you can test for yourself. It's just a python script with the html file needing to be in a 'templates' directory.
It should just work from the Supermodel directory, it assumes relative paths. Just adjust the paths and commands in the 'cmd' list as necessary.

outputs.zip

BTW:
Before the commit I had to slow the ppc for the Virtua Striker games or the segs didn't work at all, and then they only seem to activate from the test menu ?? . Some games are obviously more timing sensitive, but I guess that's what the z80 stuff is trying to address.

Maybe one day the script could be improved and added to the Supermodel scripts dir. Would be cool to see how it should of been written.

[ToBul]

Just noticed MAME also has the winner lamp flash during vf3 seg output test.
Not sue if that's down to the shoddy script I'm using or an emulation thing.

Edit:
The html viewer is laggy, winner lamp does flash

[dukeeeey]

Yeah I guess i accidentality broke this with the last update. The question is, what triggers the irq for these? How many times / frame should they be fired.

[dukeeeey]

Okay, I figured out roughly how it works. The IRQ triggers a counter. When the counter gets to 128 it increments the frame counter and will play the next sequence in the animation on the billboard.

The old code in supermodel was a bit broken, but it fired the irq at roughly 400 times / s. Or around 7x per frame.
400/128 = 3~ times per second. So that means the display updates at roughly 3 times per second which matches the video capture above. The video was 30fps and it seemed to update roughly every 9 frames.

What I need to make this work properly is to know what is the actual update rate on real h/w? If we can find some 30 or 60hz high quality footage from a real machine I can use it to estimate the update rate, from that I can then work out how fast the IRQs should be firing. Previously I think it was complete guess work, and this is why the lamp outputs work but are a little broken. We are simply going at the wrong speed.

[ToBul]

The html & python viewer I used was a bit laggy, I've since had Claude improve it a bit but it's never gonna be bob on.
Only footage I've seen doesn't look consistent
https://youtu.be/LJvslbrhONg?si=iU4F-JHZbT1R4N9X&t=1234
http://solid-orange.com/1431/comment-page-1

[ToBul]

that first link i've posted is the 'new versus' not 'verses' hence the difference