Quote:

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

Karateka is, by far, the worst of them.
But if you have a turbo computer, maybe you enjoy it a little.
At 7MHz the game is playable (better than on Spectrum, faster
and with less bugs), but the game is far from a good gaming choice.
In the bad side.

I will try it at... 10 mhz in the 1chipMSX

Have you guys ever considered about porting good speccy games that never were converted to the MSX?

Quote:

Have you guys ever considered about porting good speccy games that never were converted to the MSX?

Porting a Spectrum game is a HUGE ammount of work. You have to completly disassemble the game, find where graphics and musics are, CONVERT the graphics to MSX color format (at least), reprogram everything (after understanding what the original code does), converting the spectrum memory layout to MSX one.

Considered? Yes.
Want to? Yes.
Do I have the time/experience? No.

I think it's better to code something from scratch, than to waste time converting games from Spectrum. That could be a good option in the 80's, where companies probably had some source available - so it could be done quickly by people who understood both platforms.

Remember: converting things from Spectrum ends up with color clash (if the original game also has it, of course), slower and often limited game (just play MSX's Robocop and Spectrum's and you'll see what I mean)

So I don't think anyone will port games from Spectrum - as it needs not only a lot of skills (on both plataforms), but also a lot more time than a simple "cas to dsk" conversion, or a "similar layout" (read: sg-1000/colecovision) one - and the results are just not that good to justify it... of course there are *some* exceptions to this rule, but for most Spectrum games - we would be better off porting them

Quote:

I think it's better to code something from scratch, than to waste time converting games from Spectrum. That could be a good option in the 80's, where companies probably had some source available - so it could be done quickly by people who understood both platforms.

By people who understood both platforms and had programmed the original spectrum game.

Quote:

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.

lookat this: http://fms.komkon.org/stuff/spectrum.faq
It's possible to write to vram everywhere but at the cost of some slowness.

However, if
the Z80 wants to read of write the lower 16K, the ULA halts the processor if it
is busy reading, and after it's finished lets the processor access lower memory


and

If you run a program in the lower 16K of RAM, or read or write in that memory,
the processor is halted sometimes. This part of memory is therefore somewhat
slower than the upper 32K block. This is also the reason that you cannot write
a sound- or save-routine in lower memory; the timing won't be exact, and the
music will sound harsh.



about snow effect the cause is not by pure reading or writing to vram. On the same link you find a tech explanation of the snow effect.

Another conversion: the strange and little known Spanish game Knight Ghost

http://www.generation-msx.nl/msxdb/softwareinfo/2213

Download the conversion from here:

http://www.caetano.eng.br/main/index.php?l=br&menu=software&page=msx

Quote:

lookat this: http://fms.komkon.org/stuff/spectrum.faq It's possible to write to vram everywhere but at the cost of some slowness. However, if the Z80 wants to read of write the lower 16K, the ULA halts the processor if it is busy reading, and after it's finished lets the processor access lower memory

So, I was right at this point.
And I had been analyzing Spectrum hardware for some days now (writing
a MSX programmer's tech-doc about ZX Spectrum) and found out that many
game programmers count CPU cycles to avoid writing on VRAM (4000h~7FFFh)
while ULA is writing the screen.

Quote:

If you run a program in the lower 16K of RAM, or read or write in that memory, the processor is halted sometimes. This part of memory is therefore somewhat slower than the upper 32K block. This is also the reason that you cannot write a sound- or save-routine in lower memory; the timing won't be exact, and the music will sound harsh.

Yup. This is good information (but I had found several inaccurate Spectrum
tech-docs on the net).

Quote:

about snow effect the cause is not by pure reading or writing to vram. On the same link you find a tech explanation of the snow effect.

I was really wrong about this. Simply reading/writing VRAM is not fast enough. The trick is a little more
obscure: loading the I register with a value from range 40h to 7Fh, which confuses ULA during the
Z80 refresh cycles.

Fudeba: thanks for your last conversion. Even being a Spanish game, I didn't knew it

PS: I think you must do a unified - tape-disk conversions website

Quote:

Fudeba: thanks for your last conversion. Even being a Spanish game, I didn't knew it

I had a version already converted, but it was bugged (didn't work on MSX2 or better). I found
it easier to re-convert from tape to file and correct it than convert the BASIC Loader version
and then correct the bug. (I do not like BASIC loaders when running things from harddisk).

There will be a pause in the conversions this year. I will resume them next year.

Quote:

PS: I think you must do a unified - tape-disk conversions website

It is online already, but at this time SLotman and me are using it only as a reference.
I am sure as soon as there are enough games, SLotman (the author of the page) will
release the link.

@Fudeba:
Well, hoping that these tech info could help in done better convertions, but now i've a question for you:
zx does not have hw sprites, so sprites are managed in sw (the cpu does). In this way there is the problem of flickering: to avoid this YOU MUST MAKE SURE that the cycle used (restore background-save background-plot sprite) is performed while the raster beam is off the region you are working. In speccy i assume that (like on msx) this is pratically done in vblank. HOWEVER THERE IS an alternative. the usual backbuffer.

Do you know if speccy games make use of backbuffers almost always?
thx

Quote:

There will be a pause in the conversions this year. I will resume them next year.

Ok, take your time . And I must enjoy the 5 releases and try to finish them

Quote:

@Fudeba: Well, hoping that these tech info could help in done better convertions, but now i've a question for you: zx does not have hw sprites, so sprites are managed in sw (the cpu does). In this way there is the problem of flickering: to avoid this YOU MUST MAKE SURE that the cycle used (restore background-save background-plot sprite) is performed while the raster beam is off the region you are working. In speccy i assume that (like on msx) this is pratically done in vblank. HOWEVER THERE IS an alternative. the usual backbuffer. Do you know if speccy games make use of backbuffers almost always? thx

Well, AFAIK, some yes, some no. As an example, AFAIR, Shinobi indeed does use a framebuffer... but not all games do it. in fact, I believe that no 48K spectrum game use a framebuffer, but many 128 spectrum games does use them. Besides, 128 spectrum games can even use the page 7 as page-shift framebuffer (you can select what page is displayed by ULA: page 5 or 7).
A good reason for Spectrum games using framebuffer (when there is RAM available) is the fact that Spectrum "VRAM" is not really "linear" in the sense it would be nice to work with; in fact, working directly on VRAM area is even worse than it is on MSX. Video memory in Spectrum follow this distribution:

4000h - 32 bytes that forms the line 0
4020h - 32 bytes that forms the line 8
4040h - 32 bytes that forms the line 16
4060h - 32 bytes that forms the line 24
4080h - 32 bytes that forms the line 32
40A0h - 32 bytes that forms the line 40
40C0h - 32 bytes that forms the line 48
40E0h - 32 bytes that forms the line 56
4100h - 32 bytes that forms the line 1
4120h - 32 bytes that forms the line 9
...
and so on. And the screen is divided in 3 thirds also, meaning that 4800h is the start of the
sequence 4800h - 32 bytes that forms the 64 line...

As you can see, data is arranged in a very complex way, and there is a calculation to be done every
line to be changed. When using a framebuffer, usually the framebuffer is built in a straight linear fashion
(32 bytes for the first line, 32 bytes for the second line, 32 bytes for the third line...) and the computation
is needed only once per line, and the transfer is done with a sequence of 32 LDIs and a INC H and a
LD L,0 (this is done 8 times and then the original address usually in HL) is popped and incremented in
one... and the whole process is repeated 8 times.
This is a lot faster than plotting shapes directly on the VRAM (specially if one piece of the shape is
placed in one third of the screen and other piece of the shape is placed in other third of the screen).

Some 128 games adapted for MSX where changed to write its (linear) framebuffer on the
4000h~5B00h area ... and then this data is converted "on-the-fly" while is OUT to the VDP. Games
that do OUT directly (without framebuffer) usually has a conversion function that gets the "virtual
line" and convert to the correct address to plot on Spectrum VRAM. When those games are
converted to MSX, this function is rewritten to reflect the correct address in MSX VRAM.

Of course there are much more ways of doing these things, but I believe these too are the
most common ones (considering what I had already seen when modifying converted spectrum
games).

About spectrum´s inner life, one can always ask from

http://www.worldofspectrum.org/forums/

I am pretty sure there are people who know the answers...

Quote:

Two games were recently converted from tape to disk: the first is Alteread Beast, convertion done by Amusement Factory - and the second (inspired by Alteread Beast's convertion) is Time Scanner by ICON Games. So, now those two games can be fully appreciated on any MSX (as long as you have at least 64k RAM) and specially on those with "turbo", so the games run full speed, like in the ZX Spectrum... and there's more to come

In Altered Beast the next stage will be loaded if you press at the same time the keys ZYDRO during the game. You can see the end of the game, too (identical to the arcade). This trick is for the original tape but it also works in Caetano's disk adaptation.