nesdev.org

I don't see the problem if you only get 8x8 -> 16 bit multiplication. If you want to do, say, 16x16 -> 32 bit, all it takes it to compute LOW*LOW, LOW*HIGH, HIGH*LOW and HIGH*HIGH, and add/shift them together.
I guess the multiplication unit is the same used for more 7, and that it only works when mode 7 is not used (is this right or am I just making this one up ?). If this is the case you'd want to only use this if you're absolutely sure you don't need mode 7 in your game.

You'd want to look the NESdevwiki article about multiplication - of course it's different on the SNES because of 16-bit mode but you get the idea on doing a multiplication without using an hardware unit.
And for a level which has to do frequent multiplications variable * variable, but where one of the variables is only modified rarely, it's a good option to reserve some RAM to have self-modifying code doing the multiplication by this value (that is generated by software).

I'm using logarithmic shifts.
EDIT: I just thought of a faster code It stops shifting when it detects the indication bit.

Or to reduce the loop overhead even further, you can build an unrolled ASL-slide in RAM and call that.

I just thought of something. For calculating the x tile, your required to shift right 4 bits, but for y tile, you can just AND it with #$fff0.