Share This Page

For those of you who don't know, I've been working on a turn-key solution for injecting roms to the virtual console. Basically you'll select the system, select a donor wad, click "inject" and the rom will be injected, the banner and save images will be automatically generated (from base images you point to), ect..... No hex editing or nothing. More info can be found in the banner editing thread.

In order to do so I've had to start building a rather extensive toolset, based around the info we know about the various vc emulators. I am getting close to the point to where I'll need help discovering info and/or help with beta testing, so I thought this would be a good time to start a dedicated thread. This top post will be kept updated with any tools that are released.

Misc Utilities:
=================Tpl Editor 2.0 (Loads tpls of any type and any number of textures. Loads most image files and can convert back and forth. Can also load wte, banner.bin and 1.app tpl variants.)

Note: I know some of you can't access rapidshare links, but I use it because I can upload a file without an account with a single click and I don't have all the time in the world. Anyone wishing to add alternative links do so in the thread and I'll add them here.

This morning I went ahead and finished the ccf and u8 tools (will be released this weekend) and I went ahead and started looking at the brlyt files (banner info) again so I could allow larger names to be added. While I haven't figured out how to set the text length yet, I may have ran into something better.

I believe I have cracked the color format!

For those of you that don't know, all the images in a vc banner are greyscale except the snapshot, and all the coloring is done via brlyt file. Some banners have issues when we re-pack them (tg-16, neogeo) so we use a template banner based on the snes banner. This is all well and good, but the color scheme is still that of the snes! Hopefully, the info I've found will make it possible to use a single banner template for all of our wads, simply replacing the background image and changing the color scheme for each system.

The color format appears to be as follows:
============================

Under the header (quite long) that starts with "wbf1.brfna.mat" there are several material "nodes" Each node contains a great deal of data (unknown atm) including the color info.

The colors are in standard rgb format, but obviously in hex. (red green and blue values printed one after another with a range of 0-255, or in this case 0-FF)

Two color entries alwys seem to be present even if both aren't used (the first is simply repeated). The names of the nodes are rather cryptic, but these are the ones I am fairly certain of.

======================
VCPic = Snapshot
VCPicSha= Snapshot reflection/shadow
Shade=Gradient on the bottom of the banner (two colors)
PFLINE=The colored bar on the top of the banner (pfline stands for platform line, two colors)
Yearline=Color of the little line below the year
PlayLine=Color of the little line below the Player info

T_PF=The text on the colored bar (pf stands for platform, two colors)
T_VCTitle_###=The color of the game's name (###=the region, there is a color entry for each region)
T_Play_##=Player Text color
T_Year_##=Year color

There are also around 5-10 more, but the names are pretty vague and the colors mostly black or grey so it's heard for me to figure them out without changing them to see what they do. Most seem to involve the various layers of the background (logo, background color, grid color, ect....)

