Hacking WiiFlow Lite with emulator's database

[GhaleonX]

CD based system like PS1 and MegaCD are using serials(found in iso's header) instead. CRC would be much too long, about 30s to calculate!

I know that Wiimpathy said he's done with this, but does anybody know how this 'serial' system works, exactly? I thought it was using the game disc codes like G-6041, MK-4441 -00, etc, however it seems from my experimenting that it must be using something else.

TBF, the SegaCD/MegaCD does have some nearly duplicate IDs; Silpheed and Double Switch both have a copy with MK-4419 in the header, although Double Switch also has an extra blank space after the last digit fwiw. Still, both of these games detect just fine, while Sonic CD and Sonic CD++ have the exact same ID for this line, yet only one is detected as Sonic CD. There are also a couple other games that don't get detected but have the IDs in the INI file (which also suggests it is using these IDs, even though everything else suggests that it isn't).

Can anybody clarify this?

**EDIT** I decided to go a little extreme and delete everything except one entry that wasn't showing the game info/GameID and it still doesn't show, so I can't say that it isn't looking at this DiscID or whatever. In fact, it very possibly using that for others and is just having trouble here for another reason. Something else must be going on...

If it is indeed scanning for this tag, how does it get the tag from a CHD? I've tried using chdman on mac and windows and neither one seems to disclose that tag. I can get it by opening the bins in a hex editor, but it takes a long time to convert them back and forth just for that.

As a side note, this may be related to why my turbo duo folder takes a very long time to scan (assuming it’s crc hashing everything, although it does seem slow even for that, the question here would be whether or not that’s changeable)

 

[Wiimpathy]

PSX iso detection was taken directly from Retroarch code. Like all CD based systems here, it only check file header. No crc, no sha1 etc.
I doubt CHD is working for this by the way. Not sure what's extracted exactly, the code is there
I have no iso or my old scripts to check right now... Pretty sure they came from redump and were the standard serials.

For MegaCD, you may be right about some similar titles not detected correctly. Looking at the code, It seems the serial is cut. Here's the comment I put:
// Cut at second dash, we don't need any extra code.
// Sonic CD : MK-4407(-00)

Morevover, only iso/bin containing "SEGADISCSYSTEM" in the first bytes.

As you guess, this is far from perfect, but it covers most cases and is fast enough in Wiiflow (which would be very slow for better signatures algo).
The databases themselves needs a lot of improvement too. Today, there are more complete and unified databases. But it's a bit late to start from scratch...

 

[GhaleonX]

PSX iso detection was taken directly from Retroarch code. Like all CD based systems here, it only check file header. No crc, no sha1 etc.
I doubt CHD is working for this by the way. Not sure what's extracted exactly, the code is there
I have no iso or my old scripts to check right now... Pretty sure they came from redump and were the standard serials.

I'm still trying to figure out what's going on with it, but I can say that when I delete the INI file from the plugins_data/Mega CD/ folder, it doesn't recognize any of the titles, so the INI is definitely doing *something* here... I tried setting up Dolphin on my computer here to see if I could figure anything out that it's doing (especially since I'm also trying to figure out a better way to load files in quasi88 or what syntax neko project 2 might play nicely with, if any), but alas it's not good enough to run well enough to do things that involve stuff.

if it helps, my Sega CD folder is all CHD, though I've tried changing the CHDs that were not detected properly to bin/cue versions and the same problem persists as if nothing had been changed (and having both in the folder at the same time just creates two files that aren't detected properly instead of one).

My PCECD INI is all CRC32 values and it does work, but I suspect based on all this so far that is why it takes ~30 mins to rebuild the cache on it (although I have not investigated this much yet).

For MegaCD, you may be right about some similar titles not detected correctly. Looking at the code, It seems the serial is cut. Here's the comment I put:
// Cut at second dash, we don't need any extra code.
// Sonic CD : MK-4407(-00)

So then I presume that means it will take into account the space that exists between the last digit and that dash (and thusly 'MK-4441 ' and 'MK-4441' can co-exist without collision)?

Morevover, only iso/bin containing "SEGADISCSYSTEM" in the first bytes.

I'm going to try some more tests first, for now I'm making a list of the games that aren't detecting, then I'll update with the relevant INI info after I power down and put the SD card in the computer here.

