Psx4gp2x Public Beta 2

[hackgrid]

Update

Hi everyone,

Guess yesterday was bad timing for an unexpected day off. ;P
It was a "fall asleep in the computer chair" work-day.

I got a lot of work done on the dynarec. It's compatibility has been "touchy" as of late, due to the Serial IO (SIO) timings. It seems some games are more sensitive to it than others, as has been noted in past versions. Well with the dynarec, I have been able to get memory cards working with a certain timing, and controls working with a different timing. Or in one case I'm able to get both working great for half the games, and it makes the other half crash. So I'm trying to get the timings right.

Why get the timings right and not just release a dynarec version with only half the games working? Well the dynarec isn't currently giving any sort of amazing speeds when getting in-game. It's not the methods fault, but most likely the implementation. I need to work at getting the timings right, and get the very unoptimized dynarec code working smoother.

For now I've run FF7 and Einhander successfully. Both run faster than before. I can't do a 1:1 FPS speedtest as I'm using a different GPU revision than Beta 2 with a more precise FPS reader. Einhander is faster by about 7 frames per second, sometimes 10+. It ranges between 23 FPS to 30-35 FPS in-game. This test was done with a 266MHz OC. FF7 seems faster, or should I say smoother feeling. It seems like it's drawing in a lot more frames due to timing differences, but still retains a bit faster speed of beta 2. So with correct timings alone, FF7 should see a speed increase with the dynarec.

So the dynarec is still in need of some work until I have it running at speeds I find acceptable. But the potential is there, and easily in reach. Once I figure out the timings needed, it will make working with the dynarec a lot better, as games I normally test with won't work with the current timings.

Btw, the DC is a great console, especially for shoot-em-ups / shmups. smile.gif

So a bit more waiting and you'll see a nice revision of psx4gp2x with a speedy dynarec. Patience. wink.gif

 

[sakura13]

Schade immer noch kein releas, naja lass ihn mal schaffen je länger wir warten desto besser wird der emu. Was meint ihr zur entwicklung, kann man den dynrec eigentlich auch für snes emu verwenden und wie genau funktionuert der dynrec?

 

[sbock]

Schade immer noch kein releas, naja lass ihn mal schaffen je länger wir warten desto besser wird der emu. Was meint ihr zur entwicklung, kann man den dynrec eigentlich auch für snes emu verwenden und wie genau funktionuert der dynrec?

Klar. Einen Dynarec kann man für alle CPUs schreiben. Nur bringt das beim SNES nicht sonderlich viel, da die CPU Emulation nicht wie beim PSX Emulator der Flaschenhals ist. Beim SNES sind eher die komplexe Video-Emulation bzw. die Zusatzchips in manchen Modulen das Problem.

Infos zum Dynarec:
http://en.wikipedia.org/wiki/Dynarec

Gruß,
Stephan

 

[fusion_power]

Soweit ich des verstanden habe (Fachtexte in Englisch-ürks :lol: ) meint dynarec die dymamische Neukompilierung von Code während der Laufzeit oder?
Das klingt aber ehr nach Mehrarbeit für die CPU. Dass sowas nen Geschwindigkeitsvorteil bringen soll find ich schon erstaunlich. Was genau ist der effiziente Kern der Sache? (Für Laien?)

 

[sbock]

Soweit ich des verstanden habe (Fachtexte in Englisch-ürks :lol: ) meint dynarec die dymamische Neukompilierung von Code während der Laufzeit oder?
Das klingt aber ehr nach Mehrarbeit für die CPU. Dass sowas nen Geschwindigkeitsvorteil bringen soll find ich schon erstaunlich. Was genau ist der effiziente Kern der Sache? (Für Laien?)

Ziel des ganzen Aufwandes ist es, möglichst effizenten Code zu erzeugen. Durch analysisieren des Codes bei Laufzeit versucht der Dynarec z.B. Befehle zusammenzufassen und so quasi eine Abkürzung im Programmablauf zu erwirken. Man versucht auf diese Weise die Stärken der System CPU (Im Falle des GP2x die ARM Architektur) voll auszunutzen.

Gruß,
Stephan

 

[Nr.56]

Soweit ich des verstanden habe (Fachtexte in Englisch-ürks :lol: ) meint dynarec die dymamische Neukompilierung von Code während der Laufzeit oder?
Das klingt aber ehr nach Mehrarbeit für die CPU. Dass sowas nen Geschwindigkeitsvorteil bringen soll find ich schon erstaunlich. Was genau ist der effiziente Kern der Sache? (Für Laien?)