I'll be adding color functionality to my info editor soon to test this more, but feel free to play around with it via a text editor in the mean-time. I'm uncertain as to which entry is which, but I AM certain that they are colors (a snes brlyt i looked at had most of these entries come up "purple" while a neogeo banenr had them come up shades of yellow/orange so that's too much to be a concidence.)

That's something that's really excited me while reading all of your updates. You often go looking for one thing, but end up finding something completely new and useful that no one else has come across before. So rad.

About beta testing, you know where I'm coming from in the banner making scene. I'd be honored to beta test for you!

I made a crude little representation of the VC banner and when you load a brlyt file into the viewer, it updates accordingly. There are still some mysteries to solve though. I have no clue what VCPicSha changes, but I do know that it holds a color that is NEVER used. Also some colors seem to be repeated. Back1-Back4 are always the same, and represent the logo tint. Ditto With backmask1 and backmask2. Also the use of shade and vcpicbase are unknown as well. I've included sample brylts from each system in hopes maybe you guys can study it a little more closely and figure out what the mystery colors are for.

Ok, I seem to have gotten a tad bit closer to figuring out the brlyt files. It occured to me that in order to find the size values, I need to compare two files that were extremely similar, so that the differences would be more obvious. I'm currently going over donkey kong country 2 and donkey kong country 3, and at least initially, it seems to have done the trick.

There are only minor differences between the two files (three in fact)

The first one is fairly obvious.....

Each file starts with RLYTby....##

Where ##= the filesize. I confirmed that the values of the two files are indeed the filesizes, so that mystery is solved.

Each set of text entries starts with a "pane" entry looking something like this:

txt1#### 01 00 T_Name_OF_TEXT_REG

Where "####" is the size of the text node. , and T_Name_of_text_REG = the name of the text node + the region

Then there are about 7 lines of header info (most of it is unknown at the moment) followed by the text itself and 4 "00"s for a buffer to the next entry

At bytes 77-78 and 79-80 the size of the text itself is listed (it is the text size+3, probably to handle that buffer). Oddly, it's repeated twice.

So to retrieve the text of an entry (assuming you've found the node already) you would:

1. Read the start postion ("t" in txt1)+5 for 4 bytes to get the node size
2. Make a temporary variable and put the node into it using the node size.
3. Read bytes 79 &80 from the temp variable to get the text size.
4. Read the LAST (working backwards) bytes of the file for the text size +1 (there is a 00 buffer at the end, remember)
5. Format the text to get rid of the 00 entries and other junk.

To REPLACE the text of an entry (again assuming you've already found the node) you would:
1. Do steps 1-3 above
2. Copy the temporary variable to yet another variable (we'll use an unaltered version later)
3. Take the node and trim the LAST bytes off the file for the text size +1 (thus removing the text)
4. Take the text you wish to replace it with, covert to the hex format (00's between each character) add 4 00"s, and add it to the end of the node, taking note of the length of the text you just added.
5. Make a note of the length of the modified node and reset bytes 5-8 to reflect the new length.
6. Take the length of the text you added in step 4, subtract one and reset bits 77-78 and 79-80 to reflect the new length.
7. Use a replace function (varies depening upon the programming language) to replace the unaltered copy of the node you saved in step 2 with the modified node in the main file.

Of course if any text is modified, once you are completely done the new file size has to be used to set the bytes at the top of the file.

For those of you who aren't getting it here's the gist in plain english:

I should be able to allow us to replace these texts with text lengths of any size, which is something that up until now, was impossible.

Well done, HC. Not only are you making the easiest tool available for custom VC games, but you're also going further than anyone else has to make it the most comprehensive tool imaginable. Again, very well done. I very much appreciate your effort and am sure the rest of us end users do, too!

I also want to say keep up the good work. I know well from previous hobbies of mine how tedious reverse engineering can be, but I also know how rewarding of a feeling you get once it's all said and done. I wish I had more spare time, I would be into this like white on rice. Who knows, the opportunity may yet come knocking...

I think I've finally gotten a handle around the text lengths now. I went ahead and updated my info editor (now officially re-named to brlyt editor as it'll be editing colors as well) to search for a brlyt's various text entries the proper way and it works, so I must have figured it out.

To set the text in this same way only requires me to first search for the text_node, (which I can now do) read it to determine the text length, remove the text portion (always at the bottom thankfully) replace it with the new text, and update the size values accordingly. It shouldn't take long for me to implement this.

Something of note for those of you following along is some of the data above is WRONG. I got a little confused when reading the hex and read the header to the next entry instead of the one I was working with. I will update those two posts in a sec.

I will release the current builds of the often promised u8 and ccf tools tomorrow for you guys to beta test. If we are lucky I should also have a build of the new brlyt editor ready to go as well.

I've been busy the last few days, so no releases, sorry. Anyway I seem to have hit a snag somewhere with the text editing. The gist of it is this: I've successfully edited files to have names with the same size or smaller (this time properly, with the exta bytes being trimmied off instead of blanked out) and they installed fine. Unfortuantely, when I make a larger text entry, it crashes the banner. This is EXTREMELY odd because I've compared two brlyts of the same with with everythign the same except the game titles, and the ONLY differences are the ones I've mentioned above. There's one more value the changes (after the size repeated twice) but it still seems to be unrelated. Anyway, I'm too tired to work on it right now, but I'm sure I'll figure it out. It could be that the size of the banner is referenced in some other file within the banner (maybe the animation files?) and that is what is causing the crash.

Well I figured it out (FINALLY) and only because it's SO wierd I'm going to share my findings here.

I started studying the text entries of banner files and finally, upon using a hex editor to remove everything but the six "VC_Title" entries for several files did I notice the pattern. The whole section ends up being a multiple of 8! Why didn't I see it before? Well here's where the wierdness begins. The headers for each individual entry aren't multiples of 8 (they're like 117 bytes or something like that.) but when you add 6 of them together it becomes a multiple of 8. Ok that makes sense... but the actual text bits are always multiples of 8 right? WRONG! They don't have to be and often in official brlyt files, at least one of them isn't. What the developers do is add some extra null strings on another entry to make up for it so that when you add all 6 together they are a multiple of 8 and then you combine that with the 6 header entries (which are multiples of 8 only when added together) and you get a multiple of 8! Why would any saine format do this? You don't have to "seek" when parsing the files because the length of the text entry as well as the text portion itself ARE GIVEN IN THE FRIKKIN HEADER!!
See why it confused me so badly?

This crazy method does anaswer a lot of questions though... like why there's always 2,3 or 4 00's at the end of a text entry and why on some really odd ball ones (Ocarina of time) there are a bunch of nulls between line 1 and line 2 of the title.

Anyway long story short, I changed the title of Ice climber to "Ice Climber 2: Electric Boogaloo" a few min ago and it worked! We can now lengthen text entries!

Now the bad news is I adjusted the padding manually this time so I still have to code it. Also the way official files to it, is frankly, insaine so I'll be doing it my own way and insisiting that each entry is a multiple of 8 to simplify things. I can easily do this by simply loading the text for each entry and then re-saving though, so it shouldn't be too bad. I'm sick of working on it now, so I'll go back to the u8 and ccf tools and get them ready for release. Expect a release real soon.

Wow. Bravo on figuring that out HowardC. You've done some very impressive work here! I admire your determination to figure all of this out and compile it all together. I'll gladly beta test when you release it.

Just a quick chime-in... the latest version of u8tool is released and can be found up top. This one has those handy browse buttons and fixes the sound.bin error (amoung other things.) You should use ONLY this u8 tool from now on as it's the only released one that fully supports all forms of u8 archive.

this is awesome. seriously. i never even went through the trouble to banner my injects. its more trouble than it is worth in my opinion.

Click to expand...

Not if you are me. I don't mind missing manuals ect.... but I like things to look nice... I don't want thirty Super Mario icons on my wii for my nes collection.

Side note... ccf tool is up... it lets you open the data.ccf in sega consoles and replace the rom/banner files for those systems. (Yes, in theory you could do a manual sega master system injection using this tool, you'd just have to change the id in the ticket manually)

I thought now would be a good time for an update. The brlyt editor is almost finished. It will support editing the text (obviously) to any size as well as changing the color scheme, which will allow us to make banner templates for those problem games in which the banner gets corrupted when you edit it. I will probably also make an option to replace the background logo (a simple file copy... no need to edit the banner) to complete the effect.

Also for you sega fans, I have good news. I extracted a sega master system rom using my newly-released ccf tool and tried running it on a master system emulator. It ran fine without editing, which means that the master system roms aren't in any special format and it'll be very easy to add injection support! For you impatent fellows out there you can actually inject roms yourself.

1. Unpack the wad.
2. Use my u8tool to extract the 5.app
3. Use my ccf tool to extract data.ccf inside 5.app.
4. Replace the SMS file inside the data.ccf with the rom you wish to inject. (Use the same file name!)
5. Edit the 4 letter codes in your ticket and tmd files to a new value (totally optional).
6. Pack everything back up. Be sure to use the -sign option when re-packing the wad.

Anyway, that's all for now.... expect a brlyt editor this weekend (probably.)

Well done, HowardC. I'm off on a weekend trip tomorrow, but I expect I'll be updating some Genesis WADs with proper save icons when I get back! Any idea where the save icon text is located in the data.ccf?