The OCM & Zemmix also have a turbo blitter option. It makes all the difference in the world for games that do intensive blitting. Many games will run faster than on Turbo-R because of that.
and in fact, the ocm / zemmix when doing the 5 / 8MHZ overclock distorts the performance, precisely because of the x5 blitter.
Not sure if is really up to x5 seems too much. Some benchs would be required.
The main problem of TurboR is an inefficient design. 2 CPUs + S1990 for controlling them, the cost of that controller must be insane, it has even more pins than the R800. Plus the cost of the duplicated components (no need to put a full MSX2 inside).
We have a fatal roadmap from MSX2+. Not sure if because the manufacturers, which wanted to recycle their unsold MSX2, or who knows, should have been a much better computer, with a faster Z80 (8Mhz or more), faster bus (with a classic one for one slot for old devices), and more RAM, ready to receive the new MSX-DOS2.
Even the V9958 could have had a faster blitter, but probably the final design was paired with the V9938 to execute the old software in the exact same way. For software (summarizing, games) that relies on a fixed operation time of an unique VDP, a bad software design for a computer indeed.
This could have given time to refine the next gen architecture, MSX3 with R800 implementing the most used undocumented Z80 instructions (that software should not use in any case) and featuring slowing its clock for old software, putting aside finally the Z80, with only one CPU and no need for that (looks) expensive S1990. The VDP could have been the V9978 (not ready for the current Turbo-R release date). Finally with a 16-bit OS.
Looking at the speed of MSX2+, the V9958 blitter, and dual CPU on Turbo-R preserving the Z80 at high cost, it seems they were more worried about executing the old software 100% like a MSX2 instead evolving the architecture.
Meanwhile we have incompatibilites on Mac, or even on PC when upgrading the OS in example.
in case of wanting to improve the standard and maintain compatibility backwards they had 2 paths
an accelerated Z80, what would be a patch because the performance of the z80 is known
a system with dual processor as was done
the R800 is a z280 / z800 with improvements, so that part of the work was already done (binary compatibility), however, the immense failure was made not to enable the enormous improvements included, namely:
24-bit MMU
DMA, s
an exclusive RAM loop to get the performance.
As far as the MSX2 + is concerned, as panasonic has conceived it with its engine, it does not seem like a very good solution, nor is it a disastrous architecture.
the problem is of sony, the XDJ and XV, are the same plate of the msx2 XD and XDmkII, with the necessary adjustments for the fm and the vdp, incorporating a s1985 as engine, with this solution you can not scale a system correctly, that of course discounting a v9958 that is nothing but a 1.3 version of v9938 (horizontal scroll and YJK / YUV modes, ah and wait signal that is of ornament).
a more or less logical evolution of the msx2 + would have been to start from the base of the panasonic WX, with several modifications:
Z80 @ 10mhz, switchable by soft (a little more than it has now)
256KB of RAM with access to / from the VDP (the ADVRAM of Brazil)
improvements in v9958, with any of these 3 I would be worth:
1.- duplicate the sprites (without modifying the operating mode)
2.- VRAM of 256KB (there is no need to comment, no)
3.- Improved Blitter (I do not know to what extent the speed of the blitter could not have doubled, when the 9990 multiplied it by 9)
other improvements apart, although I do not have insurance to what extent it would be reasonable for the price:
an exclusive DOS slot (not to use the MSX slot), so we would not have the problem of the turbo R with DOS2, that the OS consumes a SLOT.
in fact, a lot of the work is in the engine that the sanyo and panasonic incorporate, the toshiba Toshiba T9769