Released and approved for TASVideos submissions
Ported from mednafen to Bizhawk by zeromus
Backgrounder
If you ever find a bug in psxhawk/octoshock, the first step is to test it in the latest mednafen to see if you have the same problem, if that test makes sense for the problem.
As usual, emuhawk can load .cue files directly for psx games, but ones including mp3s or apes or whatever will need to get run through discohawk.
CCD files are superior to bin/cue and should be preferred where available. But generally cue+sbi will be required for copy protected games, and redumped discs are most preferable despite being cue+bin.
Disc swapping is supported. To use it, load an m3u instead of a cue/ccd. It hasnt been proven by anyone for serious use yet, so beware. For information how to make an m3u file, refer to this forum post. Here's how it's supposed to look like when observing it in Notepad. The easier way exists though:
- Tools > Multi-disk Bundler.
To swap the disc, use the PSX > Disc Controls. It's a bit of an unusual interface, but I think it's a good one. You'll see that you can't change discs in one frame: this is physically impossible, therefore it cannot be emulated correctly. You must eject the disc and advance a frame. After that youll be able to set the next disc. Look at it this way: at one moment you press the eject button. Until time has passed, even at light-speed, the tray isnt open and the disc can't be swapped. Watch out! Some games (I think I saw this in FF7) may require more than one frame of time for it to properly detect a swap.
Discs are quickly identified from the gamedb using a custom approach involving the TOC and the first couple dozen data sectors. This might possibly not catch hacks or patches as distinct from the clean rip [1]. I'm looking for feedback on that. The "good" dumps are defined by redump.org. When using an M3U, the discs' IDs are checked and reported in the rom status display, but it isn't categorized as good or bad.
Here's the current differences between psxhawk and mednafen:
- Default rendering of the screen (scaling, filtering, etc.) doesn't match mednafen. You can change that option. I like mednafen's behaviour, but not as default, at the present.
- Input configuration is limited to one, two, or none standard gamepads, dualanalogs, or dual shocks
- Disc loading isn't done through mednafen's code; some games may be bugged or fail to load for that reason alone. It's usually not a hard fix.
- Savestates have been re-implemented, but theres nothing you can do with this information
- memory card isn't modular. It works similarly to the sram on other bizhawk cores, EXCEPT: loading a state does not automatically cause the contained memorycard to updated on your disk. It won't be updated unless the game saves something else to it. In other words, until you see the game say 'SAVING' then your memcard is untouched (actually, it isn't touched until the emulator or core closes or you flush the save ram, as per normal in bizhawk). This may be an unusual approach, but I'm trying it out.
- Bizhawk does not perform error correction on disc images like mednafen does. See more under 'Patches'
Here is a list of functionalities that are on-line for PSX, and some gotchas. If it's not working, we dont need you to tell us that it isn't working. if it's "working" but buggy, tell us.
Working:
- saveram
- savestates
- input
- memorydomains (ram tools & hex editor)
- lua getregisters
- auto-detection of PSX discs
- audio/video
- disc/tray management and swapping PAL/EU & JP regions
- virtual pad
- SBI files
- lag frame detection
- PSF
Not working:
- trace logger
- hooks/callbacks
Not fully validated:
- do cheats work?
Patches & Error Correction
PSX disc images are full of error correction data. Many patches (PPF, etc.) ("naive patches"[2] in the mednafen docs) will modify the actual data but not update the error correction data. This is a mistake. It works on many emulators, but would not work on a real console, because the console will spy the mismatch between the error correction and actual data, and 'repair' the actual data. So for example let's say a patch changed one byte containing your HP from 3 to 255. If it doesn't change the error correction data, the PSX (and mednafen) will say 'Oops, there's one byte wrong on the disc. Let me fix that for you.'
Bizhawk doesn't use this behaviour by default (but it can be enabled.) It's more accurate to do the error correction, but more annoying to gamers using lousy patches.
There's no excuse for PSX patches to be leaving off the error correction data. From what I can see, the best way to make a PPF patch is to use "PPF-Studio" ( http://www.romhacking.net/utilities/514/ ) which has an option (why isn't it enabled by default? That's a mistake.) to edit the error correction data as well.
Users with flawed PPF patches can use a utility called ECCRegen ( http://web.tiscali.it/eccregen/download.htm ) to fix their patched disc images. This will essentially say "I know the actual data is good and the error correction data is not matching it. Re-generate the error correction data"
As a technical side note, the ECC of XA discs doesn't cover the bytes 12-15 (LBA and mode) which should be cleared to zero before running the ECC. After this the ECC will 'repair' them always to zero, and then some other process (unclear whether it's in the XA/CDi specs or just PSX behaviour) will re-fill the LBA and mode fields.
Accuracy
Additional Resources
[1] Looking for feedback in the form of homebrews or romhacks that this malfunctions for. If needed, possible future work includes scanning the filesystem and hashing the structure of that + the game's EXE. This is easier than it sounds. So far I've found one case where a disc had been patched (only dozens of bytes) from it's pristine form, which we labeled a good dump--but the changes were all in the EXE, so the aforementioned approach wouldve covered it.