Testing out POPS-00001 on PS2 (Need help on PATINFO.KELF)

Sorry if the Hex Edits I made are going a little to far, I love using the HDDOSD and hoping that other can use the Hex Edits dumps for any good. I know that richi902 made a blog on how to setup a Game Partition named "Install APPS/Elfs to the PS2 Browser/Game Channel(updated)" but a lot of info is no in it. Mostly the hex sizes for how to add the icons and icon.sys and others, so its almost no help is not average user friendly,

I see that ELPatas tested it but I'll try this as well. As soon a I get home.

 

After having tested the LSN.BIN, i tested the game Wipeout XL US version with the valid header you
provided and is nice to hear the CDDA tracks, but unfortunately the game don't runs perfectly fine.

When i whatched your video before don't noticed that the game don't have the voices and sfx
sounds for weapons, starting race, extended time, autopilot and all the items, you need use a lot
them for notice better the problem.

When the emu try to decode them you can hear a very little crapy noise and then mutes, not as
obvious as the first Wipeout, if you play a lot, one of this faulty sounds stutters in a big noise and also can freezes the game, (i got two or three freezes after playing a lot because of the sound).

The game have a few slowdowns in certain points of the circuits which are hard to notice in the
slow Vector class and Feisar ship, is needed playing in the fast Rapier class with Qirex ship por
example.

I tested the game in the real psx and the cursor is also a bit slow in the "Load & Save" menu,
then seems is ok in the emu.

I don't know if this problems happens only in the poc2, if happens also in your last revision
i hope can be fixed.

 

I just tests out DumPops and I'm vary happy! My number one Gundam game for the PSone, Gundam Battle Assault 2 (SLUS-01418).
Thanks to that crappy TOC reader/dumper, it runs perfectly fine and before this, it runs fine but the game stops working in some parts.
If you like to have the MSF and LSN files, let me know and I'll upload them.

I also tried this on Tetris Plus (SLUS-00338) to see if it can access the CDDA tracks as before none of them played at all. Thanks to this now all of them play and sound just like the PSone var. If you need the files, let me know.

This looks to be fixing/doing more then just CDDA tracks?:concern: Now all if this can work on a PC as well... but I'm sure it may be harder to make...
maybe copy can worked as well, if you do it right at this.. and this be done on games that are not for my PS2, My PS2 can only play NTSC U/C games but I have a like of Japan NTSC J games... it most likely going to work that same way as a copy.

 

Thanks very muck for testing, guys !

Yes. The location of tracks and their gap are incorrectly dumped by the ELF I've posted, so the music of CDDA tracks may not start/end where it ought to. If you dump the TOC of the same game two times, you'll see that the 2 dumps don't match.

Yes I'm interested by your TOC dumps. Contents aren't copyrighted so no worries.

Some games may crash whilst trying to read CDDA tracks when they're not indexed (ie : when using the Bishi Bashi TOC). The crappy TOC dumper fixes that problem because the total number of sectors and the number of tracks that are written in the dumped TOC are right. Although, it dumps wrong MSF locations.

I'm currently writing a DOS tool that will convert BIN/CUE dumps to a valid disc image for use with the emu.
For now it parses the cue sheet and outputs a POPS header. The vomited POPS header lacks 2 entries : The lead out location and the dump size in number of sectors. Work in progress (slowly, but as much as I can)...

Thanks again for your tests and for your patience.

 

It's no problem, I love to help in any way I can.:friendly_wink:

Ok, hares the files in a ZIP file... http://rghost.net/44857857 (Note: this download may only be working for 30 days) and this http://rghost.net/44858110 is var. that I tested for Tetris Plus, I made two files and almost deleted this one.

Also I have a lot of PSone games that I can try as well and if you like I can give the MSF and LSN files.

So that's why GBA2 was crashing at times, other then the crashing it played 100% before this and now it runs fully. Tetris Plus played using the Bishi Bashi TOC but no CDDA tracks, now it works thanks to the dumper.

That's good to know... but by DOS.. as in your writing it for the "Command Prompt" not that I don't have a Windows 98/DOS PC, just looking to be sure. I'm sure it just a command line. It great that it will work for games that people downloaded or backed up.

 

I made the LSN/MDF toc dumps of 20 games, if you need more let us know.

