Maybe good and bad news.. good news is I found the problem.. kinda..
So I tweaked the code which draws the blocks in the editor, I looped back to block zero if it wanted to draw over 128. So that displayed the blocks on screen ok (but block number 128 then is block zero)...
After filling the block data full of zeros, it didnt change any output on the screen. Its not just some ram not being cleared causing the corruption either as its always the same looking. So the corruption is being drawn...
So then the bad news..
I think its a limit in the extension itself

More specifically "set block" command. I'm assuming it doesn't like blocks over 128 number and just causes it to screw up after that.
The lines after 790, those output the blocks on the screen. Though I dont really understand why it corrupts the world blocks like that. If you look..
Steem__00006.jpg
It looks like after block 128 it wraps around to the start of the screen again, as the white corruption parts from block 128 look like the menu bar at the top (white) then it seems to skew into your block data again. As to why it always seems to get the corruption from the start of the screen address, no idea.
Must be some odd bug in the world functions where over 128 it loses track of where the block data actually is (the block data is probably very close to where the screen memory is) so assume it gets confused and starts using the screen memory instead of using the world blocks in the data bank. Of course screen memory isn't in the format the blocks are (blocks have pre-shifting for starters) so you end up with odd corrupted graphics.
I guess TML guys never thought anyone would use more than 128 blocks, if they were double the size, then the editor screen would run out of space to display them all

Anyway, its back need needing the missing link source code, unless someone knows TML team to ask for the code, then nothing can be done ::(
Your only possible work-around is to draw your blocks in separate files, and swap the block address in real time. If you only want 50 blocks in a level, then just do that level with a 50 block bank with the world data, then your next level, use a new block bank.
Or if you really want to use more than 128 blocks on a single level, then your only option is to have something like 10 blocks which are common to every level (maybe water or something) then you use 100 blocks for the first section of your map, then fly over the water, at that point change your block bank address, as the water is same in each block bank, you will never know it just in effect loaded in more world blocks. Then when you fly out of the water area you have another 100 blocks you can use.
So..
load in bank 1 - (10 blocks of generic water) - 100 blocks of trees.
scroll for however long your first map section is
scroll over your water using first 10 blocks
load in bank 2 - (10 blocks of generic water) - 100 blocks of rocks.
Now your world in effect would have double the amount of world blocks... first 50% of your map with bank 1 blocks, second 50% with bank 2 blocks.
So when creating your world, you draw the first half with block 1 bank loaded, then second 50% with block 2 loaded. Of course this would look like the first 50% of your map is screwed up, but its why you would need to switch banks during the game play. As its just a address change, its not going to slow the game down any.
Hope that makes sense ?
The only other option is just not to use the world commands at all. Probably re-hack the STOS MAP editor to use bobs instead... I can't remember if you can scroll with the STOS MAP's function so you might have to scroll the screen yourself with SKOPY or something... I don't know if that would be to slow than using the world commands.
I would assume the world command is just using similar code to display the world blocks on screen as the bob code does, so might not be any speed difference overall. Also assume SKOPY is similar code for scrolling the screen as the world command does.. It might be worth doing a test map, just change the sprite lines for bobs, load bobs in, and just see how it looks ?
EDIT1:I used timer=0 and print timer after it draws the 154 world blocks on screen, and timer came back as 28. I looped displaying 154 bobs in a loop and timer came back 11.
So in that test, 154 bobs can be displayed on the screen in half the time that the world function is doing it

I tried filling the whole screen with bobs and timer came back as 16. Though looking at how fast they are all being drawn on screen , it looks like a couple of seconds. I don't think the framerate is that bad with the world command
BOBTEST.zip
Might be worth doing a loop with the world command, just see how fast it can actually display a single world screen ?
EDIT2:There is also "MANY BOB", seems the for next loop is very slow and that function solves it. So possible that could be fast enough for a world routine..
EDIT3:MANYBOB.zip
That is awesome! It actually shows a world type map and you can move the mouse and scroll about. Looks smoother than the world function to me!
oddly, the "many bob" command isn't in the DOC.. but its in the link.bas as a example. So for next loops are ultra slow then it seems aswell..
As the bob number, X,Y locations and XY offsets are all done in a array, you dont have to mess about with banks (unless you want to store the data in banks). It probably would be simple to create a ultra simple "world" editor using many bob. You only need to store the XY locations in a array as you draw stuff on the screen, thats pretty much it.
So I would ditch the world functions and go for manybob route instead. Of course you should probably check there isn't a bob limit of 128 first

Then write a new world editor, shouldn't take long. Probably design a new bank format to store the figures in.. probably just use the many bob data layout as a easy to work with bank layout..
It would just be something like X,Y,IMG,X,Y,IMG, X,Y,IMG...
So if you needed 100 screens high (about 250 blocks per screen) then thats 250 blocks with 3 bytes to store X,Y,IMG is 250 x 3 = 750 bytes per screen , x 100 screens, would need 74K of bank data.
Then have exploding stuff on your map , go remake xenon

My brain hurts now. Ask something easier next time

You do not have the required permissions to view the files attached to this post.