... slow rom? Hate to break it to you, but the cause for slow down in most (all?) games is when there's too much activity and the software is doing too much at once. Has nothing to do with the speed of the rom itself.
Are you confusing lo-rom and hi-rom?
Interstitially you are both right and wrong at the same time.
Yes Slow down happens when the game has to execute to much code that it can't get it all done in 1/50 or 1/60 of a frame, thus it frames out and you see 50/60 fps drop to 25/30 fps or 12.5/15 if it really bad.
However how much a SNES can do in 1/50 or 1/60 of a frame is 90+% dependent on how fast the ROM is. Slower ROMS >120ns means the SNES can only run at 2.68Mhz, FAST ROMS <= 120ns means the SNES can run at 3.58Mhz which gives you an extra 33% approx. which allows you to get more done per frame and potentially not frame out.
And no LOROM and HIROM are the ROM layouts in the SNES Memory Map of which you have SLOW LOROM, FAST LOROM, SLOW HIROM and FAST HIROM layouts.
Yes, in fact all Lorom slowroms (default is 1MHz) can be converted to fast roms, since there is usually one byte always changing in the entire rom multiple times, so that the game can now run on 2MHz. Zelda A link to the past has been converted from slow to fast rom, but this also brought up various new bugs, which needed to be fixed (and they were).
Actually it does, the fast rom can simply handle more sprites on screen than the slow rom. Example: original Alttp starts "lagging" when there are 3 knights throwing 2 bombs each, fast rom version has no lag in this case. But all version will always lag with 4 knights throwing bombs.
Fast rom is however not the best solution, there is too much work for very little effect, since the game can only handle slightly more activity, and will be affected with new bugs for sure.
The "next-gen" of getting rid of the slow downs when having multiple sprites on screen is actually not fast rom, but a new method of RAM remapping, so that the sprite engine is handled by the SA-1 chip (which apparently can handle incredible 10MHz), example for SMW:
Unfortunatelly we were not yet able to do the same for Alttp.
You don't need to do the whole ROM as fast, I was thinking you might just be able to get away with making the sprite updates and collisions code in Fast speed. I was also mainly thinking of the cheap Konami games that suffer from the odd slow down here and there, a small boost to fast ROM would probably smooth them out. It is a matter of finding all 24bit pointers used by said code and or-ing them with $800000. If title screens and game over screen etc run at 2.68 who cares. But converting all the decompression routines would make things "load" faster.
Yes for the ultimate smoothness SA-1 at 10.74Mhz is the king but that is a lot of work and needs lots of patching and conversion as the SA-1 can not directly see the VRAM so you have to instruct the 5A22 to pump data to VRAM for you, in a system not designed to do it that is not trivial, but also only really needed for the case of Mario world where people are doing crazy things with their hacks. And change the ROMs layout and the vector handlers and yeah make the game again from scratch for the most part