Hacking VCFE Wip...

[HowardC]

Just a quick Update....

Since the brlyt editor is driving us all crazy, I thought I'd give it a rest for a while and start work on the save injector. I've cleaned up the interface, added browse buttons, and added slots for all consoles. Because it is quite confusing figuring out if you have the paths pointed to the correct thing (in some instances I ask for the path to the text file for the save name, in others it's the folder where all the stuff is stored, sometimes it's the 1.app ect...) when you select a console the paths are filled out with a generic example of what you should be pointing to. Also I decided to have the app read the original save title as you set the path. This is yet another way of letting you know that you have everything setup right.

ATM the injector doesn't work, I'm just getting things ready, but the big issue was the save title editing. (as most of the consoles need a simple replacement tpl with no special tweaks on the graphical end). The app is currently able to read the save title for all consoles except the c64. Injecting new text will be rather simple as I'll just do the opposite.

I might release an alpha version tomorrow if you guys will help me test. A very NON WORKING alpha version. We need to make sure it always reads titles properly. I've personally tested every one and it works, BUT I only have one wad with some systems, so more testing would be nice.

 

[RadioShadow]

For the compression tool, we could use CXTOOL by alpha-0.

This tool allows compression and uncompressing files with method 10 and 11.

Compress 00000001.dol to 00000001.app using compression method 0x10:
wwcxtool /c0 00000001.dol 00000001.app

Compress 00000001.dol to 00000001.app using compression method 0x11:
wwcxtool /c1 00000001.dol 00000001.app

