Printable View
Ha, ha. You're right ;). The most common are bin+cue (cdrwin) and img+ccd+sub (clonecd). The subs and cues/ccds are not necessary (they can even cause some issues due to a very basic ccd/cue parser). Both supported by imgburn. Mdf can also be 2352, but doesn't have to (AFAIK, it can even contain some headers).Quote:
Originally Posted by Bas
They're grayed out because they're not implemented yet ;). I was going to do that but didn't have the time. I'd rather put more time into the emulator itself than the launcher. Thanks to all the responses here, I've got quite a list of issues to fix in the GUI. Once I'm done with the sound emulation, I'll try to fix the GUI issues and implement per game config + auto psx option (video mode depending on the game region, the best choice - it now doesn't work at all and simply forces PAL ;) ).Quote:
Originally Posted by GermanTom
@all
If you were wondering why there wasn't any release this week... I didn't finish the XA playback. It works, but is not good enough. It still sometimes stops playing all of the sudden (no more interrupts at some point so the SPU repeats current adpcm buffer over and over) and can completely freeze the game when running at speeds higher than 100%. I hope I'll be able to finish it this week. When that's done, the sound emulation will be pretty much complete (well, there is still CDDA support missing, but it still lacks the support on cdrom emulation side, while for the XA I had the cdrom support ready for the software sound emulation).
XA shouldn't slow anything down too much. There is no direct support for that on PS2, but I at least don't have to decode it to PCM, as PS2 supports ADPCM playback. I just "demangle" every 14 bytes of adpcm data from a frame and add two bytes with the shift+range (this is available at the beginning of the frame) and flag at the beginning to make it standard adpcm which ps2 can play just fine (plus waiting for interrupts, writing to the right buffer at the right time and changing voice loop addresses properly). This uses two voices on core 1, but that doesn't matter, as my PSX SPU "plugin" uses only core0, so I can use the other one the way I want. As for CDDA... It's 44100Hz, 16 bit PCM. I'll have to scale it to 48kHz to make it play at right speed and pitch (it's easy with ADPCM, because all you have to do is changing pitch register for the voice, but with PCM there is no easy way, I have to scale it... Well, I could encode it to adpcm, but that would use few times that much CPU resources than even simple scaling). But I'll leave CDDA for now.
Right now it is slower, but there is a lot of sound debug stuff being printed all the time.
This week I didn't have too much time to work on it either. But here is a test version with XA support. In some games it works quite well, yet in others it's one big disaster. From time to time, when skipping XA (either audio only or video+audio), the SPU2 will enter a state, when it no longer lets me send any data to it. I don't know yet why this happens, but the only way to fix that is reset your PS2 (emulator reset doesn't do the trick... even launching a ps2 game doesn't fix that... the sound is borked anyway). The XA isn't cut off properly if a game doesn't mute XA/CDrom. But since I won't be able to fix that this week, I decided to post the new test version anyway.
The proper XA muting is already done.
As for PAL/NTSC. The PAL recommendation is from an old version. Now the only recommendation is to play PAL games in PAL mode and NTSC games in NTSC mode... Soon even that won't be necessary (even if you don't do it, the result is some black horizontal bars being displayed in some games). Sure, NTSC games might work relatively slower, but even that is not a set rule (it really depends on game).
Cheat engine is possible, though I have no intention to do that. There is a ton of serious issues that need to be fixed... And whole parts of emulation missing ;) (eg. CDDA playback, drawing outside of the screenbuffer, proper screenbuffer fetches and writes... and a lot more)
Project has been temporarily put on hold (again). Will get back to it ASAP.
Where has the old good, big, hard to navigate and useless thread gone? Nevermind.
I'm not dead nor anything like that (just in case anyone wondered ;) ). I'll try to make it short:
I am not going to work on PS2PSXe anymore. Right now I'm occupied with another project, so you'll most likely hear from me again sooner or later.
Yes, most recent public r202 had some additional issues that were introduced with the hw XA playback code.
Yes, I guess I can publish the source code (or hand it over to someone). I should have somewhere all the most recent source as well as full svn repository (going back to one of the very first non-public, non-operational versions). But... (yup, this word tends to be annoiyng) It seems that some time ago I lost all the changes I made to ps2sdk and gskit (I did a proper backup of the application's sources, but never backed up my ps2sdk/gskit sources nor binaries - I considered it all temporary solution - which remained permanent ;) )... And since the application relies heavily on the changes, it doesn't compile at all (actually, it is quite easy to make it compile, but not so easy to make it work). I probably could redo all the changes, provided I had sufficient time and will. So it would require some work to even make it work the way it did at the most recent r209.
The main problem is, that it still isn't fast enough and I can't think of a good way to make it considerably faster (except for scraping all the code and starting anew). Most of the issues are fixable, but would make the app even slower.
The CPU emulation is quite efficient (there is still some nasty bug in the recompiler, though). The dynamic recompiler does it's work quite well. There is no virtualization support on PS2, so it has to be a recompiler, which has some limitations (even though it's few times faster than interpreter... which is no longer present at all in the app - was scrapped at very early stage). Branches could be made faster (a lot of checks during branches - interrupts and stuff) and here is a good place to start. The PSX registers are allocated quite efficiently to saved hardware PS2 registers (and in some cases, when there is no need to preserve the values or register is used for computation between memory reads and writes - which can cause a hw related function being called - in temporary registers). There are some check to even optimize multiple blocks (to not flush the registers to memory between blocks).
The memory layout is being totally remapped (using hw TLB capabilities), to make it as close to PSX memory map as possible, including mapping (not really a good word in this case) PSX registers and trapping them properly. So even though in recompiled code, there is simple write (sw) to a PSX memory mapped hardware, appropriate PS2 emulation functions are being called instead of simple write being done (this saves a lot of time for checking every write and read for hardware access, thus the need to either exit recompiled code to a PS2 function at every single write/read, or make the recompiled code huge, thus causing more cache issues). To make it even faster, checking for code self modifications is stripped to bare minimum, which is still enough to make it pass in most of the cases).
The SPU is mostly "translated" not emulated (no speed decrease at all).
PAD is being translated instead of emulating it. Memory cards are emulated (but all the sio emulation is simple enough, to not cause any speed issues).
The GPU emulation (although bugged), could be improved (speed wise)... Yet not as much as we need. The GS is configurable enough to support all PSX capabilities (not directly, but at very minimum cost) - (all the blending functions, texture windows, etc, that can be set up to work exactly as on PSX - on PC it's usually done with pixel shaders, so it's not a big deal, but since PS2 doesn't support that, it could become a chore, if the functionality wasn't there).
CDROM access is not a big deal (separate IOP thread that feeds EE with data in asynchronous mode) - doesn't cause to much trouble.
MDECS are being decoded (and color space transformed) using IPU hardware capabilities. It's fast enough to run at really good framerates, but is being held back by the CPU emulation taking place at the same time.
I still consider it quite fast (at least comparing to other emulators running at 300MHz CPU with 32MB of ram - heck, even the PS3 port of pcsx - PS3x was it? - wasn't fast enough to make all the games run at 100%... It was using software GPU emulation and no SPEs, though)... Though it definitely could be faster. But it doesn't matter that much, since it's bugged as hell.
But, since I lost interest in the project anyway, it doesn't really matter that much. I simply wanted to write few words, saying where the project has actually stopped.