I can't understand why MSX family didn't jump to processors like Z180, fully compatible and far superior to Z80.
I think they have not managed to find a simple, compatible and cheap way to separate the frequency of the BUS and the CPU. They did that with the R800 without it being the ideal.
But even solutions like Z80 with higher clock frequency should be fine. Zemmix Neo supports Z80@8,06Mhz and the difference is outstanding. For sure it's not as powerful as M68000 but it's clearly better option than old and totally deprecated Z80@3,58Mhz.
MSX dug its own grave, PC was not responsible of anything.
When the frequency of the Z80 increases, so does the BUS, and many extensions no longer work (RAM expansions, FM sound, etc). I think that is reason that it's not been used much. Panasonic MSX2+ do not increase the frequency much, and Victor HC-90/95 was using two BIOSes with a functional switch only before turning on the machine.
Zemmix Neo has a lot of RAM and most of the music extensions are emulated internally. So the problem is less visible.
When the frequency of the Z80 increases, so does the BUS, and many extensions no longer work (RAM expansions, FM sound, etc).
That’s not correct. The frequency of the CPU is independent of the bus, and you can increase it as long as you ensure the timing of the signals on the bus stay the same, at least on the external cartridge slot. For example an I/O read cycle must last about 0.8 µs (3 cycles on a 3.58 MHz Z80), so with a 7.16 MHz Z80 a bus controller must make sure to insert 3 additional waits in order to make it last 6 cycles. The Z280 even has built-in functions for this.
And of course the external clock output on the cartridge slot needs to remain 3.58 MHz, it is merely a clock source that can be freely used by cartridges for convenience (many do) and is not tied to the I/O signals, they are not clocked by it.
This is exactly what the turboR does (specifically, the S1990 controller). The OCM and all 7 MHz upgrades that I know of do this incorrectly, resulting in bad cartridge compatibility in turbo modes. The Panasonic MSX2+ correctly provides the 3.58 MHz clock on the bus, and I suppose due to the modest increase in CPU speed the bus timings stay within tolerances (I don’t think it has a bus controller).
It's not correct. The frequency of the CPU is independent of the bus, and you can increase it as long as you make sure that the signal synchronization on the bus remains the same (at least on the outer cartridge slot).
The BUS is connected directly to the Z80 on MSX but yes, by adding an external system we can do everything. After that it's just a cost problem.
The Panasonic MSX2+ correctly provides the 3.58 MHz clock on the bus
No, some cartridges do not work in turbo mode. This means that the bus frequency changes at the same time.
The BUS is connected directly to the Z80 on MSX but yes, by adding an external system we can do everything. After that it's just a cost problem.
Note it can still be connected directly and in fact on the turboR it is (iirc), just the clock for the CPU must not be connected to the cartridge slot clock and the bus controller must observe the I/O read/write requests to determine if it should insert waits depending on the target. At least the internal memory should run at full speed, otherwise the higher CPU clock won’t give a large benefit.
It doesn’t need very complex circuitry. Decoding the address of the internal hardware is already done by the MSX-Engine, so all it needs to do is combine the chip selects with the read/write signals, and if there is an I/O but no chip select, trigger a clocked counter which signals /wait until it reaches zero.
The Panasonic MSX2+ correctly provides the 3.58 MHz clock on the bus
No, some cartridges do not work in turbo mode. This means that the bus frequency changes at the same time.
Do audio cartridges pitch up? If not the clock stays the same, meaning it must be due to the tighter off-spec timings, as I described in the sentence after the one you quoted (guess it’s not within tolerances, so they got it only half-right).
Anyway, it seems that at the time the manufacturers had difficulties to manage hardware timings.
I was disappointed when the MSX2 released because of the CPU that had not evolved but I liked this machine anyway.
I think it was more a software compatibility problem, the hardware compatibility problem is solvable. You can’t just put a Z180 inside because it has different instruction timings, that would require a dual-CPU setup which is a lot more complex. A faster Z80 like the Z80H seems like it would’ve been feasible though without too much extra complexity, of course it would need BIOS support and the MSX-Engine would need to control the clock and dispatch waits in turbo mode.
I think they anticipated 5.37 MHz CPUs at least as MSX2+ came around because the T9769 MSX-Engines introduced 1-2 extra VDP wait cycles that seem entirely unnecessary otherwise, and a clock select register and pin (CLKX). Which isn’t wired up in the Sanyos because they lack a Z80B.
I think it was more a software compatibility problem
Software compatibility was easily resolvable by making the CPU frequency increase only in MSX2 modes for example.
IMO for MSX2 the CPU upgrade was not needed yet, the VDP upgrade alone was major and justified the release. Only two years after MSX1 the CPU was still good enough. But for MSX2+ it was definitely due, especially since it was otherwise a lackluster upgrade that got poor reviews and didn’t offer much incentive for both users and manufacturers to invest in a new computer.
Panasonic made a half-assed attempt at it, but the BIOS didn’t support it and they didn’t fix the PSG clock either.
IMO for MSX2 the CPU upgrade was not needed yet, the VDP upgrade alone was major and justified the release.
When the Amiga and Atari 520ST were available, it was before the MSX2+ and everyone compared their CPU with the poor Z80 at 3.14Mhz. So CPU upgrade was not only needed but rather indispensable. In addition, only the V9938 would have been able to send a signal to activate the CPU turbo mode in MSX2 modes. (assuming there was no hardware timing issue as you say)