Not detected:
Advanced Dungeons & Dragons - Eye of the Beholder
Ecco - The Tides of Time
Sonic CD++
Soul Star

Game Name	Title	File Name	Expected Game ID	Full Game ID
Advanced Dungeons And Dragons - Eye Of The Beholder	Eye Of The Beholder	Advanced Dungeons & Dragons - Eye of the Beholder.chd	T-75014|06281994|38E20701|	GM T-75014 -00
Ecco - The Tides of Time	Ecco: The Tides of Time	Ecco The Tides of Time.chd | Ecco The Tides of Time.cue | Ecco The Tides of Time.bin	G-6041|MK-4441|	GM MK-4441 -00
Soul Star	Soul Star	Soul Star.chd | Soul Star.bin | Soul Star.cue	T-60184|T-115035|	GM T-115035-00

You'll notice I tried a couple extra numbers on the AD&D game (the date, which is a string in the header, and the CHD's CRC32, just in case)

I noticed while building the table above that Soul Star was written as Soulstar in the INI, so I separated it into two words to match the Game Name in the XML file and now it is detecting. I went back and added a '-' between 'Ecco' and 'The Tides of Time' and now that title is detected, too.

So, for naming to work it must match the filename, INI, and XML precisely; otherwise, no linkage will occur. Perhaps it reads some GameIDs and not others for BIN files, but it seems the ones I've tried so far were not read, regardless of format.

As you guess, this is far from perfect, but it covers most cases and is fast enough in Wiiflow (which would be very slow for better signatures algo).
The databases themselves needs a lot of improvement too. Today, there are more complete and unified databases. But it's a bit late to start from scratch...

Yes, I have been expressing a lot of my frustrations with the database to @RunningSnakes lately, and have been working on 'fixing' as much of it as I can. I can say the biggest problem is that a lot of the INI files that are distributed are the source of problems because many of them are riddled with duplicate CRC values, some of which cause collisions. Once cleaned, they work quite well!

I think we could have some kind of actual "official" database to refer to, and that most problems can be eliminated if we made the software put these files together instead of having the user hope the ones they download from wherever are put together properly.

I don't have much experience in this area, but I started by importing each INI file into a spreadsheet and having it highlight all the duplicate values. Unfortunately, when I did this with the MSX INI, I would scroll through the file with worse scrolling than that of an actual MSX (which seemed poetically ironic).

That frustration led me to put some scripts together [poorly] to assist. The scripts aren't exactly 'universal' and I'd worry at all the mistakes anyone might make with something I slapped together without really understanding it, but basically I've got a system together where I can have it automatically do some things, save to different files that I can manually import changes from (or if I know the file well enough, I know if I can trust the fixes its logged).

I don't think the 'A' was actually necessary to add to the 5-digit entries you got from the scraper; one of my scripts thought all the GameIDs were bad in the Game & Watch INI which led me to discover that 5-digit values seemingly work just fine, as long as they match.

In fact, before I discovered where you got these IDs from (because I seem to discover everything backwards lately, and only just recently discovered *this* post explaining some of the questions I was hounding others with lol), I found a few duplicate games and repurposed the IDs of the redundant entries for ones that were missing, but hesitant to generate new IDs for fear of conflicting with an existing one I might not be aware of. That's when I kinda experimented with a few different IDs and they seemed to all work, and then when I found this post I went back and changed the ones I changed to what they are in the current database if they've been added, and so now when I add entries I'm using a more 'custom' tag which seems to work. I'm keeping it 6 characters for the sake of my [poorly written] scripts, but for MSX games for example I'm making IDs like 'MSXTWR' (which I used for 'The Witch's Revenge'). I created an account at screenscraper in attempt to generate GameIDs for what was missing, but I don't think I'm gonna be able to scrape anything the way they do it for that, so for now this is what I've devised.

I also accidentally ruined my MSX files yesterday and spent quite a while combing for the error, which may have simply started by including [ and ] in the text I was testing in a synopsis (although since then I have reason to suspect that could have been a coincidence). I've got them 'fixed' again now, with all my updates so far, and I'm adding in a few more entries that I'm aware of it's missing (though a MSX database may never truly be complete anyway).

I've also gathered what snapshots and cart_disk images I could of new entries along the way and fix them up a bit for display (some look better than others). ..

Post automatically merged: Dec 1, 2025

