SWR's new xkas (Patches 4x faster than original) - Resource & Tool Releases

I've spent the last few months on and off trying to optimize the xkas code to simply patch faster and to add DLL and proper GUI support. I like to think I finally got it as good as it can be.

Download C++ command line application here.

Download .NET GUI application here.

Download C++ and C# DLL files here.

I did a lot of testing but I obviously cannot oversee every situation and every patch. So I hope you guys can try out this new xkas and tell me what you think of it and let me know if you see any errors.

Also, I added some new experimental commands to incbin. You can now add start(), size(), and end() commands. Some example uses are
Codeincbin Palette.tpl start(4)    ;Reads data starting at 0x04 and goes to the end of the ROM.
incbin GFX.bin start($8000) size($1000)    ;Reads 0x1000 bytes starting at 0x8000

I also added four brand-new commands which get numbers from the rom.

_fgetb() - gets an 8-bit number from a specified address in rom

_fgetw() - gets a 16-bit number

_fgetl() - gets a 24-bit number

_fgetd() - gets a 32-bit number

The functions are also recursive. For example
CodeLDA.w _fgetw(_fgetl($9AC1F)+.table1)+.table2,y

Lemme know what you guys think.
----------

Interested in MushROMs? View its progress, source code, and make contributions here.

oh wow nice job

I'm not getting this to work at all. The C++ CLI version doesn't seem to do anything for two of my files, and the third enters an infinite loop and starts leaking memory (memory usage went from 53 megabytes to ~200, while CPU usage was a constant 50%, in less than 30 seconds). All three are invoked with "swrxkas thistest.asm" in a batch file, with "thistest.smc" being a 0 byte file.

Code

lorom
STP
rep 0 : NOP
STP

Code

lorom
db 1+(1+1+1)*(1+1+1)+1

Code

RTS
incsrc thisfiledoesntexist.asm
RTL

I have not been able to test the performance nor the new features.

<blm> zsnes users are the flatearthers of emulation

How about trying it with an existing ROM then? I'll see if I can find out what's wrong here.
----------


Interested in MushROMs? View its progress, source code, and make contributions here.

Applying it to a 32768 file makes it work fine.
Applying it to a 32767 byte file replaces the entire file with a 0 byte file for no obvious reason.
Applying it to a 32769 byte file shifts everything one byte to the right.
Something tells me you installed a code to ignore the "header" directive and check the file size. What makes you think headers of other sizes than 512 bytes can exist?

You should also look into the infinite loops.

<blm> zsnes users are the flatearthers of emulation

Is there a possibility of you releasing the source code? I'd love to see this be compiled natively on linux.

Super Mario: Star Seeker

I want to have a stable build before I release the source. I'm just gonna fix the things Alcaro brings up then I'll release it.
----------


Interested in MushROMs? View its progress, source code, and make contributions here.

As long as you're modifying xkas, perhaps you could include an option that automatically warns you if you're overwriting anything? It would help prevent mishaps like this, at least. Something like "xkas.exe patch.asm smw.smc -w" would work.

I should get a new layout.

Probably won't, though.

Originally posted by Kipernal

It would help prevent mishaps like this, at least.

They should make a rule like:

"Define freespace clearly in a patch."

To prevent things like that.

I certainly can't complain about optimization improvements for good measure, but wow, was that really necessary for xkas v06?

I mean, my old Athlon XP 2000+ from 2001 could assemble all 400KB of source code for Dai Kaijuu Monogatari in a fraction of a second. An entire full-scale game probably wouldn't take over five seconds to build, if even that.

Oh ... or do you mean it's 4x faster than your port of xkas?

> You can now add start(), size(), and end() commands.

End is a bad idea, it is not immediately clear whether it is inclusive or exclusive. Eg if start=4000, and we want to include 2000 bytes, do we use end=5fff, or end=6000? What happens if we set start=4000, end=6000, size=8000? offset+length or start+size cover all possible use cases.

Doing end($6000) will read up to byte 0x5FFF

Also, you cannot do start() size() and end() all together.

You can either do start(), start() size(), or start() end().

Also, xkas will output an error if you attempt to read past the file size.

Also, the main reason I wanted to improve the performance of xkas is because I am using the xkas.dll for MushROMs. It's designed to patch every time the user saves. So I'd rather it not take a second every time the user hits Ctrl+S.

If you have anything more to say though, I'd be glad to hear it.
----------

Interested in MushROMs? View its progress, source code, and make contributions here.

Questions:

- Is this ready for release, or are there still bugs to be ironed out?
- Is it cross-compatible?
- Is the GUI the only thing that requires the .NET framework?

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

Originally posted by imamelia

- Is this ready for release, or are there still bugs to be ironed out?

Until this gives a clean result, I don't consider it complete (though I'm not sure if SWR agrees). It's much better than byuu's one, but still not perfect.

Quote

- Is it cross-compatible?

If this means "Does it work on Linux?", I'm pretty sure the CLI and library will work after recompiling (library may need some adjustments to tell which functions to export), but not the GUI.
If this means "Does it give the same result for all existing patches?", the answer is "Patches using conditional compilation with rep -1/rep 0 will break, but it'll print a warning for this. Changing it to rep -1/rep 1 will repair them while keeping compatibility with xkas6."

Quote

- Is the GUI the only thing that requires the .NET framework?

I'm pretty sure the answer is Yes.

<blm> zsnes users are the flatearthers of emulation

...Well, I just tested it on something that normal xkas was giving me trouble with, and it gave exactly the same result: It crashed without displaying an error message. What I was trying to do is insert the newer version of my custom block patch. I had xkas in a folder that also contained folders called "patches", "Page5", and "Page6". In the "patches" folder was customblocks.asm, which incsrc'd three files also in that folder (patches/cbptrs.asm and the like). One of those three, cblist.asm, incsrc'd files in the Page5 and Page 6 folders. If I move those two folders to the "patches" folder, I simply get a "file not found" message, but if I keep them where they are, I get the message-free crash. Any idea what might be causing this?

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

If you send me the files, I can debug and find out.
----------


Interested in MushROMs? View its progress, source code, and make contributions here.

Hey, I have a feature request if your open to it. I think a "-nowrite" command line parameter would be helpful for tools like spritetool and my stupid batch compiler. Basically a option that would preprocess and use print commands, put actually wouldn't output anything. Then again maybe I could do a write to NUL. I am not sure if that would work or crash badly.

Your layout has been removed.

It would work. I could do it no problem. Sure, I'll add it.
----------


Interested in MushROMs? View its progress, source code, and make contributions here.

Thanks. :3

Your layout has been removed.