Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding CSO support to HPSX64 #28

Closed
Zero3K opened this issue Dec 24, 2018 · 7 comments
Closed

Adding CSO support to HPSX64 #28

Zero3K opened this issue Dec 24, 2018 · 7 comments

Comments

@Zero3K
Copy link

Zero3K commented Dec 24, 2018

It would be nice if that were done for the PS2 emulator that is a part of it (and the PS1 emulator that is a part of it if possible). Its links are as follows:

Homepage: https://sourceforge.net/projects/hpsx64/
Source Code: https://github.com/Zero3K/hpsx64

@unknownbrackets
Copy link
Owner

From a quick search of the code, I guess it would be here:
https://github.com/Zero3K/hpsx64/blob/48a8bf5eb39f91370a9e155cdd4aebbf3e209077/common/DiskImage/cd/src/cdimage.cpp#L2033

I'm not sure I'm likely to look into this soon, but CSO is pretty darn simple. You can see PPSSPP's code here:
https://github.com/hrydgard/ppsspp/blob/master/Core/FileSystems/BlockDevices.cpp#L216-L288

It's in Play! and PCSX2, with a similar implementation, matching the format documented in README_CSO.md.

-[Unknown]

@unknownbrackets
Copy link
Owner

Anyway, since this isn't really an issue in PPSSPP itself (more like an issue in hpsx64), I'm going to close it.

The code in maxcso to read / write CSOs is more complicated, because it uses multiple simultaneous threads for maximum throughput when decompressing / compressing. I don't recommend using it as a model to implement CSO reading in an emulator.

-[Unknown]

@Zero3K
Copy link
Author

Zero3K commented Dec 25, 2018

How would I (or someone else) implement the code that you linked to?

@unknownbrackets
Copy link
Owner

It seems like image right now maps directly to a file (and there's cue sheet handling to determine where to read from.) I'd suggest abstracting out the CSO logic to a separate class, and maybe have image be an interface (it might be most convenient for it to become a pointer.)

It seems like it would just need to support Read(Async|Sync), Create(Async|Sync), Size, and WaitAsync mainly.

This other class could then read the header on Create:
https://github.com/hrydgard/ppsspp/blob/ce6cb7e7c92643ab6e65928cc4cb114ac0d6df5f/Core/FileSystems/BlockDevices.cpp#L133-L207

And then essentially the code I linked to before on Read or the more efficient option for multiple sectors:
https://github.com/hrydgard/ppsspp/blob/ce6cb7e7c92643ab6e65928cc4cb114ac0d6df5f/Core/FileSystems/BlockDevices.cpp#L290-L381

Basically:

  • The CSO code should run whenever a sector would've been read from an ISO, e.g. when reading bytes [X, X + 2048) from the uncompressed data.
  • On init (one time per CSO file), it should load the index, which will map X to the actual compressed file position.
  • On read, you use the index to find the actual file position of the compressed data for X and read it in.
  • Then you simply deflate with zlib, which might be the most popular compression library there is.
  • Next you copy out the part of the compressed block you want (a compressed block may decompress to more than 2048 bytes.)
  • If you want more sectors, repeat this process for each X.
  • As an optimization, consider caching the last X and reusing the decompressed block. More complex methods of caching often lose on overhead, but this cheap type of caching usually helps.

-[Unknown]

@Zero3K
Copy link
Author

Zero3K commented Dec 27, 2018

I have an issue with HPSX64 that I wrote more about at Zero3K/hpsx64#1.

@Zero3K
Copy link
Author

Zero3K commented Dec 27, 2018

How do I contact the developer of HPSX64?

@Zero3K
Copy link
Author

Zero3K commented Jan 1, 2019

No one else is interested in adding it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants