Getting a really quick, coarse view of what a file format looks like, easily picking out different types of data. Try uploading a SNES ROM or similar and you'll probably see a lot of distinct squares because of how the ROM banks work.
Super Metroid has a surprising amount of filler scattered all over.
> Super Metroid has a surprising amount of filler scattered all over.
It only really looks scattered because the visualizer uses a space-filling curve instead of laying out the bytes of the file linearly. If you change the curve to "scan" instead of "cluster", it becomes a little easier to see what the filler is: it's the unused space at the end of each ROM bank.
(As someone who's spent a lot of time in that particular binary, I think the use of the space-filling curve obscures a lot of details that would be a lot easier to spot otherwise -- such as the structure of the ROM banks, the location and layout of various pieces of compressed and uncompressed data, and repeated structures like a couple KB of common routines that are duplicated at the beginning of every bank containing enemy code.)
Did you happen to catch the post regarding ROM dumping the Nintendo Gameboy (DS?) by allowing the crashed game play through eventually playing ROM contents? just wondering if that's what gave you the idea here. But I agree, ASMr would be interesting!
Super Metroid has a surprising amount of filler scattered all over.