Quote:

@Fudeba: remember only on thing, the main bottleneck is the process of converting 'linear' display format to msx one. the vdp is not the *only* thing that slow down things.

MSX has many things that slow everything down. I had already explained several times that even without the need of sending data to VDP... MSX would be slower than Speccy. Speccy doesn't have an extra wait state on every M1 cycle as MSX does (from MSX1 to turboR in Z80 mode).
Of course that every data conversion "on the fly" will slow things down, but this is only one of the problems.

Quote:

Why we need the speccy format on a non-speccy machine? Because programmers are simply too lazy to implement a sw sprite routine that can work on the z80 ram in the SAME FORMAT as VRAM VDP. they work in the backbuffer in speccy-alike mode then they convert while blitting in vram to msx mode. THIS IS THE MAIN CAUSE OF SLOWNESS.

Of course it can (cause slowness); On MSX1, thought, the time Z80 is waiting for the VDP is being "wasted" in these conversions. If they weren't present, there would be the need of some NOPs between OUTs (as I had to add many times because TMS9128 fails to process the data fast enough).
Anyway, programmers are lazy by definition.

If you are not lazy, as I had already said before, feel free to adapt the game data. I am sure the game will be faster, even if not as fast as it is on Spectrum.
Just as an example, with a few optimizations in the output routine of Karateka (nothing huge like you are proposing) I was able to make the game run a little faster (just a little!... the game still crawls at 3.57MHz... but it crawls under Spectrum too, no big deal) and was able to re-enable some features that were previously disabled.

Quote:

For games that also manipulate colors there is also twice almost the amount of data to be processed. this explain why a z80 @ 7mhz is needed to get similar speccy performances.

Colors are less complicated than patterns. Usually the processing is conversion using a table and then outputing 8 times the same value... this way, the "overhead" is not that critical. I found it curious why the programmers had chosen to statically convert the colors and left the pattern conversion to be made on-the-fly. The only reason I could find is that it would be too complicated/complex and would require rewrite so many parts of the game that it couldn't be justified... on a conversion. Maybe it would be better to rewrite the entire game (and the programmers probably were not paid to rewrite the entire game).

Quote:

A thing that could be done will be to convert some sw sprites (where possible) into hw ones, thus minimizing the amount of work that the z80 must do

This is often discussed by me and SLotman; but I was never compelled to do it.
There are some good examples of conversions, though. Knight Tyme is one superb one. And it uses sprites for the main character.

My kindest regards,

Daniel Caetano

Quote:

Another release, this time from Amusement Factory... Karateka!

What marvellous piece of s .... t, congrats to the original game developer.

Another convertion!!! Great!!

PS: I played it a lot in a old XT PC when I was a child at a friends home

I do not know, you but I find it unplayable

Even the original version for PC was very difficult, but in 1984 was a real game hit. This game was made by Jordan Mechner, who created 5 years later of Prince of Persia.

http://en.wikipedia.org/wiki/Karateka_%28computer_game%29

@Fudeba:

Quote:

MSX has many things that slow everything down. I had already explained several times that even without the need of sending data to VDP... MSX would be slower than Speccy. Speccy doesn't have an extra wait state on every M1 cycle as MSX does (from MSX1 to turboR in Z80 mode).

But it has contended vram access, do not forget... speccy guru's know about of this.... so when the z80 writes to vram the ULA slow down the cpu...

Quote:

Colors are less complicated than patterns. Usually the processing is conversion using a table and then outputing 8 times the same value... this way, the "overhead" is not that critical. I found it curious why the programmers had chosen to statically convert the colors and left the pattern conversion to be made on-the-fly. The only reason I could find is that it would be too complicated/complex and would require rewrite so many parts of the game that it couldn't be justified... on a conversion. Maybe it would be better to rewrite the entire game (and the programmers probably were not paid to rewrite the entire game).

I agree. with color it's a most simple situation, however the having to output 6144 instead of 768 bytes (even if all equal) does impact severely on performances. Plus consider that we can not do things like this.

ld a, (HL) ' assuming HL pointing to zx attr table
out (0x98),a
out (0x98),a
out (0x98),a
out (0x98),a
out (0x98),a
out (0x98),a
out (0x98),a
out (0x98),a

because the vdp cannot cope with this. otherwise maybe we need something like this:
out (0x98),a
nop
nop

X 8 times

this slow down the performances at the same level of about pattern blitting....

Fudeba: Karateka's Curiosity page on your site is still in Portuguese only?

Quote:

I do not know, you but I find it unplayable

It's only really playable on turbo R or 7MHz mode. In fact, it was unplayable even on ZX Spectrum native version. It was a surprise it became playable on MSX @ 7MHz.

Quote:

But it has contended vram access, do not forget... speccy guru's know about of this.... so when the z80 writes to vram the ULA slow down the cpu...

I am not a Spectrum master, but I had always assumed the slow down on Z80 by ULA was only during the screen update by ULA ... and most games seem to avoid writing/reading VRAM on these moments (some games seems to write during screen update to create the 'snow effect', though).
Anyway, it's very hard to compare both hardwares. But I completly agree with you that is those games were re-written for MSX, using directly its resources, MSX @ 3.57MHz would be able to reproduce Spectrum speed.
Too bad this practice was the exception... not the rule.

Quote:

Plus consider that we can not do things like this. ld a, (HL) ' assuming HL pointing to zx attr table out (0x98),a (...) out (0x98),a because the vdp cannot cope with this. otherwise maybe we need something like this: out (0x98),a nop nop X 8 times this slow down the performances at the same level of about pattern blitting....

Well, I discovered in the 3 or 4 past years that, in fact, these nops are needed
only on computers using TMS9128 (or V9918, or V9928). When the computer uses
V9938 or better this is not required; Most games I adapt or improve has two VRAM
writing routines; one for MSX1 computers, with the NOP delays and another for
MSX2 or better, without the delays.
The speed improvement is not huge, but it is not small either.

Quote:

Fudeba: Karateka's Curiosity page on your site is still in Portuguese only?

Unfortunately, yes. It is a big page (usually the Curiosities page is the most text-massive one),
and I am without time to translate everything (with my poor-man`s english). The time I have
I am spending in converting new games.
Curiosities are Technical Curiosities about the "development", explaining the bugs, how the
game works, what was the worst part of the conversion...

Some time in the future I will take a time to translate them, too.

Please, guys, I do understand that the fun is in the technical challenge, but have you guys ever considered about converting good games?

Actually, I haven't still tried the MSX version of Karateka, but I am enjoying the other three games

Quote:

Please, guys, I do understand that the fun is in the technical challenge, but have you guys ever considered about converting good games?

Hehehe... The idea is convert the last remaining ones. There are only a few.
The selection criteria was: Altered Beast - I like the game; Karateka - some
guys are always complaining about not being able to play Karateka no MSX...
The third game I am converting (probably ready) was a little effort and is
in beta stage (soon will be released). This one is really a bad game; the
selection criteria in this case was random.
Future conversions will probably be random too.

And when every CAS game has been converted to file games (loadable
by disk) maybe I will start to convert some DSK games to file, correcting
FM output in Turbo computers (like Valis 2 and others). But this is just a
maybe. For now, the momentum is for bad cassete games that were never
converted to files.