I encountered two games which the tool can't dump, the first Wipeout (SCES-00010) and
Ace Combat 2 (SCES-00699), stops in the message Parsing system.CNF.

Then for the next revision is needed using this tool for make the valid header each time for each
individual game?

Keep the good work with the lead out location and the dump size.

Many thanks to you!

 

I made some more dumps as well on 28 NTSC U/C games at http://rghost.net/44881422 and hears a list.

I tried one game that worked but made a file that I can't open, delete or look at. It was the NTSC U/C var. of Tekken 3 [SLUS-00402]
but this may just be an error by the dumper at part of the PS2.. like maybe a USB Mass error.

Yes, Many thanks to KrHACKen's great work and all of them!

 

Yep, a good old MS-DOS command prompt app. But the release will come with the source code attached, so could be ported or rewritten later

Haha, I took my French copy of Ace Combat 2 and open the SYSTEM.CNF...

Lacks a slash. Should be cdrom:\SCES_009.01;1, hence why DumPops cannot parse SYSTEM.CNF
Shadowman had a similar issue with previous builds of DumPops, because there was no ;1

Thank you for uploading your TOC files !
It's amazing that the emulator can reach all tracks with such shitty TOCs. I don't understand why each time DumPops invokes cdGetToc/sceCdGetToc, it returns a load of garbage in the buffer. Segment_Fault made a working TOC dumper during the POC1 era, but since we're no longer in good terms... anyway, we'll not need that thing anymore as soon as we can use a PC tool.

LSN... Well IOPCD doesn't support that kind of stuff, so I don't get why it works. Some games use FILE access to read from audio TRACKS:wink-new:, in this case I can believe that a valid sector count is enough, but it does not explain why the emu actually run games that have an unsuitable TOC like the LSN.BIN. Nonsense:stupid:.

CDRWin vs. IsoBuster. Project maintainers had difficulties with their TOC generator. TOCs resulting from CDRwin cuesheets were invalid because of pregaps. It caused CDDA tracks to not play from the correct location. So I've added an optional command in my tool that allows the user to add/substract 2 seconds (pregap size) to all tracks MSF, just in case it happens.
Todo : disc image I/O, lead-out MSF, sector count, NTSC patch.
Not sure I'm going to put a NTSC patch thing, because I already expect that the resulting aspect will be crappy (and the patching process slow as hell).

 

Wow! Open source...

Heh, almost all games are working with shitty TOC from BishiBasni3.

As i know sector count is the most easiest stuff to realize. Just copy value from offset 9368h (or mirrored at 936Ch)

Yea I know that this value can be wrong cause to wrong image, but... But the game reads sector count from here and if the game can start with wrong value it means that this wrong value can be stored in the TOC. Finally its not your work - checking if image is correct. End user can you some third party programs for checking images (such as GetMD5)

 

Yeah. However it would be better to do a complete re-write rather than a simple port. Since I'm an amateur, my source code is full of dirty tricks and math.

Yep, that's actually what DumPops does when it says "Reading the 16th sector":encouragement:.
For the PC tool I think I'll use another strategy :
1) Get the dump size
2) Get the sector size (if the dump starts with 00 FF FF FF, sector size is 2352; else assume it's 2048)
3) Divide the dump size by the sector size
4) Copy the sector count I got in the above step to the header
5) Convert it to MSF
6) Copy the converted sector count to the lead-out MSF field of the header.

One thing I can tell is that my tool will not support multi-binary cuesheets (cue sheets that use multiple file for each track). It'll only work with stand alone raw dumps (one bin + one cue). Users can convert their "splitted" dumps with some other software I guess, like IsoBuster, CDmage or such ISO manipulation software.

 

And you can improve the tool for it can read all the different system.cnf files for all the games?

For what is the ntsc patch if you put it?

 

I can but I'll not, because DumPops is a test tool, not really intended to all POPS end users. The TOC files that it saves to the USB drive are junk, somehow "working" but still erroneous. Unless I find what causes cdGetToc to return incorrect MSF and fix it, there will be no more revision I'm affraid...

PAL games and users that don't have GSM or don't want to use it. But like Zapper, Napalm's NTSC patcher and Paladin, the resolution of NTSC patched games doesn't fit very well.

 

Aha, but the DOS PC tool you are writing and which dumps from bin+cue will not have this problem?

