Stands for iso_insert. Originally, a small utility that I made for injecting assembled code and data (binary), into a destination file (binary as well). It’s a simply utility; . The util will pad the destination file, if offset exceeded the original bounds of the destination file. For the hacking world, something like this is pretty handy. Often, you’ll need to inject new data and/or code into specific places of a rom or iso file. For small roms, I usually just include it as a binary into PCEAS and assemble directly into it. But PCE CD ISO hacking is a little different. Some games need the same code/data to be in multiple spots in the ISO (same data, just loaded from different sectors of the ISO for whatever reason).
If the data is the same, in all sectors/offsets, then this isn’t a problem. Simply copy a block to reassemble over (from within the assembler), and then copy the assembled binary back into the ISO. Done and done. That’s usually the case, but not always. Sometimes there are small differences between the offset chunks. While the area you are modifying specifically, might not change, the surrounding data might be different. This becomes a problem with PCEAS and it’s 8k output system. If you code/data starts somewhere other than the starting offset of an 8k bank or the data is less than 8k, you’ll have to manually cut/edit the binary in a hex editor – making the automated process… not so automated. For this specific situation.
Spriggan Mark 2 fits this bill. At some point in the game, it used a slightly different build of the game engine. While my code and data locations don’t change (logically), the surround data does. I can’t simply use one block for all the locations in the iso. So I’m modifying iso_ins once again. Adding source_offset and source_length parameters. But that got me thinking, why not just embedded a small part/liar into the file, in which the util could scan and use those parameters instead? The util would scan the source file for a specific ascii string (start of the copy parameters), and the end ascii string. From there, it would validate all parameters, and apply as instructed to the destination file. I can simply use the assembler’s internal logic/directives to create this list for me (automatically too). It could be anywhere in the binary, but I’d more than likely put it at the of the file. If the code/data size changes, I don’t have to worry about manually updating said parameters, because the assembler does that as part of the input data to the function that creates this list. That would truly be done and done.
I’m not sure if this would be of any use to anyone, but I’ll release it publicly anyway (probably over at RHDN too). I’ll make sure to have a switch for the last feature mentioned. I use it for a lot of stuff; not just pce projects. A simple command line util setup with a batch file. Run and done.