I think I've got the MSX one fixed and significantly updated. If either of you would like to try it out and see if you find any errors, I'll be happy to see if we can't get a proper database back in order

MSX-files

I've got my current cart_disk, snapshots, and plugins_data folders for MSX in here so that you can just rename your current folders and pop these in and see if they play nicely for your ROMsets, too. I have changed a few of the snapshots and cart_disk images that were in the pack I started with (which is worth noting if you plan to merge the folders at any point), for better or for worse haha.

 

[Wiimpathy]

Thanks for sharing your MSX data.
Regarding the chd format, I'm pretty sure the header is not the same as original iso/bin. When converting chd to iso we'd have to open the file with an hex editor to check the header.
I understand your frustrations with those databases.
But writing wiiflow code + creating those was a Lot of work.
I agree they need some cleaning. One the biggest issues is the cd based system, crc, sha1 is too slow in Wiiflow.
One better alternative would have been a pc program to check games(relying on existing online database), rename them and generate data for Wiflow. But again that's a lot of work...

 

[GhaleonX]

Thanks for sharing your MSX data.
Regarding the chd format, I'm pretty sure the header is not the same as original iso/bin. When converting chd to iso we'd have to open the file with an hex editor to check the header.
I understand your frustrations with those databases.
But writing wiiflow code + creating those was a Lot of work.
I agree they need some cleaning. One the biggest issues is the cd based system, crc, sha1 is too slow in Wiiflow.
One better alternative would have been a pc program to check games(relying on existing online database), rename them and generate data for Wiflow. But again that's a lot of work...

I'm happy to share anything I can contribute!

You are correct the header is different on a CHD; my initial thought was that a scan with something like chdman could be taking place (although eventually I determined that chdman [probably] doesn't show that info).

Please don't take me referring to "frustrations" as any kind of complaint or belittling of the work (which I'm very thankful you and others have contributed so much to, because this whole thing is nothing short of amazing) that went into getting it where it is - my frustrations are more about what's happened *since* that work was done anyway (like the collisions I mentioned). I do think they're really cool, and I am working on cleaning up and improving the others, as well.

One thing I tried to do was use some of the other control values to add certain boot-related data, but that was not exactly successful (still, I can include valuable instructions in the descriptions that can serve as the next best thing). While all this may seem like way too much effort for a console that's old enough to vote, some of this stuff can probably get reused in future projects that end up using similar frameworks (or not, depending on things).



