Lookup tables can be both magic and fast, but they're being overestimated here. A lookup table bigger than 256 bytes takes longer to use and one that requires bank switching is even worse. That's not the worst issue, though. Let's assume that by slight of hand, the time for the perspective projection routine could be reduced to zero -- no time at all. Guess how much of a difference it would make? 15%. That's the total amount of time that the divisions take in the version that I posted, if you look at the profile (CPU clocks ILOG + IDIV1 + IDIV2). The maximum theoretical possible speedup, which is not actually attainable, is therefore 1.17x. Other routines like the rotation routines need attention and aren't necessarily as easy to optimize with lookup tables as the divide.

That having been said, it's not like there's an epidemic of people actually working on Star Raiders, so if someone can make the game awesome with 1MB strapped to an Atari, who are we to argue....

As for precision, the vast majority of the stars are within 12 bits for all coordinates (|XYZ| < $1000). Reducing precision down to 8 bits ($FFF0 mask) is about as far as can be tolerated; below that the motion fluidity starts being affected such that the game might as well be running at 30 fps, which kind of ruins some of the magic. You can test this in the version I posted by masking off low bits from A on input to the ILOG function. Therefore, when it comes to a direct division table, the minimum needed is 64K, and it would be better to go to 256K to fold in the sign bits as the abs calculations in CALCVH and DIVIDE/IDIV1 are fairly expensive.

Using Veronica for math acceleration would be silly. It has a 65C816 accelerator running at eight times the 6502's speed with no DMA overhead and a full 128K of local memory. You'd run the *whole* game on the 65C816, including framebuffer rendering, and use the 6502 for I/O and sound.