Ohh, okay. Sorry, wasn't certain on the scope. At first I was thinking a full editor (images, DLs, etc.)
Interestingly, the game doesn't just use a microcode system to set up stages and events, but like Eurocom's games also uses one in lieu of display lists.
Pushing files around would be remarkably easy. I would suggest building against the Japanese and PAL releases instead of North America. Japanese is already set up for NTSC and european for PAL, but uniquely the filemap for those two regions (after base ASM) is exactly the same and their tables are even at the same location. Both also supply the same amount of multilingual support.
I'm still tracing the microcode commands used for stage setups. There's quite a few commands and they are also used for triggers. Text triggers off of of an ID system, and altering text is remarkably simple once you work out the special escaped characters.
Have the formats for the FDOs, all but one type of PAK entry, most if not all text file escape sequence variations, and half of the world binary format. MUTs are a bit esoteric and one of the sound formats is undocumented as of right now. Actually, dumped all the FDO images.
I should point out those are all the resources that are drawn upon. Level files are the LRL files in PoolLRL. They use one of three major formats (BBLR, BBL1, BBL2) with string designators for each class within them. They reference the base textures and special object types, but oddly 'blocks' are defined more by a system of contour and repetition. It's a unique system to be sure.
[edit edit edit]
Stage construction is remarkably simple. Right now in documentation phase for all the different possible values and special features.
Basics are first four bytes of a CELL indicate its type and connectivity. Next three words are simple cartegian coordinates indicating where it belongs. There's optional floats after this to distort them and all, which is part of the reason for more documentation.
Things like circular and squiggly paths are defined by PATHs. These connect two cells automatically using particular mode flags and a given number of steps. Each step has a coded value, just like cells, to indicate their type and connectivity. For instance, the semicircle at the beginning of level 1120 consists of six steps between cells 1 and 7. Each is a 2way indestructible tile.
LODE sets your starting position and MONK starting positions for monks. EXIT is obvious and has a minimum gold value, and LOOT would be items. Right now I only a few item codes: basically keys, gold, and some powerups. LIFTs connect two rooms and are fairly straight-forward.
[edit edit edit edit]
Figured out the demo format too. DEM files just periodically probe the controller port. It's a slightly-simplified format, and the recorder might still be embedded (part of a debugger is), but basically just periodic probing. 'World 8' are all the demo files, which really just clone existing stages.
The only thing I'm not certain of yet are how falling gold is set versus static gold. Might be world-dependant, as both gold are a special case.
You could probably build an editor very simply. The only non-aligned blocks are generated via paths. These 'stretch' from one block to another and can follow curves, assigned via bitflags. Sometimes a few of the members will be invisible, in particular the 'stairs' in the first stage. Invisible blocks are occationally used, mostly as placeholders on lifts (this permits falling off one) but occationally to place an item/monk so they're above the stage and drop in.
Block schemes are hardcoded to worlds, as are what images are applied when using different pathing. If a block is destructible directly affects the image set, although once the level is loaded you can circumvent that. Arrows (and therefor connectivity) uses a different set of bitflags.
Special blocks and items are all simple to set up. They're applied to cells, and occationally invisible cells are used for this purpose. The only annoying thing is when an item/block is set in the middle of a path, although that just means you need to use an offset value to position it. Everything else is simple cartegian graphing.
Also, amazingly you can stuff comments into level headers.
I'll start typing everything out sometime between work. Might make a few proof of concept stages to demonstrate different things. It uses a simple filetable so really all you need to do is stick each file in sequence and mark the file offset. Decompression is based on extension.
Stage names are generated via formula and use the extension LRL: world, stage, level, sublevel (1110.LRL being the first level). So long as you stick to the original filenames all is well, but otherwise you'll have to hack the lookup. Other resources like objects are a bit dicier and do lookup based on name lookup in the general directory and relevant zip files. So, if you wanted to change one of those names you'd need to hack the codewords and/or lookup method.
Overall, super simple. You should be able to make an editor easily.