News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - SCO

Pages: 1 2 3 [4] 5 6 7
ROM Hacking Discussion / Re: Gamecube ROM Hacks
« on: January 13, 2018, 11:16:46 am »
Speaking of this is there any specification of the nintendo disc format i'm missing? Because while dolphin has no problem opening 'isos' from those consoles, they certainly aren't isos and cdemu chokes on them.

Personal Projects / Re: Asuncia (PS1) project
« on: January 11, 2018, 10:55:26 pm »
Mednafen RA is different from upstream RA in this respect i've found. Stricter for some reason (probably upstream divergence).

It blackscreens at boot, just before the 'xs' and that logo shows (mednafen RA doesn't show the bios).

In order:

52d7184aec32af915860ac5b78b21d8b  Asuncia - Majou no Jubaku (Japan) (Track 01).bin  (redump data track md5sum, works on both RA and standalone mednafen)

8f255d74822d700f33b5d45324aaec86  Asuncia - Majou no Jubaku (Japan) (Track 01).bin (with your patch applied, works on standalone mednafen, doesn't work -black screens- on RA mednafen)

584fc0933909ae1636255bc9649cb719  Asuncia - Majou no Jubaku (Japan) (Track 01).bin (with both your patch and error_recalc applied, works on both mednafen again).

error_recalc is like a battle axe that will cut down any mismatching ECC. I don't know if that is actually 'the best way' to fix this. It says it has a option to remove the EDC completely from mode2 form 2 sectors that 'may be optional' whatever that means, but i used the one that recalculates everything.

Personal Projects / Re: Asuncia (PS1) project
« on: January 11, 2018, 02:14:57 pm »
Yeah, the front mission translations are... well, i've always been told not to say anything if what i'm going to say is bad.
No sound in videos for example.

Anyway, i'd also suggest London Seirei Tanteidan if you're looking for a rpg project. Looks sweet.

Speaking of this game in particular, this translation doesn't seem to work with redump on RA mednafen. Just blackscreens forever... unless i apply error_recalc to correct the ECC/EDC.

This happen pretty often on ppf translations, maybe you should ask how to avoid it. Or maybe it's simply not possible because ppf only applies the patch to the user part of the data on the iso and was never fixed. Or quite possibly it's the actual patcher i'm using that is guilty of not doing that.

I'm hoping this is a easy way to figure out if a cd/dvd iso is ps1 or ps2. If it's not, drop a hint if you know ok?

January 11, 2018, 05:27:29 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Apparently yes. Or as far as i've been able to figure. Must be part of the ps2 retrocompatibility with the ps1.

ROM Hacking Discussion / Re: CD romhacks often create corrupted cds
« on: January 09, 2018, 06:55:02 am »
edit: deleted all the confusing info.

Yes, that's true, but ps1 discs were true mixed mode cds, and always had some sectors at the beginning that had 2324 user data (for copy protection) and sometimes videos or audio with the same (for space efficiency).

I tried to modify the adapter so it could 'read(index)' with these sectors with a complicated scheme of list memoization of the 'naughty' sectors and calculation of the right sector by transversing a list of the naughty sectors and calculating their extent. But pycdlib always objected (even if i can't find the bug). So i decided not to care and pretend the 2324 sectors are 2048 only. It apparently still works to extract the system.cnf.

Meanwhile, the author of pycdlib relaxed the parsing of the problematic cases so it seems it's all good.

Except i got a headache: apparently ps1 and ps2 have the same system identifier 'PLAYSTATION'. There goes the console autodetect. This is just not right.

I also found that that cotton translation nukes the system description, but leaves a new volume description "Cotton RIP Trans". It's obvious that it was done very poorly.

ROM Hacking Discussion / Re: CD romhacks often create corrupted cds
« on: January 09, 2018, 12:56:44 am »
Actually don't bother debugging weissvulv (at least for now). It seems like a library screw up for now. Something about not expecting 2352 bytes sectors in isos, i'm bug reporting it. It is just a bit strange that hacks have different errors but it's better to wait until at least the original dumps problems are fixed before the hacks are analyzed.

ROM Hacking Discussion / Re: Converting FDS images to NES?
« on: January 08, 2018, 09:42:12 am »
There is actually one thing that bothers me about treating diskettes, and hd images like ROMs in emulators: they're writable, unless the 'copy-protect' cover is closed (it existed on the Amiga anyway).

This means that a dumb game, as part of its normal operation, might very self-modify (HOOK.EXE did this in dos to savegame and change settings 'in the executable') or just change things around in the disk (savegames etc).

Many games asked/created a dedicated save floppy for this, but many didn't.

This is a problem for emulator usability, because, besides the hassle of managing your own savegames location, it has the potential to change checksums of dumps when you play, making your 'romcenters' and dat files much less useful (for emu autoconfig among other things). I suggested something like a copy-on-write for RA already (and i already use it for dosbox on linux) to prevent this in a 'general' way (as a bonus, something like this can also play games from a zip, cd, dvd, blue-ray etc, and only copy stuff that needs to be written).

Thank god for whdload for the amiga and that most DOS games later than the 80's were hard-drive targeted so having a 'save diskette' is rather uncommon for them.

Something like this, will also be useful for later consoles with hard-drives later on. It's not a good idea to have a copy of a OS for every game, or to have your 30gb game change crc just because and something like a VFS with cow could prevent that sort of stuff.

ROM Hacking Discussion / Re: Converting FDS images to NES?
« on: January 08, 2018, 03:32:41 am »
The only project i know that habitually consolidate data into another medium (ie, not no-cd hacks) is WHDLoad, and those guys are still introducing and fixing bugs on their installs.

However, i still exclusively use whdload. The convenience is much better.

ROM Hacking Discussion / Re: CD romhacks often create corrupted cds
« on: January 05, 2018, 11:38:11 pm »

For Sega consoles (all of them i know), it's actually the first 256 bytes which are the header. libmirage allows me to get the 'real' data without having to care about fileformat gunk (cue/bin MODE2/2352 has a little prefix for instance) or ecc bytes (this one is not really a problem since all cd modes sectors are larger than 2048 at least). A exception: as far as i can tell, Sega mega-cd has two headers glued together to give 512 bytes at the start of sector 0. Since redump uses that second one (AFAIC) i'm using that.

After extracting the bytes, i do a md5sum of them. Since those headers are part of the original data, all (non-corrupted) versions of any iso/nrg/cue|bin/etc will have the same md5sum.

There was another reason to do it like this, from a cursory look at the redump site on sega cd, it's not easy to parse out the the correct 'actual serial' across versions because a great deal of them look incorrect (but the header is correct, since it's incredibly hard to get wrong).

For ps1, the serial is quite standardized (with some exceptions i've encountered).
It's basically the name of the executable in the 'BOOT' line inside system.cnf which is the console boot file. If that file doesn't exist, i try the cd volume descriptor and sanity check it (only game i 'have' that i've had this necessary was King's Field(Japan)). In either case, i then transform it into the redump standard (remove dots, uppercase, add '-' separator if missing). This was actually the main reason libmirage and iso parser was needed, because it's not exactly easy to find a utility that can access most dump formats and still extract files without mounting.

It's still not portable to windows (mostly because libmirage is not portable - as far as i know).

I'm planning to use the script on m3u files (that mednafen retroarch cores support) as a target of configurations names (find config with filename 'id', copy it over to the m3u name). Since m3u support multiple cds in retroarch you would only need a single config (cd1 on the m3u) to apply to all cd changes).

If only i can convince the people doing those configs to use this scheme ofc. That's the part i'm not confident on (see no windows support).

I've not investigated nintendo consoles yet.

ROM Hacking Discussion / CD romhacks often create corrupted cds
« on: January 05, 2018, 08:23:58 pm »
So i was doing a little tool to extract games ids from cds (i want to be able to have a way to rename Retroarch configs to any dump type and name, so i decided to extract a invariant id from the dumps) using libmirage (part of the cdemu cd emulator) and pycdlib, and when testing it on my collection, many of the hardpatched cd translations gave a parsing error in pycdlib. There is a common error on originals which is probably a library bug ('year is out of range').

I'm not sure if most of these weren't already on the originals, but for what it's worth, i only verified that the original iso is not 'corrupted' like that on the policenauts translation. They all play fine (obviously) so this is just a curiosity. The list is just checking the first cd of multicd games to not get too long: (verified original doesn't have the problem)

'pycdlib.pycdlibexception.PyCdlibInvalidISO: Invalid root directory entry identifier', relevant pycdlib is here. (translation says it inserted the modified files from the original distributed as a iso and create a ppf)

pycdlib.pycdlibexception.PyCdlibInvalidISO: data in 3rd unused field not zero

pycdlib.pycdlibexception.PyCdlibInvalidISO: File structure version expected to be 1

pycdlib.pycdlibexception.PyCdlibInvalidISO: File structure version expected to be 1

As i said, this is probably useless and the library guy will probably relax these anyway since the games obviously play, but it's interesting.

It might also be my fault by way of libmirage since it loads dumps in 'most' formats to a in-memory format and the script is just trying to plug in the first data track to the pycdlib iso parser. Maybe some information is getting lost.

You can convert one to the other with the right patch here: (search for 4089 and you'll find the two conversion-back and forth patches).

xdelta3 is a command line program so you have to learn the switches to tell it to patch or make a patch.

Anyway, it also works here *if you start desmume first* and start the game from the file dialog. If you just try 'desmume patchedrom.nds' from the command line, it crashes like that. It's probably something wrong on desmume... though i'd honestly be more assured of that if the base of the translation wasn't a rom that was underdumped. And if you tested it works on hardware.

We hope everyone enjoys the patch :)
Hmm, could you try it with regular, non retroarch desmume on linux and PM me what happens? Just to eliminate the possibility that the emulator is causing this.

I did. That's why i wrote "both retroarch desmume core and standalone"

edit: ok, this is a desmume 'race condition' when you start the game from the console (also happens with the RA core).

desmume patchedrom.nds crashes with that message, start 'desmume' and open the rom from there and it starts.


It *only* happens with the patched rom for some reason though. The normal game starts from the console like that (both dumps).

This is not working on desmume retroarch.

I patched ROM with crc32 5CF26E2F

as requested on the page (but i will notice that crc is from the older 'scene' dump, that is a underdumped header: )

resulting on a ROM of crc32 of 647e487b

both retroarch desmume core and standalone say something like this:
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr: __pos (which is 18446744073709551615) > this->size() (which is 5)

The rom is also 76.2 mb to the original 134.2, though i've seen other patches that do the same and work.

Am i doing something wrong here? Maybe the crc on the page is just wrong? Or maybe it was just tested in hardware...

I'm using xdelta3 on linux.

Yeah, this 'controversy' always seemed to me a bit of a /v crusade against 'moralfags' because some translator had the audacity to rename minor things he felt were offensive to his religion (stormfront nazis ofc don't admit to playing games).

It's not a good thing, but no reason to blacklist a patch... especially when bullshit like this and this is praised on the same place. I dislike culture war even when it targets things i disagree with and i dislike hypocrisy.

Internet really concentrated the shit of humanity into echo chambers with disproportionate influence on the unwary.

ROM Hacking Discussion / Re: Any Growlanser translation projects?
« on: December 13, 2017, 03:15:11 pm »
I would be totally hyped to see you guys work on a Growlanser patch  :)

Also on the topic of opening videos, Atlus changed the intro animation for Wayfarer of the Time as well, although it was a completely new video instead of just a different song like 1. I always thought it didn't look as nice as the original PS2 opening, certainly not as colorful.

They did that a lot with nominally 'enhanced' versions for some reason or other. Probably lost sources for the encoder?

Happens in the remakes of Mana Khemia 1 and 2 on the psp too i think. Speaking of that, Mana Khemia 2 is another 'japan-only enhanced psp game with a ps2 english version'.

edit: i think i remember the reason now, the psp remakes add a female protagonist. Same rationale as persona 3 where it would be ~troublesome~ to remake all the anime FMV so off to visual novel format they went. As it would be expensive to do more for a quick-cash grab, and would necessitate changing stuff anyway (either extra FMVs or have to change them anyway in order to not alienate people that are interested in the new path), they do the minimum of 'reimaginating' the necessary FMVs.

I once joked that Nanashi (the protagonist of SMTIV: Apocalypse) looks like a butch lesbian (one of those asymmetrical haircuts, earring) so they don't have to spend money if they decide to add a female path to the game in a new edition.

ROM Hacking Discussion / Re: Any Growlanser translation projects?
« on: December 12, 2017, 07:35:47 pm »
He's talking about Growlanser I. It is actually the release without a english version out of 1, 2, 3 and 4.
1 came out on the psx and psp (not english), 2 and 3 were rereleased on the psx2 (english), 4 with a enhanced version on the psp (english). It's a similar situation to the the duology of persona 2 on the psp (though that's nearly as frustrating, considering the psx versions the missing game has a official translation and the other has a fan translation if you don't like the psp release).

This one doesn't work with no-intro right? Sometimes you can apply a ips file to a non-matching checksum and they work, but the no-intro dump apparently has a different size (my guess is, no copier headers).

Personal Projects / Re: Tengai Makyou Zero translation project
« on: November 21, 2017, 08:10:09 am »
There are still quite a few Japan exclusives (and Satteliview) that aren't translated. And many subpar translations of course.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 18, 2017, 03:30:22 pm »
If it's a question of the patched file md5sum or similar being different, there might be a 'virtuous bug' in that softpatching might evade that (emulator uses original md5sum to recognize settings, *then* softpatches into memory). Similar to something that happens with retroarch unrecognized fan-patches, where if the core can softpatch, at least the original rom metadata is correct (even if you're not playing the 'original' rom).

On the other hand, if the patch changes something fundamental about the required chip settings on the rom itself, then using the 'post-softpatch' md5sum would be required and require another hack in the source code. *shrugs*. This is the reason i call it a 'virtuous bug', logically consistent behavior is to get the hashcode after the softpatch, even if the contrary is more useful if it works. It's basically the fault of the underspecified rom format i think.

Pages: 1 2 3 [4] 5 6 7