.

[creeperton]

.

[PhOeNiX]

A lot of method parameters is usually a sign that some refactoring of your code will be needed. One solution would be to gather most of the parameters that you need in a separate class representing something meaningful like a file entry.
The class Entry might have a "name",  a "data struct" and a "length" for example.

Code Select Expand


public class Entry{
  private String name;
  private int length;
  private byte[] data;
 
  public Entry(String name, int length, byte[] data){
    this.name=name;
    this.length=length;
    this.data=data;
  }
 
  public String getName(){ return name; }
  public int getLength(){ return length; }
  public byte[] getDataStruct(){ return data; }

}

The you would pass a list of entries to your method.

Regarding the rest of data in the sectors. If you are dealing with MODE2 images, you will need at least to recalculate ECC/EDC integrity codes for each sector, in order for the iso image to work on hardware.

[creeperton]

.

[PhOeNiX]

This pretty much depends on the kind of data you are dealing with. Mind that sharing data between classes like the GUI one and another one is not circular dependency.

Circular dependency happens when a class holds a reference to another class and vice versa. That is, the GUI class holds a reference of class A and class A holds a reference of the GUI class.

[creeperton]

.

[PhOeNiX]

This is what you need https://kenai.com/projects/jpsxdec/sources/svn/content/trunk/jpsxdec/src/jpsxdec/cdreaders/CdSector2352.java?rev=57.

The most important one would be the "rebuildErrorCorrection" method.

[STARWIN]

What I can see from browsing the internet and looking at some images in a hex editor, things look something like this:

2352 byte sectors

sectors 0-15 useless, there is some more structure later though with regards to the filesystem (which may not be used?) and exe location perhaps (in the end?) that I'm unsure about

assuming XA..

00 FF FF FF FF FF FF FF FF FF FF 00 -(12) sync pattern
xx xx xx -(3) address in some ugly format, irrelevant?
02 -(1) mode
ss ss ss ss ss ss ss ss -(8) subheader
(edited from http://club.myce.com/f61/sub-headers-207630/):

Code Select Expand


0 Identification of interlocked files
1 Channel Number
2 Submode Byte
BIT 7: Signals End of File (EOF)
BIT 6: Signals if Data is dependent on time
BIT 5: Signals if sector is Form 1 or Form 2
BIT 4: Type on (depends on the Operating System)
BIT 3: Data Sector
BIT 2: ADPCM Audio Sector
BIT 1: Video Sector
BIT 0: Signals End of Record (EOR)
3 Type of Coding for the Video and Audio data (00 when data sector)
4-7 duplicate 4 first bytes


Note that different sectors can be form1 or form2 within the same image. The subheaders may look something like this?

form1 (data): bits 3 set, byte3 zero, 2048 data, 4 CRC32, 276 RSPC
form2 (media): bits 2 5 6 set, byte3 nonzero, 2324 data, 4 CRC32

,with the exception of "01 00 00 00" sectors in media?

[creeperton]

.

[STARWIN]

You have the root folder listing in sector 22. You can for example see that B_CDATA folder is located in sector 0x043244, which means offset 2352*0x43244=0x268DD0C0. In that sector you can see a similar listing for files inside that folder, for example BOTTOM.ARC is in sector 0x044956. This way you do have a list of all filenames and their sectors there. The exact format is related to ISO 9660 no doubt, and perhaps slightly less boring than some of the other specs. I guess something like cdmage traverses this structure when it shows image contents, regardless of whether the game uses the structure or not.

[creeperton]

.

[STARWIN]

See my earlier post: mode is expected to be 02 always. Form1 vs form2 is about the subheader. Perhaps "00 xx xx 00" in subheader means it is a data sector.. one more question is whether you need to do anything where you need this knowledge? What is your tool supposed to do in the end?

I wouldn't be surprised if there is a max one file/sector limit. Just remember that the error detection and/or correction codes are in the end.

[creeperton]

.

[STARWIN]

I would focus solely on the filesystem part for now, so that you can traverse through the filesystem structure in your program and for example list all folder/filenames there. You can compare with the cdmage listing (and it shows LBAs too, which is how I could quickly see that the sector numbers are in the image, a bit before each filename, in both little- and big-endian).

Later when you can extract/insert (requires those annoying error code recalculations per sector) you can compare the result with a manual extract / insert modified file back in cdmage. The resulting images should be equivalent. (no binary differences in vbindiff or so)

Are you going to insert data that is larger than the original? If not, then you won't have to modify the filesystem at all I think, just read.

I'm not too familiar with cd images but I'm also thinking of creating an editor to some PS1 games later, so we kind of have similar problems. It feels a bit silly having to deal with these things considering that everyone in a similar position has to recreate the same stuff.. plus that cdmage already allows manipulating same-size extract/insert already. This is why Disch's Fischmare has an interesting project idea.

[creeperton]

.

[STARWIN]

One thing to add is that if you are not going to modify the filesystem, you might be able to ignore it. You'd only have to assume that every cd image is like yours. In that case all filesize(+ file structure..)-unmodified images of your type would be compatible, and you'd identify file/data locations just by image offset. The only thing left would be recalculations per modified sector.

On the other hand in cases where you'd want to increase the size of some file, I can see one theoretical problem: what if the game loads different files into slots that have just enough space for them as-is, and doesn't consider filesizes? In that case it would load a larger file over the next file in the RAM (or a new file over the end of the extended file). Of course this is a problem only if you don't do the work of figuring out how the game currently loads files to RAM. Also, there could always be some rule that PS1 games just don't behave in certain ways for some reason I don't know yet  . (even if the game considered filesizes, the RAM is much smaller than the ROM here, so it might be full at some point in runtime). But I guess most people would ignore these sorts of paranoia and just do it.