forums.jaspp.org.uk

I'm not overly happy with the way I've currently implement the 50Hz VSync, so am going to recode it as a Phase Locked Loop and do a comparison. Currently the code starts counting GPU generated VSyncs on a MODE change, and if after 1 sec the GPU is generating more than 50Hz, it starts ignoring the GPU and generates it's own VSync at 50Hz.

Advantages of current method:

• The game sees a very precise 50Hz VSync

Disadvantages:

• Any dropped VSync during the initial count could make it look like the GPU isn't at 50Hz, when it is
• There are a lot more VSync being generated, essentially the monitor Hz + 50

Advantages of a PLL:

• No requirement to pre-count VSync's, it will naturally settle at an average of 50Hz immediately
• No requirement for a separate 50Hz VSync to be generated

Disadvantages:

• The 50Hz VSync that the game sees won't occur every 2cs, it will drift forward/backward to average at 50Hz

This is now partially coded although it's had a knock on effect on the blitter that requires some drastic changes. Essentially I need to change the blitter to track screen geometry on a per framebuffer basis and only change the geometry, when the relevant framebuffer is blitted.

The first step towards this was to move to triple buffering, which is done; I now need to code up the geometry handler. Hopefully this will also fix the scrolling in James Pond 2, but I can't be certain, as I'm still not 100% certain of the cause of its jerky scrolling.

Because of all these big changes, I've not put a daily build up for a while as its not at an acceptable level yet.

A quick update on this and the next release in general.

Firstly, due to a combination of going to work in Sept and poor health, I've not put much time into ADFFS this month. I was hoping to have the next release ready for a Christmas release, but it's very unlikely as there's far too many code changes and testing required for the blitter and ARMv7 support.

I've also been somewhat sidetracked by optimizing Zarch, which I had started earlier in the year but not spent much time on.

Thanks for the info update, Jon. As you know I follow this project very closely and visit this forum on a daily base, so reading news (even if they are no-news) is good
I hope you recover you health! It's cold around here, too, and it will get colder, so it's normal to have minor issues.

Hope you make a speedy recovery.
Jerry

I've resumed development of 2.53 this week and noticed that raising VSync at 50Hz via a PLL breaks SWIV, which hangs randomly on the title page. My suspicion is that there's possibly a section of code in SWIV that isn't re-entrant, although that's purely a guess. IRQ's are disabled when any game interrupts are called, but if a game enables IRQ's and can't handle re-entrancy it's going to hang immediately.

Adding back the VSync raised via RTSupport at 50Hz fixes the problem, however it creates another issue in that there's now 50 more VSync's occurring. For the most part this doesn't affect games, but I have noticed Chuck Rock's title sequence runs too quickly. Its reporting 25fps where 2.52 reports 20fps - which clearly isn't right, I suspect 2.52 is misreporting 12.5fps. It's probably just a bug in the code that forces the frame to blit when a game hasn't frame swapped for a certain number of VSyncs, this could be getting confused by the increased number of VSync's.

On the positive side, games now see 50Hz immediately, where previously they'd run at the monitor refresh rate for 1 second until the number of actual VSync's/sec had been counted.

The crunch test will be to see what happens when the monitor is at 50Hz...is Pac-Mania's scrolling smooth?

Woho! Back to testing I am!

I'm still debugging, its pretty much unusable at the minute...

This morning, I've found out that this change also causes OS_Find to lock up, when changing discs in most games

Despite all my efforts in trying to figure out why blitting the frame via a PLL should cause OS_Find to hang, I've not managed to find a working solution.

I've tried everything from stopping the blitter and waiting for IRQsema to clear down, to unsubscribing from RTSupport. I suspect the root cause may be a compiler bug or a timing issue, both of which are near impossible to diagnose.

Sadly, I'm going to have to drop this for the time being and roll back to the original method, otherwise I'm going to be wasting weeks trying to find a fix and possibly get nowhere.

EDIT: This change was released in 2.60