CPS2 - Important information to anyone using the hardware.

[Unessential]

INow its time to fix it?

There may not be anything to fix. From what I gather, this can happen on original boards and hardware as well. Under and overpowered boards go wonky. But all of them behave in different ways this just happens to be how the CPS2 behaves. Which some people have blamed on phoenix sets in the past (and the multikit now)

 

[Dion]

Yes, there is nothing that requires a fix. If you are worried about timing (though no one has noticed anything) then just set your voltage to 5.08.

Someone contacted us who saw this thread and has in depth knowledge of the CPS2 architecture and is responsible for much of the new breakthroughs in the arcade community and we have been informed that the way the CPS2 processes the game code that the game will completely freeze rather than start dropping frames. This guy likes his privacy and doesn't want his name used (let's just say that AMB stole A LOT of his work to sell) so he is someone to listen to. He is also smarter than anyone posting on this site or on our site. Here is the quote:

"If there isn't enough power only ram would be affected as it's asynchronous. The rest is regulated by the clock. That means that if there is a power drop and it affects graphic ram then you could see glitches. If it affects sound ram you could hear sound glitches and if it affects program code, program will hang immediately.

No Delays.

Either works or hangs immediately"


I'm still interested in seeing results, especially with decrypted sets on both original and multis but I don't think an actual performance issue will be seen. Possibly a freezing issue or even failure to boot the program if voltage goes low enough.

 

[Xian Xi]

If anyone should be in here it would be DreamTR, he plays high level fighting and would definitely be able to tell if timing is off on anything.

 

[Unessential]

I'm a high level super street fighter II turbo player as well (some vampire saviour, and even less Alpha 2). That's actually what got me into arcade collecting (I built a supergun for that game, and figured I might as well get other stuff too) However I don't have access to a board that's phoenixed nor the multikit. (I want to get a multi kit eventually though since I have a xvssf that just died recently)

I don't think DreamTR's played super turbo or any CPS2 fighting game in ages... at least, not competitively.

From my experience (non phoenixed cps2 boards) if the voltage is too low for the board, the fan still runs (although slower) but the board simply doesn't start up. I think the fan runs off of 12v rather than 5v anyway...

That's probably more likely due to the fact it's probably my power supply that doesn't allow fine tuning. After this weekend (canada cup) I'll try and do small dials to the power and see if i can hit a sweet spot where I can notice timing issues and the game still boots up (battery CPS2 SSF2T)

I think I notice timing issues on emulators such as mame and fba, maybe it's an illusion compounded with input lag,

it's not relevent to this thread but I can also feel input lag greater than 1 frame. because it messes with the consistency of my reactions and timing.

Super Turbo isn't exactly the best game to use for "subjective" (human) testing of speed since some stages run faster than others... but it doesn't hurt to try.

 

[Razoola]

Yes, there is nothing that requires a fix. If you are worried about timing (though no one has noticed anything) then just set your voltage to 5.08.

Someone contacted us who saw this thread and has in depth knowledge of the CPS2 architecture and is responsible for much of the new breakthroughs in the arcade community and we have been informed that the way the CPS2 processes the game code that the game will completely freeze rather than start dropping frames. This guy likes his privacy and doesn't want his name used (let's just say that AMB stole A LOT of his work to sell) so he is someone to listen to. He is also smarter than anyone posting on this site or on our site. Here is the quote:

"If there isn't enough power only ram would be affected as it's asynchronous. The rest is regulated by the clock. That means that if there is a power drop and it affects graphic ram then you could see glitches. If it affects sound ram you could hear sound glitches and if it affects program code, program will hang immediately.

No Delays.

Either works or hangs immediately"


I'm still interested in seeing results, especially with decrypted sets on both original and multis but I don't think an actual performance issue will be seen. Possibly a freezing issue or even failure to boot the program if voltage goes low enough.

Tell you friend that the test code runs on a CPS2 board in an identical way all game code would. I have been a games programmer, there is nothing in CPS2 architecture that would cause games to freeze if counts are slightly out. That's like saying overclocking or unclocking would never work on a games system. I agree what he is saying about voltage though totally.

I am only saying its voltage related at this point because someone has come forward and said upping the voltage fixed the situation for him. It may turn out to be something different as the cause but the raise in voltage fixed it he stated.

From what your friend says he is implying he feels that this is not a voltage issue. That sort of implies that this issue only affects your multikits (which is something I do not believe at this time). The fact however is two multikits tested have shown this situation (one says fixed with voltage increase) and of fiveteen EPROM based boards, none have of yet.

Your friend I feel does not understand what the test program results are showing so I will lay it out for both of you and what it means when lower than unexpected values are returned. Those test results show either;

A) The frame timing is different (no longer the CPS2 default). IE; the system is no longer running at the correct refresh rate for the frame tested.

B) The available CPU cycles has changed with the system running at the correct refresh rate for the frame tested.

C) The CPS2 bus is adding wait states on reads from the program ROM space when it should not for the frame tested.

