Rewritting MSX games

There are two things that always annoyed me about the MSX. The 4 sprites/scanline limitation and the lack of hardware scrolling.

The sprite limitation can easily be fixed in emulators or, hopefully, in the 1-chip MSX.

However, fixing a 1 pixel scroll will require some reprogramming. I'm trying to figure out how much extra work it will be to "fix" games like Nemesis 2 and F-1 Spirit on, for example, MSX2+ hardware. I have no real machine code experience on the MSX, but I suspect that what needs to be done is to simply copy the upcoming characters in the scroll eight frames earlier and then tingle the scrollregisters for the next 8 frames.
This would also change the screen size and probably all the calculations on where to place objects in the screen.
Hopefully one can leave the game logic alone, e.g nothing happens with objects scrolling into the screen until they are one full character into the screen.

My question is, for any one with some experience of programmering the MSX, how much work would rewritting the scroll be? Just a rough estimation.

Of course depends of game, but if you need only i think a patch could be done in less than 1 week a game when you discovered the key points.

Basically those games scroll a 8x8 pixel block every specified n. of interrupt so somewhere there is a code like this.

c=c+1

if (c > 10)
{
BlockScroll();
}

should be changed in :

c++;

finescroll(c);
if (c>10)
{
finescroll(0);
blockscroll();
}

Removing the sprite flicker routine is also more easy. some game activate it by using a flag. Only a matter to cut the routine that check the flag...

Not a big WORK, instead would be interesting to rewrite msx1 games in msx2 fashion. this would be a challenge.!
Because some kind of jobs are done in very different way...

I'm trying to figure out how much extra work it will be to "fix" games like Nemesis 2 and F-1 Spirit on, for example, MSX2+ hardware.

It's impossible for Nemesis games because they use character enemies that move at a pace that is different from the scroll.

PingPong: thx for the example. What still worries me is that the screen area has to be one tile or one row larger (since the last and first row will be partially visible) and how this might affect the rest of the code.

Edwin:
Ah, right, I didn't think about that at all! Indeed it sound like a real pain to locate, rewrite and test for the Nemesis games.

I believe F-1 Spirit and Knightmare only uses sprites for moving objects, but the blocky scroll in Knightmare actually never bothered me that much, so that leaves only F-1 Spirit to be fixed.

Of course those elements cannot be converted unless at a big price... but JEZ talk about scroll. Pattern Based enemies are another thing

I think you missed the point. On games with pattern enemies that move relative to the scrolling background, you can't just change the scroll because it will interfere with the movement of the enemies. A game like Space Manbow was able to do it because it was designed to scroll so. If you check it, you'll see that all the big pattern based enemies only move in the direction that doesn't scroll. The other direction just moves with the scroll. Or, as is the case with bosses, they are the only pattern enemy on screen.