I was meaning that inside the mul/div, it would check the cycle counter value (starting from N and going downward) and calculate the results there, on the actual read.What I did last time was store the H/V counters when the mul / div began, and each time either the result regs were read, or a full scanline had been emulated, I'd adjust the counters there.
The above was the "trick" to avoid having to update the counters every clock tick.
But then below,
Joypad polling isn't the same as mul / div, it has visible effects on the system as it increments the joypad read indices each time it fetches a bit. Though I'm certain you have some neat tricks for that, too ;)The joypad polling I cannot do the same. If it polls every 8 clocks and is done automatically, I will need something like if(auto_joypad_poll_active == true) inside the main add_clocks() loop.
If the overhead is already taken by the joypad polling, it won't add any more to add mul/div counter adjusts right next to it. And if there is more overhead, I'll use the method above for that, and this method for joypad polling only.
The raw multiplication would obviously be computed all at once, and only on read, either way. I'll even make sure it caches the end result so that it doesn't have to compute finished values twice if read twice.
So no worries, not going to make it slow just because I can here ;)