Some .dol (00000001.app) files in the NES and SNES Wads use the Method 11 compression. Some will need to be uncompressed so the Save Title (for NES's case, dump the Save Banner as well) can be changed.

Also some later SNES Wads (Super Mario RPG and Secrete of Mana 2 [Japan]) have started using the Method 11 Compression on the roms.


The files in the 00000000.app use the Method 10 compression. The files are compressed like so:

- IMD5 is used for the first 32 bytes (uncompressed).
- Then four bytes appear afterwards being: 4C5A3737 (saying LZ77 in ASCII) (uncompressed).
- Then the compressed .dol file (using Method 10).


HowardC, it might be worth modifying the tools to use that compression tool instead. It might fix the compression problems we've been having.

Hello HowardC, i have here an problem with the C64 banner/lz77 compresion.


As you can see, the white Space get transparent.
It does not make any diferenc if i use your tools, if i do the tpl by hand or i just use the original tpl without modifying(simply unpack and repack).

Do you have an idea?

The LZ77_banner.tpl in the Commodore 64 Wad seems to be using the compression that is used for graphics in GBA and some DS Games (like Advance Wars DS).

Using GBADecmp successfully uncompresses the file. It should successfully compress the file correctly.

EDIT: And to prove it works:

HowardC is going to have fun updating his tools.

 

[HowardC]

Well, it was my understanding that cxtool was part of the nintendo sdk, and thus I don't want to use it even if it does work better.

GbaDecmp might be as well.

**EDIT**

OHH, you mean wwcxtool.

There's a very good reason I dont use that one... I've tried and tired and I've yet to get it to work.


**EDIT2**

Just to make sure I wasn't nuts, I went ahead and plugged it into the u8 tool and tired to decompress a banner.bin. It failed. I also tried to decmpress it by using the command line manually, it also failed.

So either method 10 is NOT lz77 compression, or the tool simply doesn't work.

**EDIT3**

Well gba decmp is slightly more promising but unless someone has more info on it, it's completely useless for our purposes as it doesn't have a command line option. The app appears to be either a vb app or a vc app and the bulk of the work is done with the dll, but as I don't have any example of how to declare the dll I can't use it.

 

[HowardC]

On to better news...

I went ahead and worked on the save icon/text injector this morning and things went really well. I haven't actually installed any yet, but judging by the hex compares, I have every system working but msx and c64 with the text injection. N64 has issues with the japanese entry, but when don't my apps have issues with the japanese entry.

I need a msx banner.cfg.txt to confirm the format if somebody can send that to me, but it's really just a formality.

As for the c64, I've yet to find it. I think the text is stored in the 1.app, but they are always compressed on the c64, so I'll have to check.

 

[gundalf]

Many many many thanks RadioShadow

@HowardC
Look for 0062616E6E65722E64617400002F62616E6E65722E62696E00
in the 01.app for C64 Wad's

 

[HowardC]

Many many many thanks RadioShadow

@HowardC
Look for 0062616E6E65722E64617400002F62616E6E65722E62696E00
in the 01.app for C64 Wad's

Thanks a bunch man, I didn't realize it was that obvious. My hex editor must be acting up because when I searched for a unicode "International Karate" it didn't find anything. It's nice that in the case of the c64 there's actually some buffer space so you can extend the text. I'll look into adding this tonight.

Ok just to summarize for documentation purposes. The save text is stored in 1.app imediately after the string "/banner.bin" in unicode.
You have a setup similar to the snes text, except it's 68 bytes per line instead of 80. First line is 68 bytes giving us a total of 34 english characters to work with. the second line starts on byte 69 and is again 68 bytes long for 34 characters of text. There is some extra paddign after that, but don't be fooled as that isn't part of the text buffer.

Something of note about the plain text, save text files as well. (Sega Games and what-not) Again, just for documentation purposes.

At first glance, it appears that thy are plain text files, but actually they are mixed unicode text files. What does that mean? Well in any programming language when you print text to a file it's stored in "dos text format" which is basically the ascii code only (one byte per character). Mixed unicode obviously uses two, but also allows for different regions of text to be stored in a single file, thus the japanese and english text in the same file. To create a mixed unicode file programatically you do the following:

1. Take all the english portions of text (yes all of them) and convert them to unicode. (Bascially add a null character between each character)
2. Merge the asain text as-is with the converted english text. (This may be a staged process as usually the asin text is in the middle of the document.)
3. Put a "þÿ" at the beginning of the text file. Yes it looks odd, but this tells notepad (and any other text editor) that it's a mixed text document.

It sounds easy, but the generation is very tricky. Notepad and probably the wii determine if text is asian or english by checking for a null before each character. Keep in mind that some asian text has the second byte null (like 4 & 0 = "40") so if you get even a single null out of place when doing the unicode conversion of the english text, everything will get shifted out of pattern and all text after the screw up will be in kanji!

The bad news about this style of document is you pretty well need to know where your asian text is ahead of time as there isn't any easy way to determine if a lenght of text is asian or not. This means that the save icon injector, at least atm, only allows the replacement of the japanese line with japanese text. I shoudlbe able to force a work-around later on.

 

[HowardC]

Ok, I've went ahead and plugged in read support for the c64 and it works just fine. I'll add write support sometime tonight. It should be ready for testing very soon.

Also, on an unrelated front, I've went ahead and added read support for wte and banner.bin (neogeo save icon) to the tpl editor fe. I figured this would be useful for debugging reasons as we don't have any way to actually read wte's and the banner.bin other than through hex editing. I think I might also add support for extracting the NES/FC icon. I already have to extract it for the save icon injector, so it'd simply be a matter of saving that hunk of data instead of replacing it.

I can also add write support for wte files later on, but seeing as how they are only used for icons and we have the icon generator I really don't see the point.

 

[RadioShadow]

**EDIT2**

Just to make sure I wasn't nuts, I went ahead and plugged it into the u8 tool and tired to decompress a banner.bin. It failed. I also tried to decmpress it by using the command line manually, it also failed.

So either method 10 is NOT lz77 compression, or the tool simply doesn't work.

**EDIT3**

Well gba decmp is slightly more promising but unless someone has more info on it, it's completely useless for our purposes as it doesn't have a command line option. The app appears to be either a vb app or a vc app and the bulk of the work is done with the dll, but as I don't have any example of how to declare the dll I can't use it.

Using the wwcxtool does work for uncompressing some 01.apps so it will be worth using it for that. Must be a different type of compressing used for the banner files then.

Would the souce code help in order to figure out the compressing? NLZ77 contains the souce code.

I'll also send you the MSX Wad HowardC by e-mail.

 

[HowardC]

I'll look at the source, but no promises as it's in c# and some of the variable types used in c# don't have a vb equivelent. (Plus I'm not quite as familiar with the syntax.)

GbaDecmp would probably be best as it's self contained, I just don't have enough info to use it in the code. The author's website has disappeared which is unfortunate as you can tell he intended for everyone to use his dll, but without declaration examples it's farily impossible to do so.

 

[HowardC]

I went ahead and released the new version of the tpl editor which will be quite useful for debugging once the injector is released. It'll now read wte files as well as neogeo's banner.bin save tpl and extract the tpl from the 1.app of a nes/fc app.

 

[RadioShadow]

I'll look at the source, but no promises as it's in c# and some of the variable types used in c# don't have a vb equivelent. (Plus I'm not quite as familiar with the syntax.)

GbaDecmp would probably be best as it's self contained, I just don't have enough info to use it in the code. The author's website has disappeared which is unfortunate as you can tell he intended for everyone to use his dll, but without declaration examples it's farily impossible to do so.

I found this site: http://members.iinet.net.au/~freeaxs/gbacomp/#LZ77%20Example

GBACrusher uses Command Prompt. Would that be more suitable?

 

[HowardC]

HowardC

When using the U8 Tool,

If I decompress all files and then compress all files without closing the program everthing works correctly. But if I decompress files, close program then try to compress files. I get a runtime error '76' path not found. Then it deletes the whole directory and I have to start again.


Not sure if this is a problem with everyone but happens everytime with me on 2 different computers.


on a side note:
Thanks these programs are making things alot easier to make new wads. Keep up the good work.

I was finally able to replicate that error and I've fixed it accordingly. The new version will be up within the hour.

 

[HowardC]

I'll look at the source, but no promises as it's in c# and some of the variable types used in c# don't have a vb equivelent. (Plus I'm not quite as familiar with the syntax.)

GbaDecmp would probably be best as it's self contained, I just don't have enough info to use it in the code. The author's website has disappeared which is unfortunate as you can tell he intended for everyone to use his dll, but without declaration examples it's farily impossible to do so.

I found this site: http://members.iinet.net.au/~freeaxs/gbacomp/#LZ77%20Example

GBACrusher uses Command Prompt. Would that be more suitable?

Unless I'm missing something, gba crusher doesn't extract files, it only compresses them.

 

[HowardC]

I updated the u8 tool yet again tonight..... I STRONGLY SUGGEST that everyone download this new version.

While I was working on the save icon injector I went to extract the 6.app for metal slug and the thing took like 15 MINUTES to extract! I looked at the code, and while there weren't any bugs, there was a single line that would make extraction slow on any app that has a lot of nulls in the file. So I changed that portion and extraction is nice and fast again.

Apparently this "bug" has been in there for quite a while. I can't believe nobody complained about it before.

 

[RadioShadow]

It does take a a while to extract N64 file in the 05.app. I'll see if the update upacks it quicker.

And I'm sending you the the MSX Wad now.

I'll look at the source, but no promises as it's in c# and some of the variable types used in c# don't have a vb equivelent. (Plus I'm not quite as familiar with the syntax.)

GbaDecmp would probably be best as it's self contained, I just don't have enough info to use it in the code. The author's website has disappeared which is unfortunate as you can tell he intended for everyone to use his dll, but without declaration examples it's farily impossible to do so.

I found this site: http://members.iinet.net.au/~freeaxs/gbacomp/#LZ77%20Example

GBACrusher uses Command Prompt. Would that be more suitable?

Unless I'm missing something, gba crusher doesn't extract files, it only compresses them.

*checks* Oh. I'll keep looking. I might go and ask at romhacking.net and see if they know any LZ77 Extract/Compression Command Line Tools.

 

[HowardC]

Thanks man, that'll be extremely helpful considering msx wads aren't even available in the US.

I'm upping the Icon Injector as we speak. I've tested these on the pc via hex compare, but I haven't done much else in the way of testing. The icon injector works in conjunction with the icon generator. By that I mean you use the banner.tpl my generator makes to create a neogeo banner.bin and use the wte files my generator makes for the sega files.

Because some consoles have multiple image files and some consoles have multiple files that store the text and some consoles store one and/or both inside an app or other special file, injection can be VERY CONFUSING. PLEASE READ THE DIALOGS WHEN USING THIS APP.

I would appreciate it if everyone could help out with testing. I'm very confident that the sega-style injections work, but testing needs to be done on the nes, snes and n64 in particular. Nes and NeoGeo DID work on the old version of the tool, but since I've changed everything around a bit, it might be worth re-testing.

 

[HowardC]

Looking at the msx wad and contemplating my next app (the rom injector/copier) this one is particularly interesting. The menu to the app appears to be a swf, which is very strange, but cool because in theory someone with flash experience (read NOT me) could make an english version and that'd solve our language issue. The roms themselves are stored in a ccf and have a plain text file telling the emulator which roms to load and in what order. This is very similar to the tg-cd roms and should be very do-able to add, assuming that the roms haven't been radically altered.

Other than that, as RS has said, it's very similar to sega files. There's even a region setting in one of the files and my guess is getting this to work in pal might be as easy as changing that value. Not that I could test that as I have a ntsc wii.

 

[HowardC]

More info on the msx.

I downloaded the bluemsx emulator for the pc and the rom that was included with the wad matches the official msx emulator wad exactly! It also loads just fine.

There is a wad that appears to be a save state though, but I'm not so sure it's needed.

Here's what's inside and what I found:

aleste_d4.meg (256kb)...... This is the actual rom. Needs to be loaded in cartridge slot 2 of the emulator.

msx_aleste_d4.rom(32kb).... Appears to be some sort of save state/bootloader. Interestingly enough loading this in slot2 will also load the game.

fmpac.rom..... This is qbasic and the midi program that generates tones (similar to the old soundblaster tsr in dos) it should be the same regardless of the game

arch...... A plain text file that contains "msx" and nothing else. Maybe the emu supports different msx models?

init..... This is the header file telling the emu how to load the roms.

Init looks like this:

load-rom msx_aleste_D4.rom 0
load-rom aleste_D4.meg 1

Remember I said in the emu you had to load the rom into slot 2? Well init tells the wii how to do that. Notice the mystery file is loaded to the first slot. My guess is we could omit this and an injected game would run fine, or we could use one of the generic files used by bluemsx as a replacement. I'll see if I can find a match.

 

[RadioShadow]

"Invalid control array index" when opening SaveInject2.0.


Rom injection looks like it will be pretty easy (well just MSX1 at the moment) but it's modifying the controls on the Controllers.

If you look in the 'config.zlib' file, you'll notice some controls for mapping the keyboard:

country="jp"
romfile="Aleste_D4.ccf"
player.0.bindings_override="(core b=A)(classic x=A,y=C)(gamecube y=A,b=C)"
player.0.mapping_keyboard="A=SPCE,S=FK09,X=AD05,Z=ESC"
machine_msx.enable_opll="1"
config_menu.disable_staff-credit="1"
config_menu.disable_ds-controller="1"

A lot of it is kinda confusing. It's just different MSX games use different keys so it would have to be modifed in order for the game to use the controllers.

The interesting thing is the MSX can use a USB Keyboard (unlike the Commodore 64 which uses a Virtual one) which acts as it would do on a MSX (besides STOP = F9).


EDIT2:

I've just downloaded EGGY for the MSX (the game makes no sense >_

 

[HowardC]

The injector is fixed.... it was some kind of crazy bug/fudge up during compile. The thing nearly crashed my pc when I downloaded it to find the error!

Regarding msx... it's not THAT crazy. Japanese "pc" games have a standard similar to us games. While our defaults are based on doom (numpad and/or arrow keys and ctrl alt and space for buttons). Their defaults are based on earlier msx standards, namely arrow keys for movement and z, x and c for buttons. Aleste uses these keys as well (at least on blue msx it does) so the extra re-mapping in the wii is probably optional. As you noticed eggy doesn't use any remappings.