Well, IF I ever finish a Prince of Persia for MSX -- note that it should have all levels, including the last ones where the player faces himself (besides enemies, traps, and so on) -- you will hear about it.
The most problematic aspect is for sure the VDP. Not enough VRAM to hold all frames, not enough speed. You can do it on MSX1, but wouldnt look much better than the spectrum one. I want to make it for MSX2 or higher - but it is A LOT OF WORK, and even if I had all the things sorted out, my spare time isnt what it was like some years ago.
Also (reading some posts I didnt see before) - you cant just say "msx can run Space Manbow", and expect an amateur project, developed in spare time to have the same quality as the *BEST MSX GAME* (feature wise, of course) developed by a payed professional team of developers.
And about the topic: bumping this old topic will do no good... but if anyone feels like coding PoP, please, be my guest 
I think fudeba see only the msx1/2 limits without correctly weigthing the SAM ones.
As said before by others people, i do not think a screen5-like management on sam coupe' could be faster than a good use of vdp processing capabilities.
Try to emulate in SW a LMMM copy operation on SAM coupe'. I think will be no surprise if results are inferior to the msx2 vdp. In games like screen 5 there is a lot to calculate to smootly blit a sw sprite. You also need to implement the transparency.
Plus consider that were the msx video ram access will suffer heavily respect to mapped-contended ram architecures is only one scenario:
Access to a lot of non-contiguos vram address. this is because of the need to set the vram address ptr. In this scenario there is a very big performance loss... In others (fortunately more common) scenarios, where you set rarely the address ptr and then you move 30-40 bytes the speed loss is not so heavy....
What instead is more important is the M1 wait: this makes a 10-20% of delay and affect all z80 operations.....
However the situation IMHO is not soooo bad as fudeba say.
Only to take an example:
If i remember well, Ball Quest is a SAM coupe' game ported to msx2. the author sayd that fps is increased because of use of VDP cmds instead of the use of cpu.
First of all, I respect everyone's opinion, but I would like to mention some facts.
The MSX VDP has reasonable good features, even if they are far from what a programmer would like.
But it is slow and the VRAM access is even slower. And the fact it has no interrupt on command finish
is the final blow, because this creates the need of clever tricks to do something that should be usual:
let VDP work in parallel with Z80.
Because of this (but not only), all the complex games made on MSX are done with extreme hardcore
tricks. Calling games like Akin / CoreDump and Space Manbow as "trivial", simply because they use VDP
commands is just absurd (IMHO). Those games are very optimized and use complex tricks to achieve the
result seen on the screen. But its creation was not easy at all - and, remember, they do not reproduce
nothing, they are genuine creations, there is nothing to compare them with.
I would like to point (again) to the fact that something *is possible* doesn't mean it is easily done. And
sometimes it requires a lot of re-programming until the correct/better "algorithm" is found.
About Sam Coupé limitations, of course emulating VDP commands *can be* slower, but I believe that's not the case in question. No one will program Sam Coupé to "emulate" nothing (the same way Space Manbow do not emulate resources available at arcade games). Anyway, when you have access to VRAM directly, it's not "a lot of calculations" to make transparency, it's done the same way as it is in spectrum: a bunch of ANDs and ORs. The only difference is the amount of data. Anyway, I do not think the need to change addresses is a real problem anymore. Change VRAM address is only two OUTs, and usually it allows an economy of hundreds of OUTs. I tested this on GnG, where the performance increase was great using "address jump" instead of re-printing never-changing patterns.
But I agree with you in one thing, PingPong: if (and only if) the game can be done fully using VDP command engine and the game is clever enough to do some work while the copies are done, *then* the game speed will probably increase because:
1) Z80 will not loose time printing the screen.
2) Z80 will work in parallel with VDP.
3) Printing the screen is the most time consuming activity in a game.
If (1) or (2) are not correctly satisfied, the game will be slower almost always.
BTW: if you do not took my calculations into consideration, I was trying to say that the waiting time for Sam Coupé with its "contended access" is something very similar to the extra M1 cycles on MSX (on MSX, every memory access is contended by one cycle). The difference is contended access can be up to 3 waits (But it usually is 1 or 2) per instructions, and M1 cycles contentions are never more than two per instruction (usually 1 or 2). On the other hand, there is a good ammount of time where there is no contention at all (VBLANK, HBLANK) on SamCoupé, but extra wait on M1 will always, ever, bug each Z80 instruction processed on MSX. NOTE that this is a problem *on 3.57MHz*. Most 7MHz computers have no wait on Z80 instructions enabled (what makes 7MHz computers work more than twice as faster as 3.57MHz machines). Anyway, even then there is a "contention" on VRAM access, which must be controlled by software (NOPs between OUTs) or hardware (waits generated by V9958). So, MSX is also "bugged" by some kind of memory access contention.
Or am I dreaming and we can access every piece of hardware as fast as we can?
The main difference is the fact on MSX I have to create three or four routines and detect speed of every piece of hardware connected so I can use them to the last drop of power without making the computer hang and allowing the program to work on every computer, from MSX1 to OCM. And this is needed just because the "contention" is not correctly controled on MSX hardware. On some machines waits are generated in excess (turboR) and in others they are not sufficient to prevent ill-effects (MSX1, MSX2... FM on every MSX computer and so on).
About remakes that became better than the original, the example you mentioned is not the only one. There is the Goody example or the Last Mission example. And I have been working for years in such a project (reprogramming a speccy game to work on MSX2 or better, using higher screens and VDP commands). And, believe me, this has not been an easy process. I really must express profound respect to Manuel Pazos who did Abadia del Crimen MSX2 conversion and also to Prodatron, who gave birth to something I thought was not possible: SymbOS.
But no way I will ever say to someone: "Hey, look, it's simple! Get that CPC game and do it better on MSX! How is it not easy? They guy had not ported SymbOS for MSX and it became even faster?" Nor do I say: "Hey, port that Prince of Persia from ZX to MSX in Screen 5! There are many ports from ZX games and there is even that versions for MSX2 which are sooooooo neat and soooooooo fast!".
Personaly, hear those assertions only make my interest (in porting/creating a game) to fade.
Besides that, just bug off.
Very interesting debate indeed. Thank you for sharing your programmer's experiences! It's good to have a glance at considerations behind your productions.
First of all, I respect everyone's opinion, but I would like to mention some facts.
Obviuously, and i think NO ONE had said 'Fudeba is a stupid people because he said is not possible to do PoP'. Or i'm wrong? People are only posting their opinions. Does this irritate you so much?
The MSX VDP has reasonable good features, even if they are far from what a programmer would like.
If you need a ATI RADEON video card to make your life easy i agree with you. But the last sentence could is also true for C64, Speccy, Amiga. Depends on what you want to do. Surely the good amiga is FAR from what a programmer want if he want to code a today 3d game....
And the fact it has no interrupt on command finish
is the final blow, because this creates the need of clever tricks to do something that should be usual:
let VDP work in parallel with Z80.
Yes. this is effectively the most annoying problem. Even considering that having it implemented was very easy...
.... Those games are very optimized and use complex tricks to achieve the
result seen on the screen. But its creation was not easy at all ....
Most games are optimized some on AI, some on graphics, some on several aspect... Again, if you want to do unoptimized code i think MSX is not for you (but also every 8 bit machine)
I would like to point (again) to the fact that something *is possible* doesn't mean it is easily done. And
sometimes it requires a lot of re-programming until the correct/better "algorithm" is found.
for sure, but there is a lot of difference between 'IMPOSSIBLE' and 'DIFFICULT'.
About Sam Coupé limitations, of course emulating VDP commands *can be* slower, but I believe that's not the case in question. No one will program Sam Coupé to "emulate" nothing (the same way Space Manbow do not emulate resources available at arcade games).
I agree, emulating require much more power to balance differences. (A modern pc can emulate a relatively slow msx, but take a look at CPU time and consider the waste of power)
However, simply porting zx->msx is a kind of emulation.... (almost on gfx side)
When i'm talking about doing a simple sw sprite print with transparency support , i'm not emulating nothing. It's a common task on those machines. And doing this via SW on a 6mhz z80 is SLOWER than the vdp speed. Look at BQ- The programmer had a good knowledge of ZX like machine and a poor of the MSX2 VDP.
Even the final result is better.
(Not soooooo much better but even better)
Plus consider that doing in SW SPRITES can allow access to some tricks like Dungeon'Dragon do for trasparency such considering a byte = 0 as the trasparency for two pixels. I've seen how this game works and profiled times
This game do SW sprites with z80. even with this trick the speed erase copy required for a sw sprite is slower than what the vdp can do. AND FOR SURE YOU LOOSE ANY CHANCES OF PARALLELISM
Anyway, when you have access to VRAM directly, it's not "a lot of calculations" to make transparency, it's done the same way as it is in spectrum: a bunch of ANDs and ORs. The only difference is the amount of data.
see above, try to do in SW and consider that to support trasparency you need to read /mask/ write, and this is constly on a z80
Anyway, I do not think the need to change addresses is a real problem anymore. Change VRAM address is only two OUTs, and usually it allows an economy of hundreds of OUTs. I tested this on GnG, where the performance increase was great using "address jump" instead of re-printing never-changing patterns.
For GNG it's probably true. But if you think for example to a PSET routine with random x,y. compare the zx one with the msx one. The ZX version literally FLY the MSX version surely NO! (I think there is a 1 order of magnitude in PSET speed)
.... So, MSX is also "bugged" by some kind of memory access contention....
I call this speed penalty, not memory contention. MSX VDP memory is electrycally disconnected from cpu bus. the final effect is however the same....
Or am I dreaming and we can access every piece of hardware as fast as we can?
Even if true, the main bottleneck will be the z80.....
The main difference is the fact on MSX I have to create three or four routines and detect speed of every piece of hardware connected so I can use them to the last drop of power without making the computer hang and allowing the program to work on every computer, from MSX1 to OCM. And this is needed just because the "contention" is not correctly controled on MSX hardware. On some machines waits are generated in excess (turboR) and in others they are not sufficient to prevent ill-effects (MSX1, MSX2... FM on every MSX computer and so on).
this is in effect a bad design. but MSX VDP it's full of bad things that with a little effort could revert some big limits (for example a scanline int? or a simple hw scroll register? )
... And, believe me, this has not been an easy process. I really must express profound respect to Manuel Pazos who did Abadia del Crimen MSX2 conversion and also to Prodatron, who gave birth to something I thought was not possible: SymbOS.
I do not think it's easy. But simply saying it's difficult does not help at all. That's the point. About prodatron when he make SymbOs on msx MOST people said 'not possible, the main problem: THE VDP'. Prodatron made it and it's good. Again another point: the char printing routine is 1.7 faster using vdp that the one on CPC (as prodatron said). And consider that the CPC has little amounth of data to move + the fact that prodatron is a master in z80 programming. I think The CPC gfx routines are far from worse....