In all three cases frames will not necessarily drop, the amount of cycles given to the 68k to use in the tested frame has changed however. This issue will only cause dropped frames (depending of the severity of cycles lost) in some games that are on the limit... Progear comes to mind because that drops frames already even on a correctly working CPS2. In short progear could drop more frames than it otherwise would running on a system with this issue, or drop frames where it would not normally. Progear aside, the difference in speed of the 68k per frame will affect things like game timing and AI in some games more than others. The SSF series being a prime example of a game more susceptible than others given how its coded.

I'm not saying your friend does not know his stuff (he sounds quite knowledgeable) so please invite him to explain the test results and offer his opinion to what he believes is the cause of the test returning unexpected values. All information is helpful.

Like you I want answers and I'm not blaming the multikit, Im only going on what one multikit owner has posted in this thread as what fixed the issue for him (I'm still waiting to hear back from the other who's results show the problem). You have a multikit, you are able to do the tests yourself and post what you find (I have asked once already), that would be helpful also.

Raz

I have edited this post a to try and make it a little more clear in a couple of areas.

 

[ebinsugewa]

Raz can you give a bit more detail about what the issue with SSF2T would be? I have access to phoenixed/original copies of the game as well as running tournaments for it and playing it all the time. Myself or other people in the ST community would be glad to do some further testing if it ensures the game is running correctly on top of what you've already asked.

 

[Razoola]

Sure. First I have to make it clear that I am not an expert SSF2T player so some of these things I bring up I have no experience personally myself, I'm talking about what expert players and tournament hosts have told me. I know just how serious this issue can be taken by people who love SSF2T and just how serious they are about the game playing correctly. Many years ago I was commissioned to create a special SSF2T version for tournament use in Japan, this version was made just for tournaments. The number one rule was all changes were NOT allowed to cause the game to play differently. The tournament host found it unacceptable if even 4 cycles were added or removed per frame from the point the game round started until it was over. It was tested by expert players to confirm it played right before it was used, I guess this let me know just how serious the matter was taken.

Coming onto what this issue can do to SSF2T gameplay is quite complex because it can mean different things depending on what the cause of the cycle loss is (one report shows about 650 cycles a frame during what would be gameplay), and what game level is being played. I'm sure you are already aware expert players can feel the difference in game play depending on the background level, it shows just how susceptible this game is to timing changes and how the smallest change can be felt by the player.

In the explanation in my previous post about what the test results show one needs to group cause A separate from cause B and C. I'm also going to leave game AI out of this even though it can be affected and just talk about game speed and input polling.

If the cause is A the most obvious and potential side effect would be an increase in game speed over time. Basically if you had 2 games running side by side through attract mode with identical revision, game settings and region, one with the issue and one without, the board with the problem could run faster. This would mean all timing during game play is faster thus affecting input given how it is read by the game. It is also possible however the game could run slower, it is very dependant on what the game is doing at the time. In some places it might be faster and other places slower. What would be different regardless would be the time between polling of the joystick port.

If the cause is B or C then the most obvious side effect could be game slowdown. Again running identical boards side by side the one with the issue could start to lag behind. Again like cause A, it may affect some places of the game more than others. On top of this however would be an issue where polling of the joysticks is still happening at the same speed as the board without the issue.

If you can do testing on phoenixed boards and let me know test result numbers that would be great, if you can find a board showing the issue that would be even better for testing purposes.

One test I really want to do myself on a phoenix board would be to test a board that does not have the issue and then slowly lower the voltage, keep trying the same board to see if the issue appears before the board stops working altogether due to low voltage. I would have done this myself already but my PSU does not have a voltage dial on it.

 

[Namnuta]

It's not his creation.
He objected to the compatibility of his work being played on it due to his dissatisfaction of it even existing.
Now he's saying that the PHX roms (which should be incompatible with this device) run slowly due to a defect on the device (a device that he himself doesn't like).

Sounds legit to me.

Would be nice to have the creator of the multiboard provide his own findings on it.... fat chance of him coming back here though.

QFT

 

[Razoola]

@aha2940, your PM box is full.

 

[aha2940]

@aha2940, your PM box is full.

Sorry man, made some space.

 

[ChuChu Flamingo]

Razoola, what changes did the tournament person in japan want, just curious. I am assuming being able to pick a new character for both sides without soft resetting.

 

[Razoola]

Razoola, what changes did the tournament person in japan want, just curious. I am assuming being able to pick a new character for both sides without soft resetting.

That's going a little off topic of what this thread is about but it did not offer this feature, mainly because it offered other things that made that unnecessary. For example it was a two player game only (1 coin = 2 player game), you are not able to play the CPU at all either. Once a player won a match the game was over. Hence what you suggest was not needed, there was also no scoring / highscore either, it is all about beating the other player only. It has many other things also besides that, its an ultra rare version of the game, only 2 copies exist.

 

[Tyranix95]

Raz,

The CPS2 multi-board is a collaboration project between a hardware developer and a software developer.

So, why not let ds load your ST phoenixed rom onto a multi-board, and then run the speed test on it.

Perhaps that will yield some useful insight into the problem.

Just for testing purposes only though.

 

[Razoola]

@Tyranix95

