Сказать что-либо более осмысленное религия не позволяет?

Может еще и книжки вам расжевывать. Эмуль жрет 28 мб, только потому что ему надо эмулировать проц и озу. А не потому что каким то магическим образом там появятся какие то мифические фишки о которых вы писали выше. В лучшем случае увеличится скорость загрузки игр. Да и то не факт

Dyons, вообще-то Dimmписал , что будет сглаживание

The emulator itself (lets call it "the core") won't have any complex GUI at all. Just some simple text based menu, allowing user to do some basic operations (take screenshot, save, load, change disc, reset emulator, shutdown console, exit to external app, exit to the actual GUI).

The actual GUI will be a separate application, that will serve as configurator and launcher for the core. Why this way, you ask? Well, there are many reasons, but two of them are the most important.

1. The GUI for the project might be quite complex. I'd rather use c++ for it, as it's much easier to use for this kind of stuff. Plus the new universal GUI framework I work on is written in c++ (it will work on both PS2 and Windows, which I need for some other project I'm working on). On the other hand, the overhead in the compiled c++ code makes the whole emulator work muuuch slower (plus the core requires a lot of changes to compile at all as c++ ). When it comes to the lowest level, the pure c aided by direct assembly is much easier to work with (and much more efficient).

2. The memory the GUI will use would most likely need some huge changes to the core. The PS2 has 32MB of main RAM and I'm emulating a machine that has just 2MBytes, so what's the problem? Well, it's not actually that straightforward as you might think.

Let's start with the PSX Vram emulation. It is only 1MByte, right? True, but to emulate it efficiently I need few times this much. Why? Let me explain:

The PSX Vram is divided into texture pages. Each is 256x256 pixels regardless of the pixel depth. So you might think it would mean the Vram has only 4x2 16bit pages, 8x2 8bit pages and 16x2 4bit pages? Far from it! Each page can start horizontally at the multiple of 64 halfords (2bytes, because the PSX Vram can be treated as 1024x512x16bpp area) and vertically at the multiple of 256. A primitive can use only texture in one texture page. The texture pages can overlap (so, eg. you can have 64x256x16bit texture in page (0,0) and 256x256x4bit in page (1,0) ). Additionally, at the time the texture/clut data is being sent to the Vram, you have no idea, which bit depth it is in. You will know it only at the primitive drawing time. So, to emulate the Vram efficiently, you have to allocate:

32 256x256 16bit texture pages (4MBytes)
32 256x256 8bit texture pages (2Mbytes)
32 256x256 4bit texture pages (1MByte )
+ 1MByte for the actual PSX Vram Memory to store the data before we will know what depth the texture has.

That means 8 freaking MBytes to emulate 1MByte of PSX Vram! Quite a lot, isn't it? Couldn't it use less memory? Well, it could, but it wouldn't be as efficient as it is now (my PS2 Vram manager takes care of everything, so the LRU algorithm for texture storage in PS2 Vram is used - only 4MBytes of Vram on PS2 and we need two display buffers of 640x512x32bit/16bit !).

And no. You can't just allocate it as one texture in PS2 Vram. There are few problems, but some are most important. You would need 4096x512 texture for 4bit, but PS2 supports 1024 size max. The other problem is that you can't just store it as 16bit and then use it as 4bit or 8bit. PS2 Stores the texture formats quite different in the vram. You could swizzle them properly and still load 4bit as 32bit, but that gives some additional problems, not to mention that at the load time you have now idea of the depth. This approach is a no go anyway.

That's what we need for textures. But there are also CLUTs that we have to take care of. I coded clut cache that has some fixed entries. The cluts are replaced by the LRU algorithm. The cache right now uses 256kBytes. But it's not perfect. If the clut has changed or has not yet been uploaded to PS2 Vram (or has been replaced in Vram by some other clut by the Vram manager), it is loaded just before the first primitive using it is being drawn. That's usually fine. But consider a situation, when a game uses in single frame a lot more cluts that can be placed in the cache. It could lead to the situation, when a clut is least recently used, but it has still not been uploaded to the Vram. Now the cache buffer is being changed... What's the result? Well, a texture is being displayed as garbage, as there is wrong clut uploaded. That's quite uncommon situation, but happens in some games. The LRU algorithm is quite efficient (bidirectional lists with pointers to cache entries, the used one moved to the top, etc., basic coding stuff... designed to make both LRU algo and cache search as efficient as possible). Searching the cache to check whether currently needed clut is already in cache is a little bit slower, but still quite fast). I can't extend the cache, as searching for cache hits will become too slow. I also can't make it the way I did for texture, as clut can begin at the multiple of 8 halfords horizontaly and 1 vertically. I would need some dirty flags, entries for LRU algo... That would simply need a lot of additional RAM, that I don't have right now. I will think of a way to make it efficient while still not affected by the situation described above.

That's the PSX Vram.

Now you need 2MBytes for the actual PSX Ram, 512KBytes for the ROM, scratchpad, SPU memory, parallel area, hardware mapped stuff. There are also lookup pages for many things to increase efficiency... Quite a lot of memory to even do the very basic emulation (eg. in interpreter mode)! The lookup tables are not used for PSX memory access, neither for PSX hardware access (thanks to PS2 incredible TLB configuration capabilities, I can simply access the memory and emulated hardware directly, without using any lookup tables... though for writes I have to do some additional stuff to make sure the self modifying code does work on the emulator).

Now, the interpreter would be quite slow, so we need a dynamic binary translator (recompiler). So we need additional memory for the recompiled code. Most of the games would need at most 2-3MBytes, but if the game uses self modifying code (or sort of plugin systems, when there is main executable and then it loads others to do some specific stuff), it needs much more, because otherwise the emulator would need to flush the entire cache too often. So right now I allocated 8MBytes for it.

Most of the caches need specific alignment. Because of the TLB requirements, some of them have to be even aligned to 1Mbyte boundary (the main PSX Ram, which is then mapped using two halfentries along with the process id, so it doesn't overlap with the main ps2 processes, that can access their own, usual mappings - that actually needed some additional work, because the PS2 was hanging at interrupts and other stuff, but it wasn't that hard to do). I did as much as I could to minimize the memory lost due to alignment, but some is still being wasted.

There is also some other stuff to make the emulation efficient. Some intermediate buffers, cdrom buffer (small on iop, a lot bigger on ee side). Then the memory used by the emulator itself (~500kB, pure code, as only 128x128x4bit - 8kB - font is embedded).

Putting everything together, the core uses now almost (or even above? I didn't check it recently ) 28MBytes of memory! It could be coded to conserve the memory, but I'm sure you will agree with me on the point, that I should prefer the efficiency over memory usage, right?

So there is no space for the complex GUI in the core. Of course I could free the dynamically allocated memory, load the GFX for the time GUI is being displayed, then free again, reallocate, rebuild buffers, etc, etc. But that would cause some problems. GUI access would be quite slow (need to load everything from mc/usb/hdd every time), it could eventually lead to memory fragmentation, so it might not be possible to allocate the needed memory block (especially at specific boundaries). There are also some other problems, because some buffers cannot be deallocated inside the PSX code... But once the used code is recompiled, the emu won't actually leave the PSX code until the code has changed or new code is being executed (the PS2 code is being called from within PSX code!).

So as you see it's a lot more complex that you might have thought it was. That's why the core will have just the basic interface, and the main GUI will have to be separate application used for configuring and launching. But I believe it doesn't pose any usibility issues. You will still be able to configure everything, then play the game, do all the stuff you need and return to the GUI if you need to reconfigure...

Shoot! I was going to write a lot more, but the text has already reached 8kB boundary (hmm... almost 8.6 actually). I will stop here, as it might be too much and too boring to read. .

Yeah, well, I hope it's understandable.

На psx-scene внедряют языковые файлы в эмулятор пс1,может кто попросит текст для перевода на "великий и могучий"?