What exactly INTC Sync Hack does?

[vsub]

There was info about the other hack but not this one...I'm just curious to know what exactly this hack does,because since pp441 till now the x? Cycle Rate is almost useless for me,even on most of the games using it slow down the games a lot when there's something that the CPU is working hard on(loading something big).

For example with only INTC Sync Hack the games are working on the speed I get before pp441 with all speed hack enabled.Now if I try to use any x? Cycle Rate with INTC Sync Hack for example on Atelier Iris 3 when I'm doing Edge's Godly Beam when the beam fall on the ground the speed goes from ~90 to 25 and with only INTC Sync Hack for ~90 to 50(is I use VU-Skip it doesn't go below 60)....using only x? Cycle Rate on almost all of the games I've tried form pp441 till now don't give me any speed boost.

PS.I'm not complaining about anything,I'm just curious

[LuisR14]

yea i've been curious what the INTC sync hack does.

[Jasperking]

New Speed Hack! And a good one! This is an idea I had a while back, as
implemented by Pseudonym, and is intended as an eventual replacement for all EE
speed hacks (x2, x3, etc). Expect huge speedups in most games way beyond even
X3, and it shouldn't break FMVs or cause graphical artifacts either like the old
hacks do.

That was taken from the revision it was made. The comments were removed so i can't find anymore information

[LuisR14]

that doesn't explain what it does.

[Jasperking]

Yeah Air did explain what it did sorta in the comments but they get deleted overtime

We will have to wait till he replies to this thread.

[Air]

Many games, in particular 2D-ish ones and many early generation PS2 games, "spin" on the INTC_STAT register to sync to the vertical display rate. Specifically, INTC_STAT contains a flag that is set to 1 when the vsync happens. Games wait on that, and then begin their next frame logic and renderering afterward. Normally this is slow because it's a very short spin loop -- a mere 4 MIPS instructions -- that includes a computationally expensive hardware register check. (hardware register reads must go through the VTLB's special handler since many hwRegs map to odd addresses, or set or reset themselves when accessed). When done thousands of times per frame, it ends up being the equivalent of the old joke, of adding:

Code:

int b=0;
for( int i=0; i<100000; i++ ) b++;

... to the emulator.

The INTC Hack works by instantly fast-forwarding Pcsx2's internal emulation to the next scheduled event whenever INTC_STAT is polled by the game. The theory being that about the only time a game ever cares to read INTC_STAT is when it's done doing "everything" and needs to wait for something else to finish (either the GS, various hardware counters, or the vsync). Since it's just idlely looping anyway, no harm in just "zapping" the loop out of existence and skipping right to the meat of the action.

This differs from X2 and X3 sync hacks in that it generally doesn't impact times when the EE is, in fact, very busy doing important things. This namely applies to FMVs, and also to most later titles on the PS2 (which had fancier gfx, AI, etc). When games are busy doing stuff they aren't going to bother checking INTC_STAT for anything, and so the hack never gets used anyway. By contrast, X2 and X3 hacks basically cut the EE's clock frequency in half (or less). This works fine for some games, but causes lots of problems for things that depend on the full instruction throughput of the EE.

[LuisR14]

thanks Air (now we all know how it works )

[vsub]

That's really cool hack then...thanks for the info