The above video goes away if you are a member and logged in, so log in now!
There will be improvement in visuals, as displaying at higher resolution doesn't take much more resources than displaying at native (except, when there is a lot of framebuffer access and more generally a lot of direct vram access. I guess it can be minimized by changing design a little bit). As for the speed... This is a little bit worse case . The code cannot run perfectly natively, as I need IOP to be in current, PS2 state for device accessing (mostly hdd and network). This alone leaves me with not too much of memory on IOP (not to say about horsepower, as other threads would take some of it from us). EE is much faster, but some translation is needed. The same for device access, which have to be either emulated, or sent to IOP by RPC, there dispatched by my code properly to the real device (like pad and sound, which are handled directly). The GPU is a project in itself. It's still not well coded, but let's call it "first approach". If it will prove useful (which I think it already did ) and efficient, I'll try to code it more low level (I believe, that simple packet translator could be possible for most cases, with some emulation for others). This is yet to be seen, as I haven't finished it yet.
Recently I had some nice idea. There is a lot of functions in code, that don't really have to be translated in any way... So I just detect them and replace calls with PS2 native code. This decreases overall compatibility a little bit, but makes some additional speedup possible. Not as much as I thought, but cache issues are quite big here... I have to place and use the code more efficiently. Right now small changes, like removing a single line of code, which makes less instructions being executed, can cause in fact 5-8% slowdown because of the cache issues, as the code is being compiled and placed differently by the compiler. The app itself isn't that big (~510kB the new one and ~540kB the old one), but the parts of code being used are scattered across the ram quite widely . This of course is also caused by another issue. The ram is divided between PSX space (which has addressing of it's own to speed up memory access) and PS2 space, so once PS2 native code is called from within PSX code, we're always getting misses. I guess that this part needs redesigning (though, at this point I cannot think of better method... using simple lookup tables for all ram access was simply too slow to be useful, and since PS2 has these nice hardware capabilities, I had to use it - which turned to be much faster than the lut approach).
Anyway, you should expect, that some games will never work at full speed with this method (I already have some candidates).
What's wrong with FF8 on PS2? I've played it some time ago, but I do not recall and real slowdowns. I just had to disable texture smoothing as it was screwing the display a little bit. The only problem I had, was grandia. At some points (dungeons, mostly in battles... but not only) it was freezing. At some point, after 90min dungeon exploring, it froze just before the save point. I was so pissed off, that I wrote savegame editor in 20minutes to get all the items I lost in my inventory and all the experience I lost... and the next time just pass through this dungeon without exploring .
that really reminds me of recent advancements in winUAE ;-)
Recently I had some nice idea. There is a lot of functions in code, that don't really have to be translated in any way... So I just detect them and replace calls with PS2 native code.
i guess that's just my subjective feeling.
What's wrong with FF8 on PS2? I've played it some time ago, but I do not recall and real slowdowns.
but i do feel that both wipeout 2097 and ff8 work more smoothly on psx than on ps2. the framerate feels more 'jerky' and some parts of the game seem to slow down at times - e.g. the fade-out effect in ff8 when you go between various areas of towns, or battle entering effect.
@ ffgriever - now that is some great news. Thanks for sharing that with the 'hungry dogs' like myself.
Originally Posted by Bootlegninja
I didn't expect a response from him, much less so detailed!
To err is human. To really foul up requires a computer.
Thanx for the answers ffgriever,and to those who had to have a whinge about someone asking a perfectly legit question about something happening in the PS2 scene well "---- ---" fill in the blanks yourselves!
I just now realized what I posted. I had a lil' too much vodka in my system and had just finished arguing w/ my girlfriend. Shows me to post under the influence...
Could there be a way to convert the old "NeoKey" code into a .elf to boot ps1 backups? This question might be ignorant/stupid/crazy but came to my mind since it was a usb device and would direct boot ps1 backups...
It was only a 12c508 with the neo 2.2 code, I remember I made my own for like 8 bucks... LOL...
Please don't flame me too hard if my question is out of whack... LOL..
For the multibillionth time , that is completely impossible.
Originally Posted by gyigyo
Such PS2 programs can not remain resident and working after the console switches to PS1 mode.
Just accept that fact, as it is unalterable.
If you really want to revive an obsolete disc-swapping method, then I suggest doing that in some other forum, as it has nothing to do with FMCB-related topics. Sure, most disc-swapping methods will continue to work regardless of FMCB being installed or not, so what else is new...?
Best regards: dlanor