but Nishi didn't like MSX being seen as a videogame and even forbidden game related upgrades to the vdp (history is that multi color sprites were done by Yamaha engineers without being in the specs, and scroll was done only up/down to scroll Kanji text in graphic modes smoothly for ntt terminals using the same vdp).
If this was true, i think we need to congratulate with nishi for its BRILLIANT vision and to have contributed to the early debacle of this system. ;-)
I think it is common knowledge (and common sense) that the V9938 feature set was driven to a large degree by requirements for non-game software? I don’t know whether Yamaha engineers were “forbidden” things, that sounds like an urban legend, but I’m sure some things were rejected and others were requested. Surely high resolution modes with many colours to enable GUIs, Kanji display, video and photo digitisation and graphical software were high on the requirements list.
The MSX has a keyboard and peripherals, it could not possibly compete on the games console market which did not need to incur that cost. So I’m not sure how that would’ve given MSX higher odds of survival.
I think the magic Y-values is a pretty cool feature
On the TMS9918 Y=208 is not so much an issue although perhaps an unnecessary annoyance since you can’t just place off-screen sprites just anywhere in the border area (if may need a check). On the V9938 it is more problematic since the sprites scroll along with the display offset, so when the screen is scrolled halfway down sprites with Y=208 (or Y=216 in 212 line mode) are in the middle of the visible area, causing a “forbidden line” that needs to be checked and causes a small jump in the sprite position after correction.
One solution could’ve been to not scroll the sprites with the display offset, as is the case for horizontal scrolling on V9958. Another solution could’ve been to disable the mechanism entirely since it has little to no practical use, but there was backwards compatibility to consider (even if it were disabled in sprite mode 2, the issue would persist in sprite mode 1).
Anyway this conclusion we’ve had many times before, so I’m not so sure it is interesting to go over it again. It is the way it is, every system has their nuisances, as examplified by Pokun’s example of how the NES PPU deals with sprite positions above the top border, I’m sure some NES developers pull their hair out over that too.
Honestly I think on MSX the limitations have mostly to do with bandwidth. The new V9938 modes have a lot of resolution both in dimensions and colour, better than any other 8-bit system, but moving so much data around is quite taxing on the CPU and blitter. On the other hand, the TI-83 can easily do impressive full-screen effects because it only needs to deal with a 96×64 area with 1-bit colour. The Spectrum has a similar bandwidth advantage over the TMS9918 due to its small colour attribute table.
But honestly in many respects it is a self-imposed limitation by developers, since the MSX2 does have low-bandwidth screen modes like screen 4, with plenty of VRAM to back it too for buffering and caching. However when given the choice game designers often chose better graphics over smoother gameplay.
But going back to the topic of MSX3 (in the 90’s era), thanks to Moore’s law bandwidth is one of the easier problems to solve with new silicon, as demonstrated by the V9990’s ridiculous blitting speed. So maybe it was a very future-sighted approach 
.
AFAIK, the 6502 is typically considered to be about twice as fast as a Z80 at the same clock rate
You should not compare them at the same clock rate, the max rated frequency of the 6502 is 1 MHz, and the max rated frequency of the Z80A is 4 MHz. The processors demand different clocks because their internal pipeline is structured differently, but the end result is similar levels of processing power at each their rated frequency. I’ll leave claims on who has the edge to others, as long as the basis for comparison is correct .
