It's a .NET 2.0 app, you'll need the framework if you want to run this.
It doesn't suffer from slowdown with a jump table instead of an elseif style of searching blocktool uses. Two methods are / will be made avaliable for insertion blocks.
-xkas .asm files
-blocktool .bin files
Upon first time opening, you'll be told where it installed a hack. This is the same address you'd place in a hex editor (points to RATS tag). Then, you're free to add blocks and insert them. Save your changes and see how it works.
It generates two files at the moment. A "blocks.db" file which is the database for blocks avaliable for insertion and a "<insert ROM name>.bks" which keeps track of which blocks are inserted and what ID has been assigned to them. When you patch a blocktool patched ROM, it will just overwrite what it has previously placed there. It should pretty much behave like blocktool was never installed. If you'd like to try this, please make plenty of backups since I don't trust it much myself. I've tinkered with most of the hacks I have here and it seems to tolerate the new system just fine. Feedback much appreicated...
The pictures below should explain themselves.
The block data editor
The legacy .bin tab
Choose a block
Currently inserted blocks
I mentioned an .asm block for xkas, which an example of is shown here.
;template block, this example simply blanks the screen when mario stands above the block
JMP MarioBelow : JMP MarioAbove : JMP MarioSide : JMP SpriteV
JMP SpriteH : JMP MarioCape : JMP MarioFireBall
STZ $2100 ;reset
The JMPs MUST be there for it to function since that's what my code jumps to in the block (to replace the function of offsets). Basically what you have here is something that makes the screen partially black when mario is on top. The code always ends in RTL. Don't place header / lorom or orgs because the program does that automatically. There is no way for me to tell whether xkas has produced an error sicne it outputs a file uncondtionally, although testing a block in command line shouldn't be that much of a hassle at all.
Desptie that minor issue I chose xkas over TRASM because since TRASM is pretty much a fossil from the demoscene (1994) and as such has a few issues that really bugged me during sprite programming.
-Math system is busted. I remember trying to get some simple math going and had no success, then I gave up trying when not even the examples including in it's .doc were failing.
-Missing opcodes (ouch)
-Loopholes need to be taken when writing certain data to the output
-Errors which aren't caught at all (anyone here ever met the "wtf mate" error from sprite tool when TRASM outputs a different sized file between passes?). Really got on my nerves.
Let me know if it does anything odd. I've had success with .bin / .asm insertion.
-Delete works properly now
-Changing a critical element in the database for a block that is currently inserted warns you that you need to reinsert (just click the below menu item)
-Reinsert all menu option added, deletes all blocks then reinserts. You have to do this if you change any block data for already inserted blocks.
-Fixed issue with the program thinking a block with failed reinsertion is still inserted.
-Fixed issue where it would potentially overwrite critical unprotected data.
-Fixed issue where bogus offsets / reloc offsets would cause potential issues.
-If the contents of ROM are inconsistent with what the program thinks is in ROM, and message box pops up and the inconsistent stuff is removed from the ROM or the record.
-Sorts by map16
-Catches whether xkas is present or not, not sure how I missed this one.
-SA-1 mapping added
-Fixed issue where sprite index was not carried into block code (this fixes any sprite <-> block interaction issues)
-Added a hack for the many blocktool .bin blocks that would crash without hex edits
I'm also making some blocks, but not just rewriting the blocktool .bins in .asm form (unless there's something definable), but a few new ones. They're all in the .asm folder.