Der Vorteil wird darin liegen, das der Arm-Prozessor des GP2X Arm-Code ausführen kann, und damit seine Leistingsvorteile ausspielt. Er bekommt auf ihn optimierten Code und nicht blind übersetzte Befehlsfolgen. Der Arm Prozessor ist deutlich Leistungsstärker als der Mips-Prozessor der PSX, wenn er für ihn optimierten Code empfängt. Abzüglich der "Verlustleistung" für den Dynarec sollte ein deutliches Geschwindigkeitsplus im Vergleich zum Interpreter bleiben. Allerdings muß ein Dynarec genau optimiert sein, um keine Kompatibilitätsprobleme zu erzeugen. Zodttd´s Dynarec erreichte denn auch im ersten Test (noch nicht sonderlich optimiert) 6 Frames mehr aber er hat zur Zeit noch die erwähnten Kompatibilitätsprobleme, deshalb gibt es auch noch keine neue Testversion. Mal abwarten und hoffen, das er so fleißig bleibt. :wink:

EDIT: zu langsam :lol:

 

[fusion_power]

Na auf alle Fälle SEHR interessant. ^^ ich bin immer für Optimierungen. Ist ja heutzutage keineswegs mehr Standard beim entwickeln.

Wenn man den PSX Emu komplett in ARM-Assembler schreiben würde, währ des dann noch effizienter?

 

[sbock]

Na auf alle Fälle SEHR interessant. ^^ ich bin immer für Optimierungen. Ist ja heutzutage keineswegs mehr Standard beim entwickeln.

Wenn man den PSX Emu komplett in ARM-Assembler schreiben würde, währ des dann noch effizienter?

Mal abgesehen davon, daß man wohl heute kaum noch Leute findet die ein ganzes Projekt wie Psx4all in Assembler programmieren, macht das auch überhaupt keinen Sinn. Außerdem ist es ein weitverbreiteter Irrglaube, daß ein Programm alleine durch Assembler schneller wird. Da man beim Benutzen von Assembler sehr viel mehr Dinge als Programmierer beachten muß als bei Hochsprachen kann das Ergebnis auch schon mal nach hinten losgehen.
Es gibt sicherlich einige zeitkritische Bereiche in dem Emulator, bei denen Assembler sinnvoll ist. Chui vom Psx4all Team hat afaik auch schon einige Bereiche in Assembler optimiert. Welche das genau sind, hat er allerdings nicht geschrieben.
Es gibt aber auch Bereiche (allem voran z.B. die GUI) wo die Benutzung von Assembler einfach nur Blödsinn ist, da man das gleiche Ergebnis auch mit viel weniger Aufwand und viel bequemer errreichen kann...

Gruß,
Stephan

 

[fusion_power]

OK.
Es ist natürlich abartig, alles von Hand in Assembler zu machen. Ich hab ehr an Programme gedacht, welche "normalen" Code in wirklich optimalen ARM-Assembler übersetzen können. Obs sowas gibt bezweifle ich.

Ich hab heute noch Alpträume von meiner Ausbildung. Neben C und Turbopascal hatten wir auch x86 Assembler. HORROR!!! Und das dann auch noch in der Prüfung. Also ich weiß wirklich, dass Assembler hart ist.
Aber er KANN natürlich effektiv sein.

Warten wir ab, was die Progger noch so alles aus dem Emu raus holen können. Liest sich alles schon vielversprechend. ^_^

 

[sbock]

Mal wieder gute Neuigkeiten von Zodttd:

Nice, I see some new people joining the discussion. Glad to see
you.

I think it was emudev that had a great dynarec discussion going by someone who gave detailed posts about how it worked. Definitely good read.

MattPurland: It surely is a good thing. Unai has done an excellent job with the GPU and his expierence shows. Speaking of his GPU, I recently tested a revision of his latest GPU and performance has increased quite a bit. I noticed a 10% increase in speed, and another 10% on top of that can be had with new assembly he's written. He's picked up ARM assembly very quickly too! So from one game I tested that was 28 FPS (a 2D game btw) in-game became 32 FPS with the first revision, with this latest revision I'm expecting it to be around 36 FPS from what Unai has indicated. Either way, he's doing a great job and the framerates show that. ;P