This one is going to be a bit of a passion project for me, I suppose. Since the PC-88 stuff requires a lot more direct involvement (like which disks need to be in which drives at boot, and tape games can't even auto-boot like single-disk disk-based games), so I think including these details in my entries may be helpful to somebody someday if they ever use it.

 

[Wiimpathy]

That's a cool project. I also think writing game intructions especially for these systems is useful.
To be honest, I also thought of adding that instead of synopsis. Having both would have been ideal. Some kind of 'More info' button that gives access to small manuals... There are databases like GameBase that contains that info too. Or even manuals files but mainly pdf. Oh well...
I also think the WiiFlow gui is still one of the better for an emulation system.

 

[GhaleonX]

That's a cool project. I also think writing game intructions especially for these systems is useful.
To be honest, I also thought of adding that instead of synopsis. Having both would have been ideal. Some kind of 'More info' button that gives access to small manuals... There are databases like GameBase that contains that info too. Or even manuals files but mainly pdf. Oh well...
I also think the WiiFlow gui is still one of the better for an emulation system.

Thanks!

It started with me trying to edit a few MSX entries and trying to think of a way I could label MSX/MSX2/MSX2+/MSXTurboR, and then I figured explaining how to boot a game was arguably more important than a synopsis explaining why you may or may not be interested in said game (but both are important), so currently I'm basing my PC-88 entries as substitutes for a manual.

Since BlueMSX takes care of everything so amazingly well with letting us pre-write all the necessary CommandLines, I'm inclined to let MSX descriptions remain as they are unless I notice something I think could really use some additional explanation.

For PC088, this may actually make a difference in some users being able to play some things they may have been interested in, as I don't think there are any emulators for it yet that can automate it to the same level BlueMSX is capable of and multi-disk games don't all play by the same rules (Xanadu will have you keep your user disk in drive 2 for the whole game, while games like Asteka 2 will have you swap disk 1 with the user disk for saving/loading, and games like Ys3 actually don't boot from the main disk, etc.

I agree WiiFlow is one of the better GUIs for emulation systems - It really does transform the Wii into something that feels is not only fresh, but quite capable, as well (which is especially impressive for hardware that's 18 years old)!

If I was a capable programmer, probably would have immediately tried a couple additions to either your code or quasi88's, so I'm kinda happy that I'm not [yet], as it's given me the opportunity to research what the games I'm interested in need to boot normally, and I can at least gather, compile, and share that info with others through this method, which might actually lead to at least one other person who encountered confusion to play some PC88 goodness!

 

[GhaleonX]

I've been working on figuring out what's wrong with the NES database the past couple of days and have learned of quite a few more things to check for with my cleanup endeavors. Primarily that while you can technically get away with using '&' in 'name=', but some of the XML tools will flag it as invalid, and it makes me wonder if it could still be causing an error somewhere else that just isn't immediately obvious.

I feel like I'm really close to having a fully-functioning, robust NES database already, but it's not quite there yet. In the meantime, I'm gonna share my [rudimentary] scripts here in case anyone wants to experiment with them.

***Obviously, only use these at your own risk!

Name	Syntax	Function
syntaxvii.py	python3 syntaxvii.py filename.ini	• removes any values in the CRC32 fields that is not 8 characters • Checks for proper structure (name=GameID|Value1|Value2|etc) including trailing | • Creates a new file named after your input file with '_validated' added to it • NOTE: Does not create a log (but you will see an output in terminal if it does anything)
clean3.py	python3 clean3.py filename.ini	Removes all duplicate CRC32 values and puts them in removed.txt and names the cleaned file cleaned_file.ini (NOTE: It removes the first two header lines of the INI file, so put those back when you rename it)
conformii3.py	python3 conformii3.py filename.ini	Checks INI for lines with non-conforming characters and outputs them in a file named 'nonconforming.txt'
XMLfix3.py	python3 XMLfix3.py filename.xml	Searches XML for instances of illegal & and replaces them with & (it may do something else, too)
namii3.py	python3 namii3.py filename.xml filename.ini	Creates a file with each game ID and the name it uses in the XML file as well as the name it uses in the INI file (used for finding name mismatches)

These scripts have come in handy, but I try to see what changes they make and then make those changes manually in most cases.

Also, if you have a bunch of zipped ROMs and would like a handy-dandy CSV file that keeps track of the archive's name, filenames within, and their CRC32 values, you can open a PowerShell in Windows and navigate to the directory your zip files are in and paste this code into your PowerShell window:

Spoiler: Paste this code directly into a Windows PowerShell with the right-click

$results = @()

$zipFiles = Get-ChildItem -Path . -Filter *.zip

# !!! Ensure the path below points to where 7z.exe is installed on your system !!!

$pathTo7z = "C:\Program Files (x86)\7-Zip\7z.exe"



foreach ($zipFile in $zipFiles) {

# Run 7z list command (-l) with technical details (-slt)

$output = & $pathTo7z l -slt $zipFile.FullName



# Parse the output line by line

$currentFileName = ""

$output | ForEach-Object {

if ($_ -match "Path = (.+)") {

$currentFileName = $matches[1]

}

if ($_ -match "CRC = (.+)") {

$crc = $matches[1]

$results += [PSCustomObject]@{

ZipFile = $zipFile.Name

FileName = $currentFileName

CRC32 = $crc

}

}

}

}



$results | Format-Table -AutoSize

$results | Export-Csv -Path "CRC_List_7Zip.csv" -NoTypeInformation

Post automatically merged: Dec 4, 2025

I started to tidy my Quasi88 folder up a bit and I'm running into some issues and am not sure what

For example, Pocky & Rocky (USA) for Super Nintendo.

1. Look for the GameID in SUPERNES.ini

a) Based on filename minus region flags. If found go to #2 else b).
b) Based on CRC in this case.

Since this is the first order of its operations regarding identification of a ROM, would this mean that false positives might be occurring based on naming alone (even if we have both CRC values under different names in the INI file)?

Say with the example of Airwolf for NES - both games are quite different but basically share the same title, so, if someone has Airwolf(U).nes and Airwolf(J).nes in their directory, even though we have different CRC values for both games, it first identifies it by removing the J and the U region flags, and therefore [incorrectly] determines the user has 2 copies of the same game?

 

[GhaleonX]

- The rating /20 should be shifted in carbonik theme.
- The 'coop' value isn't used in Wiiflow.

Does 'rating' and/or 'control' work? If so, I can't determine the proper syntax. For rating, I'm specifying type as ESRB, CERO, or GRB and for value I've tried "E" as well as 0 and 1 with no visible result - I was assuming those things just weren't implemented yet, but rereading this part makes me wonder if it's just not displaying in the right area for the theme I'm using, and if that's the case, I'll resume putting that info in these updates I'm making.

 

[Wiimpathy]

No. It's not displayed for plugins in WiiFlow(only in my demo mod). And the ratings in the plugins databases were just screenscraper user's rating.
For controllers, not implemented either, well it wasn't some years ago.Here's a quote, 1st page:

Just like for Wii/GC games it shows the number of players. Personally I found it useful. And the coop value too, but for that we should perhaps add a new icon and the corresponding code off course...
Regarding the control type, it's just the default and same controllers in all databases. I didn't bother to change them per system (keyboard for computers, required classic/GC for N64 etc.).

 

[GhaleonX]

No. It's not displayed for plugins in WiiFlow(only in my demo mod). And the ratings in the plugins databases were just screenscraper user's rating.
For controllers, not implemented either, well it wasn't some years ago.Here's a quote, 1st page:

That's kind of hilarious then, because I only tried it that way because I opened it with a hex editor and searched for the "rating" string and found ESRB, CERO, PEGI, etc near enough to it that I just assumed THAT was the rating it was referring to (TBF, none of the XML files I have examined so far had any of those areas fully populated for me to deduce that from). I'm actually quite relieved to know why it wasn't doing what I thought it would do haha

Just like for Wii/GC games it shows the number of players. Personally I found it useful. And the coop value too, but for that we should perhaps add a new icon and the corresponding code off course...
Regarding the control type, it's just the default and same controllers in all databases. I didn't bother to change them per system (keyboard for computers, required classic/GC for N64 etc.).

I like the Players tag; I think that's definitely useful info. The co-op tag might be useful if we have an online co-op emulator to pair it with, but other than that, I think the number of players is sufficient for that area of info if we take screen real estate into account.

I've been replacing "nunchuck" with "keyboard" on a lot of entries for MSX and PC88 so far (or sometimes I just add it), at least for entries that I know use it to some degree, although you could kinda make the argument that any computer emulator technically requires a keyboard regardless. I assume the grand intention of it is/was to display an icon of each controller supported/required, which I think is pretty neat to have with the info, but also just a bell or whistle, so to speak...

Thinking about some of my previous comments - a lot of the things I think would be useful for a particular platform's database aren't exactly things that could even apply in others. Like the idea to have 'Platform' for which MSX machine a game was for wouldn't apply to most other things for the simple fact that we're just including all the different MSX platforms under the same umbrella whilst separating nearly every other platform, so I appreciate that a lot of ideas that could be "neat" aren't really things that are good for a universal system (and sometimes a terrible waste of time, I suppose). Perhaps if it were just a field one could customize to look like a tag that appears on the same page with the developers/players info could accommodate such whims.

Side Note: I've done a lot of changes to the MSX db since the previous one I've posted, so I'll share the updates here if anyone else wants to try them (and feel free to let me know any problems/errors with them and I'll try and find/fix them, too)

I've added several games to it that still aren't in screenscraper's database, found more characters to clean up throughout a lot of entries, too. I think that the apostrophes don't actually create any of the problems, but seeing as how there are multiple different iterations of how to make an apostrophe, it can lead to problems by accidental name mismatches, to say the least (though outside of that, it doesn't seem to actually "break" anything like an & that's not inside quotes or not closed with a semicolon). My current approach leaning towards cleaning all of them as I come across them, just to make uniformity a tad easier (and keeping validation as fast as I can lol).

I'm also including the NES one which I kinda jampacked a lot of work into and it's a little more than just "fixing Airwolf" that happened with it, but so far my testing with it is going well enough to share.

I'd like to get a few more entries squared away in the PC-88 one before I upload it, but I'll be sharing that one soon, too.

Post automatically merged: Dec 5, 2025

Oh, I also did some work on the 32X ones; they should be a little better now, too.