STR, XA, FF7STR??

  • Thread starter Thread starter G
  • Start date Start date
Status
Not open for further replies.
On this same subject. How are you mounting the PSX disk under linux? I haven't been able to get any mode-2 disks to mount under linux in *years* I have a windows PC running 95 that exports the cdrom via SMB so I can copy the data over via network.

Are you mounting an PSX ISO via a loopback?
 
There is no problem for me to mount PSX cdrom - just insert CD-ROM and I have mounted automatically it. Maybe your distribution is outdated (I am using latest development release of Ubuntu (Ubuntu Feisty)) Of course when I try to copy mode2 sectors (for example video data [*.MOV]) - it copies it incorrectly. But I user another scheme: I insert cdrom and grab image using cdrdao, and then I wrote psx2iso converter, so i convert bin image to iso and mount iso using command: mount <filename.iso> /mnt/iso -t iso9660 -o loop,nojoliet,norock,block=2048 (we have to turn off joliet and rockridge cdrom extension to see normal files, then I copy all files except mode2 ones movies), and then I write another mode2 dumper to dump that interleaved sectors. If you need that tools, I will upload them today into q-gears/utils
 
If we are directly readng the CD,you are going to need to least compensate for the extra wide sectors. Ripping the full mode2 sectors as a file shouldn't exapnd the videos *that* much. In a pintch, wouldn't be awesometo write an "installer" that will rip/copy files directly to the hard drive?

For what it's worth, the last 280 bytes are padding and can be tossed.
Click to expand...
halkun that's not the case.  The ADPCM data uses the full sector acording to the documents I have.  The video data doesn't.

I should finish that ISO FS stuff, I get so distracted by things at times LOL.

Cyb
 
On this same subject. How are you mounting the PSX disk under linux? I haven't been able to get any mode-2 disks to mount under linux in *years* I have a windows PC running 95 that exports the cdrom via SMB so I can copy the data over via network.

Are you mounting an PSX ISO via a loopback?
Click to expand...
I think you'll have to go through G's route and access the /dev/cdrom device directly. On my dumper for MacOS I can use an ioctl() to switch the drive into a RAW mode. This must be possible on Linux as well, otherwise you couldn't rip audio disks.
I'm sure I saw a library for Unix-style systems to do that in a portable way, but I'm not sure if I can still find the link...
 
Of course there is ioctl interface on Linux! It's not hard task to do grabber of filesystem in one step, I will do it, just bit later...
 
I've created an iso from my original disc 1 and can now mount it and access the files on it.

What I want to know though is how to point q-gears at it. I tried mounting the iso on a
mountpoint called ~/ff7/data and have placed a copy of config.ini at ~/ff7. I then tried
starting q-gears from within ~/ff7 but I keep getting files not found errors in game.log
as you can see below:

<snip to relevant section>
[18:37:55] File data/splash.bmp failed to open.
[18:37:55] Can't load texture.
[18:37:55] Set SDL input handler.
[18:37:55] Init game filesystem.
[18:37:55] Game filesystem inited.
[18:37:55] Init kernel.
[18:37:55] KERNEL: Init game base graphics.
[18:37:55] Loading file: INIT/WINDOW.BIN
[18:37:55] Can't open file INIT/WINDOW.BIN
[18:37:55] Can't open file INIT/WINDOW.BIN
[18:37:55] Warning: INIT/WINDOW.BIN not found!
[18:37:55] Warning: INIT/WINDOW.BIN isn't archive. number_of_files == 0

I've looked at the available docs, but I can't seem to find what I'm looking for. Any help on this would be appreciated.

Oh and before I completely forget I'm trying to get this running on a linux box :)
 
well, first Linux is case-sensitive. You should be running the executable in in the /output dir There is a /data directory there with the splash.bmp file it's looking for.
 
Hmm, running from /output produces almost exactly the same output. the only difference is here:

[19:32:37] GLU Version: 1.3
[19:32:37] ERROR: header must be 40 bytes long. We not support os/2 12 bytes headers.    <----
[19:32:37] File data/splash.bmp failed to open.

Hmm, the case sensitive-ness of linux could explain the other files not being found... the files on the iso are all lowercase and q-gears is looking for uppercase :/
 
All ISO9660 TRUE images should return just upper case. They should have no lower case, that is an extension such as Rockridge or Joilet.  So the whatever software was being used was reading the information and converting it to the wrong names.  You will need to be careful of this because the original files are all in upper case as well. (As all PS1 games are supposed to be). Windows CD driver doesn't even change there case. So that should be a cue to be sure not too.
Also ALL ISO file names have a VERSION number as well.  So SCUS_941.63 is actually "SCUS_941.63;1" in the root directory. I don't believe directories have this naming convention.

Erstwhile, Akari, look at FIELD.BIN in \FIELD\ directory, it contains information pertaining to all the files in that directory. Aparently a short coming of the playstation bios is to account for the strange use of the CD and directories in playstation games.  From what has been said by the group who translated it to Italain, any more than 30-40 files in a directory and the normal CDROM bios routines behave unreliably.  This is why you see the FIELD.BIN file.  Unfortunately I don't have it's format (bleah), I have tried using the Q-gears LZS decoder (without success). I think I'll try the GZIP routines instead to find out what's in it next.

I'll also put more effort into adding the direct ISO image support into Q-gears.

Cyb
 
Yes field.bin is gzip. if you look with a hex editor, you will see "1F8B08000000..." at offset 8. That's the gzip "magic" numbers :P

I checked it: removed the first 8 bytes of the file and saved it as scene.gz, thne used winrar (gzip/gunzip should work too:P) to extract it to scene.dec

Looking at it shows what seem traces to what the original scripting language looked like (bits like if, lif, the opcode names, and others), and moch more! :P

EDIT: actually "and much more" I meant lots of data that while it seems to follow some structured pattern (so it could be one or more arrays of things) dont' have any apparent meaning (not even after adding 32 to each byte to check for ff7 strings).
 
Last edited:
Wow.. you are right.. it is quite interesting.  Hmmm I'll look at the wiki to see if they match  Also I am going to see if I can corelate some of those numbers with ones for cheats in FF7. A series of those numbers look like PS1 memory space offsets.  They could be the engine break points or variable locations (either one is interesting).
I suggest you look at offset 0x0003A5B8 THAT is rather strange, it appears to be some sort of table.  Some look to be file sizes (some).  The table ends at 0x0003F0DC.  Then it begins with locations in the PS1 memory it looks like.

I guess that LBA table of files and there sizes on the disk might come in handy. Hmmm.

Cyb
 
That might be the master file lookup table when the CD was mastered and points to where the files are loctaed. That might be the key to remastering a new ISO if you wanted to.
 
Back to topic:
I cleaned up my code related to decode and play movies. Now I want to add it to q-gears. I have created new module in testscreen (not in SVN yet). Already wrote player using sdl-output.
Now I have a question: is there any methods in q-gears I can use to output movie frames onto main window? (in sdl I have used SDL_Surface & BitBlit it to root surface). Spend many time yesterday to do this, got successfull output directly through sdl in my screentest module, but after finish playing movie I have got corrupted graphics (there was not any text in menus and some other things).
 
Status
Not open for further replies.
Back
Top