For the dynarec, I am doing two things at once. I'm trying to get compatibility where it's needed while at the same time slowly/carefully adding optimizations in. Unai recommended some ideas for the dynarec which I will try to get working tommorow that should improve performance.

I was expecting 3D games to be less effected by the dynarec than 2D games since the "GTE" itself (engine used by the PS1 to calculate 3D geometry) isn't currently being recompiled, and is instead being recompiled into a function call to the C implementation. It will be recompiled soon enough. It seems that 3D games are showing a better performance increase than 2D games currently, though that's not concrete information since there's a lot of ugly code to remove in terms of the interrupts that will affect performance in a positive way.

That's all for today. Tommorow more work will be done.

Sieht so aus, als ob in den beiden Bereichen CPU und GPU noch viel Raum zum Optimieren steckt und die Entwicklung stetig weitergeht.
Außerdem wissen wir nun, daß auch Unai-i einige Bereiche in Assembler optimiert. Freue mich schon auf einen neuen Release des Emulators...

Gruß,
Stephan

 

[sakura13]

Hmm meint ihr das die emulation hinther so perfekt ist das fast alle spiele spielbar sind und rpgs in full speed? Und was meint ihr wieviel zeit wird noch bis zum release verstreichen...

 

[1nf1n1ty]

Das sind echt geile Neuigkeiten Ich freue mich, dass es so gut vorangeht und hoffe auf ein baldies Release. Echt gute Arbeit!

 

[sbock]

Hmm meint ihr das die emulation hinther so perfekt ist das fast alle spiele spielbar sind und rpgs in full speed? Und was meint ihr wieviel zeit wird noch bis zum release verstreichen...

Sehr schwer zu sagen... Ich denke mal, daß die Kompatibilität eher eingeschränkt bleiben wird und nicht alle Spiele in Fullspeed laufen werden.
Es wäre meiner Meinung etwas zu optimistisch nahe 100% Lauffähige Games ohne Geschwindigkeitseinbußen zu erwarten...
Ich persönlich bin schon mehr als zufrieden wenn die Serien Resident Evil und Parasite Eve spielbar mit Sound möglich sind.
Die Zeit bis zum Release ist auch unmöglich vorherzusagen. Früher hat Zodttd quasi jede Woche ein Update mit kleinen Änderungen herrausgebracht. Heute ist er eher dazu übergegangen zu warten bis das Release möglichst stabil ist.

Gruß,
Stephan

 

[Nr.56]

Hmm meint ihr das die emulation hinther so perfekt ist das fast alle spiele spielbar sind und rpgs in full speed? Und was meint ihr wieviel zeit wird noch bis zum release verstreichen...

Sehr schwer zu sagen... Ich denke mal, daß die Kompatibilität eher eingeschränkt bleiben wird und nicht alle Spiele in Fullspeed laufen werden.
Es wäre meiner Meinung etwas zu optimistisch nahe 100% Lauffähige Games ohne Geschwindigkeitseinbußen zu erwarten...
Ich persönlich bin schon mehr als zufrieden wenn die Serien Resident Evil und Parasite Eve spielbar mit Sound möglich sind.
Die Zeit bis zum Release ist auch unmöglich vorherzusagen. Früher hat Zodttd quasi jede Woche ein Update mit kleinen Änderungen herrausgebracht. Heute ist er eher dazu übergegangen zu warten bis das Release möglichst stabil ist.

Gruß,
Stephan

Du hast sicher mehr Einblick in die Technik und die Programmierung als ich, aber ich bin schon der Meinung, das die Mehrzahl der tatsächlich genutzten Spiele spielbar laufen wird (Und der angesprochene Faktor 2-3 sind ein riesiger Sprung in diese Richtung). Ich denke das die Masse der User ca. 20 favorisierte Spiele hat. In Anbetracht der verschiedenen Geschmäcker würde ich die Anzahl der tatsächlich gespielten Titel auf höchstens 200 schätzen. Im englischen Thread zum Thema habe ich mal von "allen"Spielen gesprochen und habe dafür Prügel bezogen. :lol:
PS: für mich ist der Ton ehrlich gesagt dabei nicht von primärem Interesse. Geschwindigkeit und Grafikqualität gehen vor und vielleicht gibt es ja wirklich irgendwann einen Soundserver, der auf der 2.CPU läuft (..und damit nicht mehr bremst).
Ich bleibe zuversichtlich! :wink:

 

[hackgrid]

Oh sorry for the lack of updates. I worked myself sick trying to find out what is causing crashes in the cdrom handling code. I finally figured it out, and now I just need to fix it.

