The GBA supercards are awful as GBA flash carts so I would advise not going too much further with it -- the entire GBA supercard line, save for the rumble which had no memory at all, use inferior memory and thus most games get extensive speed patching and such. Get a proper flash cart (anything other than a supercard or one of the clones like the team cyclops one will be better) and try that if you want to go that path. Theoretically as multiboot should be all in RAM it should work but eh.
If you must then try running it through the header viewer of GBATA ( http://www.no-intro.org/tools.htm
) and maybe http://www.gameboy-advance.net/rom_tools/flash_advance_toolkit.htm
to see if it gives you the option to fix it. Offhand I am not sure what the supercard does as far as soft and hard reset to launch and it might be something as simple as the header, said header might also fix the emulator issues.
It could be something like a GBA emulator will try to load it as a normal ROM (location 08000000-09FFFFFF + mirrors) in the memory where the multiboot game expects to find itself in the actual memory (the 02 or even 03 range) and that would quickly find itself coming unstuck.
Being memory based you could also build yourself a multiboot cable if you are really invested in this ( http://reinerziegler.de/GBA/gba.htm#Multiboot
). Depending upon what you are doing it might even be easier to do that than writing a GBA flash cart every time you want to test a new version out.
There is also the potential cowboy way of port a savestate and edit that (if it is all in memory it should all be there, hopefully nothing gets released after it is in VRAM or something) but I would say avoid that for now.
Other emulators. Multiboot games as they tend to be called can approach the world a bit differently. I am slightly surprised VBA did not work with it as we tend to find problems come not from inaccuracies but being overly harsh (improper headers and whatnot) and VBA tended not to do be that, though I don't know what VBA-m might have done. Did no$gba work with it? If it does then time for some tracing ( https://www.romhacking.net/documents/361/
, I know it is for the apparently non working VBA but the logic carries over to basically anything you want to debug on).
The utility you link is a decompression tool and given the multiboot games have a very limited amount of storage space (you kind of have to get it all in RAM after all, and still have enough to use with the game) that is not unexpected. It would also mean straight tile viewers are not likely to show much.
Colours are a palette thing so no worries there. Alignment I would have to see -- if it is just the usual jumble of tiles then so be it (figure out the map or work around it), if it is a more trapezoidal deformation then it might be a custom tile size.