The test program is available for download in my first post in this thread (both EPROM and multikit form). I have suggested Mitsurugi-w test it and post test results twice in the thread. You are welcome to download the test and do it yourself also if you have a multikit or on EPROM in a CPS2 unit if you have

 

[Tyranix95]

Raz,

All I got are battery CPS2 boards.

So, not sure if I can help in that way.

---

But, what I'm wondering is if a phoenixed rom on a multi-board would have the same problem(s), or not.

 

[Razoola]

Yup, that's no help but thanks for offering.

A phoenix ROM on a multiboard would have the same problem, even a encrypted rom on a multiboard would have a problem. But to make it clear testing is not just about the multiboards, its about non multiboards also.

Although the data so far points to it, at the moment I am not convinced this is a multiboard only issue given this speed issue was reported years ago. Although I proved back then non encrypted games do run at the same speed as encrypted, I cannot rule out the people complaining were not powering their boards correctly. Its only since testing again has a measureable speed difference been obtained. Only in multiboards at this time but I can't rule out non multiboards exhibiting the same problem under the right conditions.

So far only one person said a voltage change fixed the problem. That may not turn out to be a solution what will work for everyone, its to early to say for sure.

 

[Razoola]

Just had the first report of this problem happening on non multiboard cps2 system. Just waiting on confirmation the EPROM spec is ok. Hopefully they will have a video posted tomorrow.

 

[Dion]

This is what we were thinking. The chances of it happening just on the multikit had to be next to zero. Glad to have a confirmation finally. We did the math and the combined power usage of all components on the multikit is TEN TIMES LESS than a b-board that has all program, sound, and GFX roms installed.

So there very well could have been people experiencing issues years ago using the eproms. But the chances are if they were using the same power supply and pcb with battery power they would have the same issue. The CPS2 may be more picky about power than once thought and this would be a CPS2 quirk, not a multikit quirk. My opinion is that the moral of this story may very well be to just check you damn voltages with a meter.

 

[Razoola]

Yes and its what I have though all along also which is why I never blamed the multiboard even though the results were pointing that way. Just waiting on confirmation the person did the test right because he has issues originally trying to get the test to work so I want to be 100% sure with his results.

I have already updated a few days ago the free suicide tester program I released years ago to also do this test, its not released yet as I'm still testing it. I will do that in the next days all going well. As I mentioned already it would be good for you to advise your users to do the current test on their SD cards so they can check their cps2 hardware is running at the correct speed.

 

[Razoola]

From what the user told me it appears his EPROM is ok. Here are the videos.

The first video shows the system being turned on and everything looks 100% fine for a couple fo minutes. The second video shows the problem. He tells me the system was not powered off or on during the time between videos (which he says is 2 minutes). The system starts loosing cycles in a big way in the 2nd video.

I myself have left my CPS2 on for 3 hours running the test and I did not experience the issue being shown here.

 

[Razoola]

Couple more videos by the same person using a beta of the new suicide tester program

this video below = 4.96v



this video below = 5.08v



I think its quite clear now the situation an undervolt can cause the system. Still not 100% sure though if this is related to ageing parts that would have worked fine at the slight under volt in years gone past or not.

Mitsurugi-w, if you can please test (using the test programs) and confirm the voltage changes required if a multikit is on the CPS2 board is in the same order as what is seen in the videos then I will update the first post in this thread so the voltage warning is the same for both eprom based and multikit based systems. I would like to hear from you to confirm this first because you are an official support person for the device.

Raz

 

[Xian Xi]

The way to correctly test the voltage theory is for someone to check the IC furthest from the JAMMA connector and see what the voltage is at when the edge is set to 4.96/5.08v. If it's pulling enough amps I am guessing that it's dropping below the 4.70v threshold a lot of ICs have. Lowest I've ever gone on a board while still able to function is 4.65v, anything lower usually won't work.

 

[Razoola]

There has been two results now showing a voltage increase fixes the situation but I agree totally that low voltage may not directly be the cause, that is still unknown and more testing is needed.

I have released the updated suicide tester program over on CPS2shock (shown in the 2 videos above) to make testing easier. Also updated the original post, also to include links to the easier tester tool.

 

[SmokeMonster]

I get GOOD (1EAE, 1EAF) for every test on my CPS2 Multi, regardless of high or low voltage. I tested at 4.8V and 5.08V (20 minutes at 4.8V, 1 hour at 5.08V).

Multi CPS2: Latest Revision with the new sound fix by Mitsu
B-Board: Marvel vs Street Fighter (Revision 6, G-pal)
PSU: Happ Power Pro rated 20A at 5V, 8A at 12V.

Anyone measuring voltage from the PSU side should note my voltmeters. I have to crank mine to 5.44V just to get 5.08V on the PCB side. As has been mentioned several times, there's a major difference depending on where you measure it.

 

[Razoola]

That's great to hear though I'm a little concerned about you having to set 5.44v though just to read 5.08v on the PCB side. It makes you wonder what the volt reading was on the PCB side for the previous guy videos who read 5.08v on the PSU. He is waiting for a multi and will do the tests with the same 'b' board and PSU already tested. I'm hoping the results come back all ok.