Just the opposite! First the player moves very quickly (take a look when you run and jump), also in the later levels there are a lot of stuff going on at the same time...
And you cant use sprites for player and enemies.... would require too much sprites per line - just the player has a frame with width more then 40 pixels, which would use at least 3 sprites, from 8 per line on MSX2!
Then, if you want to get a really colorfull char, you will use 2 sprites on the player, which will take 6 sprites, leaving only 2 for the sword and the enemy!!!!
It's a tricky thing to be done... but I think there's a way - using sprites for the player and shapes for the enemies; but then I have to create a small test-demo to see how it will perform speed-wise...
I think using vdp commands+hw sprite for the main charater and where possible for other things could give a good results.
When comparing zx games with msx2 ones consider please this:
- Most zx games manage sprites on a back buffer to avoid flickering, then LDIR to vram. On an entire screen this means moving 6144 bytes each time.
On a msx2 back buffering could be achieved swapping vram pages, avoiding such LDIR, so we can use the extra time to manage sw sprites.
- Consider that even with a so reduced vram (in ZX) performing HMMC or LMMC equivalent using CPU is slower than what it's capable of doing the VDP. Of course this is balanced by the 4x amount of vram needed on msx2.
I think that pratically every game that does not have scrolling could be made with page swapping and SW sprites on a msx2 at a decent framerate, unless you do not want 100 SW sprites on screen each of 100x100 pixels @60hz of fps--
Plus there is a prince of persia prj for spectrum clones that have 320x200@16 colors, with the same 'huge' amount of vram of msx2.
I would like to add that msx does not have the color clash problems of spectrum,and nowdays that most msx users have at least 256 kbyte of ram,sunrise cf adapters,and hd storage mediums,i do not think there is any problem.If it is possible on a zx spectrum it is for msx and it can be done much better.So is anyone interested?I could try to convert the sprites to msx format by some tools if anyone wants me to do so.
UPDATE:There seems to be so much dataframes in the game.I am looking at the amiga version.what would the best option be?
It is possible on Spectrum because there, the player is monochrome, so it only uses 1 byte for every 8 pixels. The same could be achieved on MSX, but would have color clash as well.
On MSX, Screen 5 will use 1 byte for 2 pixels if you're using shapes. There's not enough VRAM to store all the player shapes - and you would need also the background graphics, plus the enemies, swords, bottles, etc.
If you're using sprites, to save memory you will need to have one-colored sprites, this way you'll use the same ammount of memory as the spectrum - but still, you'll have to change the player sprites pattern on the fly, so it can walk behind columns and some other stuff.
And if you're using sprites for the player, even altering their pattern on the fly - dont forget that on the later levels you fight yourself. So you would need another sprite of you running aroung.
Prince is not an easy game to accomplish - If you want to do it the no-monochrome-color clashing way; and yes, I dont like enemies moving in 8x8 patterns either 
I think the game could be done, even in MSX1 mode (maybe some colour loss and some flickering). Try not to do a "verbatim" copy, but a conversion.
For the "dissapear" trick , put some sprites over the collumns and so the character sprite will seem to hide behind...
bump!
Any news?any progress?
bump!
Found this Youtube video that has Sam Coupe version of prince of persia
Sam Coupe Version
Any news?any progress?
bump!
Found this Youtube video that has Sam Coupe version of prince of persia
Sam Coupe Version
Any news?any progress?
Hey, this is an unfair comparison, even more if someone wants to compare
Sam Coupé with MSX1. Sam Coupé is a very good machine and it is (in my
opinion) way better than a MSX1 in some points. In fact, it is even better and
MSX2 in several aspects (its "Screen 5" is a lot "faster" than MSX one, for instance).
Someone had ever bothered to look at Sam's techdocs? Well, I'll help you:
ftp://ftp.nvg.ntnu.no/pub/sam-coupe/docs/manuals/software/SAM%20Coup%E9%20Technical%20Manual.zip
In short:
- Its Z80 runs @ 6MHz (without any extra delays on M1 cycles)
- It has a video co-processor (MC1377P) plus extra ASIC to handle graphics, which is
capable of generating line IRQs and allows the use of a 128 color palette. It has
video-modes like Speccy (its text mode), like Screen 2 and like Screen 5, all of them
with 16 colors, plus a mode similar to Screen 6 (its 80 colunums text-mode), with
512x192 pixels, 4 colors.
- It has a FM sound generator similar with 6 channels (Philips SAA1099), plus
some AM functions, like noise generators and envelope generators, 15KHz 8
bit DAC and MIDI.
- It comes with built in 256 or 512KB of RAM (expansible up to 4MB)
- Its VRAM is mapped directly on RAM, but not in a fixed position like Speccy.
"Contended Memory" delays do not apply (AFAIK, and I don't know how it
works).
- It has NMI implemented.
The fact this computer has:
A) Z80 @ 6MHz (and every piece of hardware works at this speed, without
delays) and
B) It has a kind of "ADVRAM", which allows screen to be drawn on RAM
and displayed, even with framebuffer and everything
Makes it a much better machine for action games than MSX2 ever
was and the extra features it has just makes it superior to MSX1. The
only thing I believe MSX is really better (from a gaming program
perspective) is:
A) Sprites
B) VDP Commands (only valid for MSX2)
And since (A) is a *very* limited feture... and (B) is also of limited
use - about 16 outputs to ask a pattern copy is something VERY
annoying (it is needed basicaly because VRAM access is slow,
we need to place patterns there to free RAM space), these features,
game wise, means almost no advantage at all. With it's "ADVRAM",
SamCoupé performs, graphic wise, much better than MSX with
VDP commands.
Some will say "Gah, we have 7MHz computers and also have
turboRs..." And I will answer: the botleneck is VDP. If I just output
data to VDP @ 7MHz disabling the V9958 wait signals to CPU,
the computer just crashes. On turboR this makes no difference,
since S1990 add the delay for itself, but it adds *more* delay
than needed, which means that graphic intensive games performs
*worse* on turboR than on MSX2+ computer @7MHz.
Speccy PoP is possible on MSX1, but probably will require memory
mapper and will be slow. To be fast enough it will require MSX2 (or
MSX2+, for maximum speed using total V9958 bandwidth) @ 7MHz,
and it will have the same Speecy limitations.
Doing PoP for MSX without many ugly limitations is a very hard
work which requires the author to be very fond of the job; otherwise,
he will not finish the game for sure. SLotman do not want to create a
sluggish version of Prince. So, he will only work on the project when
he figures out a way of creating the game the way he wants it. And
make no mistake: if this game ever get finished for MSX, it will
requires a *very* good machine.
Remember: the most limited versions of the game are Speccy
and GameBoy versions. And both of them uses more resources
than a normal MSX1 has. Following we have SMS and SamCoupé
versions (which are great, IMHO); these are not directly possible
on MSX because the original computer has more resources than
the average MSX2 (SMS has a more powerful graphic chip for games
and SamCoupé has direct video memory access... both have more
RAM than a regular MSX2... and both are relatively FASTER than MSX:
SMS is from 10 to 20% faster - no extra wait on M1 - and SamCoupé is
about twice as fast as MSX - and both of them have VDPs that can be
commanded at full CPU speed, no delays needed).
FINALLY, in short, I believe - of course - Prince of Persia is possible
on MSX. But I got sick of people saying things are easy. It is important
to keep in mind that each game is unique, there is no universal solution.
One trick that optimized a lot one game will most likely *not* optimize
another game in the same ratio.
If it is so easy and the developers working on the ideas are so decrept,
please, be my (our?) gest and get the job done. Everyone would benefit a
lot from it, even the old developer, which can then use its time on other
projects.
So, when one (anyone) thinks something is not done yet is "simple",
please, do it instead of complaining and doing doubtful assertions.
Sorry about this post, but sometimes - when reading some of these threads -
I feel like Mr.Creosote, from Monty Python's Meaning of Life:
"Bug off! I'm full!"
My kindest regards,
Daniel Caetano
http://en.wikipedia.org/wiki/SAM_Coup%C3%A9
it's not all so super .I think your claims are not so true.
if you read this article on the wiki it says:
"Video memory problems
Internal RAM was shared between the video circuitry and the CPU, with CPU accesses incurring a speed penalty (the memory contention delay) as it waited for ASIC accesses to finish. As a result, the SAM Coupé's CPU ran only around 14% faster than the ZX Spectrum CPU, yet was required to do much more work in Sam's appealing high-resolution modes to produce a similar movement on the display. A Mode 3 or Mode 4 screen uses four times as much RAM as a ZX Spectrum, so four times the work had to be done in the same time.
A small compensation was the straightforward arrangement of colour pixels in this memory, instead of the ZX Spectrum's oddly-laid-out display and attributes memory. Low-level graphics software operations could be much simpler than their Spectrum equivalents and therefore somewhat faster to execute.
The penalty of memory contention delay applied to all memory accesses to RAM, and not just to memory associated with the video circuitry (as in the case of the ZX Spectrum). Hardware sprites and scrolling would have greatly improved the performance of games, unfortunately there was insufficient wafer space on the VLSI ASIC to include such circuitry.
While the main 256×192 area of the screen was being drawn, the processor could only access memory in 1 out of every 8 t-states. During the border area this was 1 out of every 4 t-states, which had no effect on the many instructions whose timings were a multiple of 4. In modes 3 and 4 the display could be disabled completely, eliminating these memory contention delays for a full 6 MHz running speed. Code running in ROM was unaffected by the contention, though any RAM accesses they performed would still be affected."
Msx2 can have many memory mappers and you can have easily more ram than 4mbytes,vdp operations on screen 5 and after i think seem much easier to do.Msx had games such as space manbow in screen 4,sam coupe cant do such things at all even at 6 mhz.
Spectrum port of Prince of Persia was not that bad,i played it in an emu and i think that msx platform has far more capabilities than zx spectrum.Besides i dont think that the 4 sprite per row in that game would create any problem.It's not a shoot em up,usually we see 1 enemy per screen,so if an inferior color clash style zx spectrum can do this,an msx1 version could be possible.
Just my thought
http://en.wikipedia.org/wiki/SAM_Coup%C3%A9
It's not all so super .I think your claims are not so true.
You are right about memory contention, I just didn't know about it (I had read some tech docs from SamCoupé and they are
not clear about it - I thought the hardware detached RAM blocks when drawing on screen). I read it when I thought about porting SamCoupé games instead of ZXSpectrum ones (since many SamCoupé games uses the mode that is similar to Screen 2, more
colorful than Speccy games). After reading about some of its specs, I gave up. Bring Speccy games to MSX in a decent speed is enough challenge to me. :P
http://en.wikipedia.org/wiki/SAM_Coup%C3%A9
A small compensation was the straightforward arrangement of colour pixels in this memory, instead of the ZX Spectrum's oddly-laid-out display and attributes memory. Low-level graphics software operations could be much simpler than their Spectrum equivalents and therefore somewhat faster to execute.
Hehe... I am not so sure about being "that" small. Anyway, a pratical data, most Speccy games draws the screen only in the vblank
time. Since Speccy runs at half of speed of SamCoupé, I believe most of a "screen 2" screen can be drawn just the same, since its Z80 runs twice faster to draw less than twice the data. For the "screen 5 and 6" modes, of course, full screen update would not be possible only in this time.
Since all of its memory is contended, it's a bad design, really. If it were like Speccys (only the block connected to VRAM being contended), I can assure you the contention would not be something so bad. Otherwise, this is a real pain in the ass. Anyway, taking into account that most of screen can be redrawn in the VBLANK, that only means less CPU time for game logic, meaning the game has to be simpler. In the case of PoP, the game logic is pretty simple to me. I cannot see complex game processing. The difficult on doing it on old computers is really the video part, including the miriad of beautiful animations.
BTW, the memory contention is only bad because it happens almost all the time. If it only happened when writing to VRAM,
it would makes Z80 work SLOW only these times, while on MSX, when writing on VDP (updating screen), it's like if we had a HALTED Z80, making no useful work at all. Of course, using patterns help a lot (less time updating VRAM) but this is useless if you want colorful graphics and smooth movimentation... this can be solved only with clever tricks like the one used on native GnG by dvik, but this method has some limitations, though. Also, VDP commands can help a lot, but then the Z80 keeps only sending commands and waiting for the last command to finish... and again, this is like Z80 being HALTED, which is way worse than working slower (conetended memory access is slowed, but once data was acquired, Z80 will process it in notmal speed).
I really would like to have a Sam Coupé to do some tests. Everyone spoke about contended access being a big drawback on Spectrum... but my experience is that most of times it makes no difference at all and Speccy games manage to run *a lot* faster than the same code running on MSX - even with NO video output (!). I tested this counting interrupts during Ghosts'n Goblins development, and Speecy manages to do some game work calling 20% less interrupts than MSX (I executed game loop for a limited number of times and, while MSX took 220 IRQs to do a work, Speccy had done it in only 150 IRQs. Of course, Speccy was running at 50Hz and MSX was running at 60Hz. This means something about (150/50) * 60 = 180 IRQs when correcting different frequencies. Ok. That means a loss of 22% of speed. But I am being nice and saying it should be about 20%, because the conversion of IRQ couting due to different frequencies I made was not accurate (there is an overhead not counted due to register saving/loading on IRQs). Anyway, it's a pretty big difference to me.
That means the difference is similar to the difference of clocks, due to extra M1, plus differences in time used reading keyboard (slower on MSX, due to more lines/columns to read), something I had to do (and had done in a similar fashion done by Spectrum), since GnG uses ROM interrupt routine to read keyboard.
*** Of course this difference cannot apply directly to the result presented to the user, when we are talking about games designed exclusively for each plataform. Using exclusive MSX features makes possible to overcome this processing time difference, but it will be there. ***
If SamCoupé manages to be a little faster than Speccy, that means it is faster (than MSX) even having it's accesses contended. Remember that being able to access memory each 4 or 8 cicles at 6MHz is almost the same of being able to access memory at each 2 or 4 cycles on 3.57MHz (which is less than a NOP to a NOP time). This means the waiting for memory access is small enough, although it would be nice it was not needed. And again, I am *not* considering the time Z80 is "halted" when updating the screen (RAM=>VRAM on Screen 2) on MSX2/2+, which takes a lot (hundreds of thousands) of cycles on MSX, when updating the full screen. On MSX1 this can be even slower, due to the awful extra wait time needed between OUTs.
So, if you say me to choose: A) "contended memory" like Speccy or B) "update screen (withouth using name tables) via I/O port without contended memory" I would probably I would decide for (A). If the contended memory is like Wikipedia's Sam Coupé description, I would have a hard time deciding, and would ask "Can I do some benchmarks?" hehehe
Msx had games such as space manbow in screen 4,sam coupe cant do such things at all.
I didn't say Sam Coupé is better than MSX2/2+ on every aspect. In fact, when *very well* used, MSX2/2+ can accomplish some incredible things. And, IMHO, Space Manbow is an incredible thing. But it is nowhere to start when comparing to other machines simply because it is the best a MSX game have ever got, when talking about action and smooth moving. And it uses every drop of VDP to do what it does. It uses nametables to draw screen, it uses palette changes, is uses sprites and do line irqs to draw up to 64 sprites on the screen, it do tricks to use VDP commands on Screen 4 (well, the top of screen is Screen 5, isn't it?), is uses setdjust/hardware scroll... it uses every NICE feature MSX2/2+ (plus an extra sound chip and 256KB of ROM, using also some RAM and all 128KB of VRAM) has to bring you that result. Now, tell me how many MSX games do you know using so many tricks at the same time. This is why I do not believe it's a game to use as comparison when someone is talking about 'how easy is to bring something from another plataform'.
The fact MSX2/2+ is able to run Space Manbow - a game developed with MSX constraints in mind - doesn't make it able to run everything. And more: saying it's "easy" to do another game because MSX is able to run Space Manbow is nonsense.
Of course, this is just my opinion (and that's all it is: just an opinion).
But I really hope you prove me wrong. June/2008 is a good date for your Prince of Persia release? ;)
It can be just the "Sam Coupé" ported version. ;)
Spectrum port of PoP was not that bad,i played it in an emu and i think that msx platform has far more capabilities than zx spectrum
Yes, it has. But the fact someone can sing doesn't means that person can program a computer. :P
MSX has a lot of features I had not mentioned. And I had not mentioned them just because I believe they don't help so much as one could expect when programming a game like Prince of Persia.
Just my thought
I agree with you in many aspects.
I just cannot agree with the assertion this is "easy" to do.