Quote:

but trying to do fast effects through the slow VDP-interface will be tough

The bottom line is that the VDP dictates what you do, what you have and what you don't have. With a piece o' mapped RAM being the framebuffer the coder is in full control. The VDP is a good SymbOS chip tho, as it's based on moving rects. Then again who'd have thought in '85 that we'd be wanting to do demo effects.. I guess the design/concept of the VDP was suitable back then as the MSX2 was -I think- more meant as a home version of the office PC than strictly a game-computer like the C64. And for office tasks the VDP is very suitable.

and if someone in 1985 had some thoughts about MSX2 users may want to make demos, must say that 1985 demos were "little bit" different than those 21st century C=64 demos....

Guess it has to do with knowing the hardware from the inside out by now and an entire community sharing technical knowledge
that makes new demos more advanced

Quote:

Quote: nor seen any truly original game on it. welllllll....I realy realy beg to differ here.

Well o.k., I saw a lot of 'em but I didn't exactly see every Amiga game ever released.

So if you can name a few, I'll go look for them.

Maybe have a look at this extensive list of Role Playing Games for the Amiga
and I recall enjoying Pirates! on it

Hehe. Looking at these pictures made me remember why I like MSX more than the other available home computer at the time.
The games of the others (spectrum, C64, amiga etc) clearly look european. As MSX games look Japanese (manga-ish). Which I like much much better......

Don't forget the sound.

But hey, I guess it's best to have the best of both worlds.

Quote:

As an oldtime C64 demo coder that just got my first MSX a couple of months ago

@Sdw: just for the sake of curiosity.... when doing a fill of 8KB of the C64 VRAM, what the estimate fill rate (KB/s) that one can reach on the c64?

Sorry if OT

Quote:

Quote: but trying to do fast effects through the slow VDP-interface will be tough The bottom line is that the VDP dictates what you do, what you have and what you don't have. With a piece o' mapped RAM being the framebuffer the coder is in full control.

Most of people complain about the port based access as a reason of slow vram access. IMHO the real problem is memory bandwith. Actually outputting a byte to vram require about 7.2 us on the msx1. this is not because of intrinsic vdp slowness, instead it's the vram bandwith that is too small. Even with a memory mapped schema, using the same vram chips, only 1 of 16 access is available to cpu, the others *must be* reserved for display. This mean that the z80, even with a direct mapped access can write only every 6us. Not more quickly than 7.2us.

Consider also that a normal z80 memory write operation like ld (hl),a lasts little more than 2us......

In all situations, with the same ram chips, the ram write is somewhat 3 times faster than an hypotetical mapped vram write.

Of course things are different if you compare random non contiguos memory writes. But normally vram writes are contiguos.

The real problem is memory bandwith. I fully agree!!
And the crappy way for setting the VRAM addresses.
I would,e.g. used different ports for VRAM setting in read mode, in write mode and for setting registers

Quote:

@Sdw: just for the sake of curiosity.... when doing a fill of 8KB of the C64 VRAM, what the estimate fill rate (KB/s) that one can reach on the c64? Sorry if OT

Assuming you mean 'fill' as in simple clear mem (there is no distinction between memory and vram on the C64) you would simple do something like

LDA #$00
STA ADR
STA ADR+1
STA ADR+2
...

If we ignore the first LDA since it is negligble when doing a couple of thousand STA, a STA takes 4 clock cycles. I think a pal C64 is 985kHz or something like that, which would give us a fillrate of about 246kb/sec.
That was just from the top of my head though, I could be way off.

Quote:

Quote: @Sdw: just for the sake of curiosity.... when doing a fill of 8KB of the C64 VRAM, what the estimate fill rate (KB/s) that one can reach on the c64? Sorry if OT Assuming you mean 'fill' as in simple clear mem (there is no distinction between memory and vram on the C64) you would simple do something like LDA #$00 STA ADR STA ADR+1 STA ADR+2 ... If we ignore the first LDA since it is negligble when doing a couple of thousand STA, a STA takes 4 clock cycles. I think a pal C64 is 985kHz or something like that, which would give us a fillrate of about 246kb/sec. That was just from the top of my head though, I could be way off.

So a copy routine (move byte from memory to memory) reach about 123kb/s, right?

Quote:

So a copy routine (move byte from memory to memory) reach about 123kb/s, right?

Yes, a LDA from absolute address also takes 4 cycles, so copy-mem would be half the performance of the clear-mem.

Quote:

The usual suspects: http://www.youtube.com/watch?v=zVPW40ygds4 http://www.youtube.com/watch?v=zipu3Wfh_wU http://www.youtube.com/watch?v=aUuds9bXFnY&feature=related http://www.youtube.com/watch?v=0-mu2rAgK_w&feature=related http://www.youtube.com/watch?v=V3qJNltIscI&feature=related So, this runs on a system older than an MSX1. You may be able to 'port' certain effects to MSX1, but not without loss of quality and/or quantity (monochrome rather than color, less objects, less frames, more RAM requirements etc.)

Instead of focusing on MSX1 (which is probably incapable of most cool effects demonstrated), let's try to see if even MSX2 comes close to the C64 demo standard. For example in emulating this:

http://capped.tv/playeralt.php?vid=booze_design-edge_of_disgrace

Part of this is probably feasible, but I'm still totally amazed at some of the effects.

Actually neither on msx2+ you can do the same things at the same framerate....
Zooming in bitmap modes is by far slower, the best alghorithm I have dops its framerate
below 10 frame/sec as soon the image reach 1/2 of the screen