With the cdrom code fixed, underclocking will be easier to do and be able to be pushed much further. For instance, on a scale of 1 to 64, underclocking maxes out at 4 currently. Soon it will be able to reach the 32-64 range, which means a large speed increase whether using a dynarec or not. It also will mean the end of "fixing timings". I removed the need for one interrupt timing mess, and the only one left is this dumb cdrom code I've been dealing with the past week.

Btw, I clocked a framerate of 93+ FPS (not VSync, FPS) in Buster Bros with underclocking set at that midrange "32 out of 64". Now keep in mind the GP2X was OCed to 266 and this was in the intro of the game, not in-game. I saw it though. smile.gif

Oh, with some of the cdrom mess sorted out, other performance enhancements can be made to that area. The timings are the first to get sorted out since whats taking up a lot of time in emulation is actually waiting for the CDROM Interrupt to sync with the reading of the ISO itself. Sounds silly and it is.

The dynarec works btw, with only a small percentage of instructions not recompiled, things are going good for it. It needs a lot of optimizations though, as it has a lot of unneeded overhead.

Once I get the CDROM mess finished, a release will be coming very soon afterwards. I know Unai wants to do some more work on the GPU as well. I think the benefits of getting this sorted out first will be worth the wait.

Oh yeah...my GP2X First Edition is dying. It sometimes takes 5 tries to boot it up even shortly after putting in new batteries. It doesn't crash, the screen fuzz's out and it makes an ugly sound. And now it's starting not to recognize the SD card. Part of the boot problem seems related to a loose power switch. It's ok though. smile.gif

Stupid cdrom code! Back to work...

 

[Devaux]

Oh yeah...my GP2X First Edition is dying. It sometimes takes 5 tries to boot it up even shortly after putting in new batteries. It doesn't crash, the screen fuzz's out and it makes an ugly sound. And now it's starting not to recognize the SD card. Part of the boot problem seems related to a loose power switch. It's ok though

Hmm. Ob das ein stiller Aufruf zum Spenden ist?

 

[RepaYne]

Oh yeah...my GP2X First Edition is dying. It sometimes takes 5 tries to boot it up even shortly after putting in new batteries. It doesn't crash, the screen fuzz's out and it makes an ugly sound. And now it's starting not to recognize the SD card. Part of the boot problem seems related to a loose power switch. It's ok though

Hmm. Ob das ein stiller Aufruf zum Spenden ist?

Sieht ganz danach aus :roll:

Aber wenn er wirklich so gebuckelt hat wie er schreibt und das Ding gut spielbar läuft mit Sound, so dürfte das jedem wohl nen 1 Euro wert sein. :wink:

(Ich geh mal davon aus, daß 200 Leute spenden)

 

[Seraptin]

hm ich frag mich was da kaputt geht :/

Und wenn er kaputtgeht ist das wohl nen garantiefall

 

[hackgrid]

Heh Drak! I did the same thing, took my GP2X apart and put it back together when it stopped working. Then it works sometimes really well and other times not so well.

Anyways...I GOT THE BUG FIXED! FINALLY! This is an awesome bug fix, since it will allow for much better underclocking, as well as allow the dynarec to be tested. The culprit wasn't the CDROM but actually the SPU. The SPU (sound) emulation was faulty, and it might actually be related to it's timings. There was a part of the sound emulation that wasn't disabled, and that's why even with the best timings I could figure out, at times such as in FF7 after the intro, when certain sounds starts the emulator just crashed!

So this next release will not only have a dynarec (though an underperforming one possibly), but will be MUCH more stable!

Time to test the dynarec and see how it performs...Will post results as soon as I'm done testing it for a little bit!

Yay!

 

[Vimacs]

Schlechte neuigkeiten :-(

Very sad news...

My GP2X is now barely working, and if I do get it to work, it's not stable at all. When I did my tests before it died, the dynarec was going the same speed as the interpreter in most areas. I might be able to test the ARM Dynarec and continue improving it without the need of a GP2X, but it will be a very slow process. I'm pretty upset. I'll see if Unai can continue the entire psx4all project while I figure out how/if I'll get another GP2X. I'll make sure Unai / Tinnus get the latest version of the code with my bugfixes in it, and if Unai decide not to continue the project I'll make sure the source is released so it can continue to be worked on. Hopefully I'll be able to return to working on the GP2X.

Ed, rette ihn