Okey, and also you intend to apply default coordinates which centers the screen the best possible?
Well, if the resulting aspect will be crappy and the patching process is slow as hell, if you put it perhaps the best thing would be make it optional.

 

The PC tool I'm writing parses the cue sheet and uses it's listed MM:SS:FF locations to make the POPS header, so no, it does not have this problem.

Yes, it will triy to patch the video mode and to fix the Y-Pos. The screen should be centered more or less correctly, but the bottom of the screen may be cut down .

Yes optional, like the other commands. For now, optional commands are :
gap++ : Adds 2 seconds to all track start MSF
gap-- : Substract 2 seconds to all track start MSF
vmode : Scans the output file (Header+disc image) for VMODE and Y-Pos patterns then attempts to patch to NTSC.
The NTSC patcher isn't implemented yet. I do have a little piece of code that I wrote for a stand alone patcher. Ready to be integrated in the POPS tool.
The tool can run and do it's job without commands, just by specifying an input file (the cue sheet). Drag & drop should work too. By default, it outputs the header (yeah, just the header for now, since the BIN handler isn't implemented yet) to the location where the cue is. For example :
c:\MyFolder\MYGAME.CUE
The program outputs the header to "c:\MyFolder\MYGAME.CUE.TOC"
"c:\Some Folder Name\My Game Dump.cue"
The program outputs the header to "c:\Some Folder Name\My Game Dump.cue.TOC"
c:\MyFolder\MYGAME.CUE gap++
The program adds 2 secs to all tracks MSF and outputs the header to "c:\MyFolder\MYGAME.CUE.TOC"
c:\My_Folder\MYGAME.CUE gap-- "c:\Documents and Settings\Administrator\Desktop\SomeGameName.lol"
The program substracts 2 seconds to all tracks MSF and outputs the header to "c:\Documents and Settings\Administrator\Desktop\SomeGameName.lol", because the output file name was specified as last argument.

 

2048? You mean support for Alcohol mdf/mds images? COOL!

 

I mean 2048 bytes/sector.
I don't think that non-MODE2/2352 dumps are accepted by the emu. The tool will manipulate them anyway, but wil NOT convert them to 2352 bytes/sector I'm thinking of adding some warning message telling the end user that the dump is not suitable... something like that...
I've dumped Rollcage Stage II with Alcohol. Looks like the mds file is a valid MODE2/2352 disc image, not MODE1/2048. The only additional thing that's needed is a cue sheet in text format. CDmage can make one.

 

On this page can be found very-very useful information about PSX CD format differences (I mean Hex offset specification).
And here is ripping tool for PC side. Maybe it is better neither yours )))

 

The reason why their tool f*cked uo with CDRwin cue sheets :

Legit.

Very useful and informative stuff on that page. Thanks for the link ! Bookmarked.

 

Its great, many thanks for the detailed explanation.

Which kind of problem happens to a track of audio CD when is needed apply the gap of
2 seconds (++ or --)?
The track is cut in the start or when are finishing? or the problem its a thing you
can't notice when the track is playing?

You mentioned that the TOC resulting from cuesheets made with CDRWin are invalid, but it
happens the same problem if you use any other rip program for the same game?
Or with a concrete game always is created a invalid TOC from cuesheet no matter
what program you use?
I use UltraISO for create the bin+cue images of my games.

 

If the music starts too late (after a gap of 2 seconds with no sound or with the end of the previous track) and if it's cut 2 seconds before the end, gap++ (which adds 2 seconds to both absolute and relative MSF addresses) should fix the problem.
If the music starts 2 seconds after the beginning of the original track (truncated at playback) and you can ear the beginning of the next track at the end of the currently played one (or a 2 seconds blank), gap-- to substract 2 seconds.
But the user should really not need these commands if their game dumps are properly done.

It seems to happen only with CDRWin.

In other terms : CDRWIN does crappy dumps that lack crucial data to make the image tracks "aligned". Each time a PREGAP is defined in the cue, the dump file doesn't contain the sectors of the said PREGAPs. gap++ and gap-- may not help with all games, so a proper fix for CDRWin BINs should be to inject sectors between the main data track and the first audio track. I did manually pad a CDRwin dump just now, and it worked like a charm. I think I'll automate that task in my tool.