ePSXe recreates the original PlayStation console in software so a computer or phone can run game data taken from discs the user owns. It translates console CPU instructions, graphics calls, controller input, audio, memory cards, and disc access into operations the host device can perform. Opening a disc image in the operating system only exposes files; ePSXe interprets that image as a console disc and supplies the missing PlayStation hardware around it.
Bring the console parts
ePSXe does not arrive as a complete game library. The user supplies game images and a legally owned PlayStation BIOS. The BIOS contains console startup code and system routines, while the game image contains the disc data. Selecting an executable file from inside a disc dump does not replace either part.
Desktop setup also separates video, sound, and CD-ROM behavior. A video plug-in controls how ePSXe turns PlayStation graphics into the host display. Internal components handle common sound and disc access, and external plug-ins remain available for different hardware or compatibility needs. A change that fixes one game can introduce visual or timing faults in another, so one global configuration may not fit the whole library.
Disc images matter
ePSXe reads several image layouts, among them cue/bin, img/ccd, mds/mdf, pbp, nrg, cdi, ecm, and iso. These names describe more than filename endings. A cue sheet can map multiple data and audio tracks stored in separate bin files. Loading only the first bin file may start a game while dropping music or later tracks.
Multi-disc titles need an image for each disc and a deliberate disc-change action at the point the game requests it. Renaming unrelated images to look like one set does not create the links the game expects. Compressed or converted images can also fail when the conversion loses track information, so keeping the original dump beside any smaller copy avoids a difficult recovery later.
Two save systems
Memory cards behave like the console accessory. Games write their own save blocks to shared card files, and those cards persist after ePSXe closes. Save states capture the emulator’s complete running condition at a particular moment. They resume faster, but they depend more closely on emulator behavior and should not replace an in-game memory-card save.
The shared card design creates a practical risk: damage to one card file can affect saves from several games. The documentation recommends backups. Copying the card files while ePSXe is closed avoids catching a write in progress. Save states also need care during upgrades because a state created under one execution path may not reopen cleanly under another.
Input and sound
ePSXe maps physical controllers or on-screen touch controls to PlayStation buttons. A gamepad that works in the operating system still needs the correct button assignment inside the emulator. Analog mode matters for titles that distinguish the original digital pad from later analog controllers.
Audio settings trade delay against workload. A larger buffer gives ePSXe more time to produce sound and can reduce crackle, but button presses may feel less immediate. A low-latency buffer shortens that delay and asks more of the CPU. Video accuracy, frame pacing, and sound timing therefore need to be judged together rather than tuned as isolated quality sliders.
Android storage
On recent Android releases, ePSXe cannot freely scan every folder. The user selects a base folder through the system file picker and grants access to it. Placing the BIOS or game images outside that approved location can make them appear missing even though another file manager can see them. Keeping disc sets, card backups, and the BIOS in a planned folder tree makes later device moves easier.
