The complexity of a gfx module has other complications to consider. If you just take a single g9k in P1 mode then at two bytes per tile and two planes, you already have four times the memory occupied to define you screen. If you want to fully utilise that, you will already need most of the io capacity of the tR. Anything you add to that will take away things you can do with the first one. Which probably makes things like the VSU especially interesting for basic use, but somewhat less for coding complex games.

What about the future of VDU ?

Personally, as an hobbyist, I feel too lazy to start learning from zero a new platform...
(It is, only the z80/r800 stay the same).

Ask yourself why there is almost no new msx game except for msx1....
Not for MSX2, not for msx2+, neither for TR or G9K.

IMHO, one reason is that moving to new HW costs effort, and hobbyists are lazy :-)
(it is an hobby, I want to enjoy, not to bang my head on new/dead HW, to study from zero)

Will the VDU share the same destiny of G9K ?
If not, according to you, why ?

I do not see a bright future for this kind on new HW....

Quote:

What about the future of VDU ? Personally, as an hobbyist, I feel too lazy to start learning from zero a new platform... (It is, only the z80/r800 stay the same).

It's not a new plataform. If you can code to 9958, you can code on VSU - even on plain BASIC (it has two of them, on the same port 98h/99h, you just need an OUT to select each or both of them) - the rest works the same way as in a normal MSX.

If you can code for gfx9000 - you can also code on the VSU - even using GBASIC. Same for Moonsound, with the extra benefit of 1Mb sample RAM.

Also, you don't have to switch video output... just connect the VSU in the cartridge slot, connect it's video output, turn on MSX and use it as always!

And there is a reason for Oazem to put 4 9990 - You will be able to use the higher resolution/colors modes on the gfx9000 - the mickey demo is in screen 8 - all the planes and the scoreboard on SCR8... and the whole map/screen is on VRAM, no need to keep copying stuff from RAM!

Now imagine using the 32k color mode of gfx9000, or something to do a reaaaaaly nice puzzle, or just as a gorgeous background to a nemesis-style shooter...

There's no way a single gfx9000 can do that

You can also do text adventures, using one high-color mode to display images, and using screen 0 / 80 columns to display the text... you won't be constrained thinking "oh, I need to write tons of code to deal with sprite flickering...", "I need to reduce the frames because it won't fit on VRAM", "VDP is too slow... I could do better with a faster one"

I can't wait to have one in my hands to "play with"

Oh, yeah, Oazem just sent an email on MSXBR-L saying that it will be available in the first semester of 2009 for sale

@Slotman: just a question: if the ports are the same (multiplexed) to the original msx.How can a out on this port go to the vsu instead of the original hw? (the original on-board vdp in any msx)? Do you remove the original vdp from the msx? (not possible the cpu may have problems)
How is the original VDP disconnected from the z80 bus when you do a in a,(0x99)?

Àccording to Oazem, the VSU comes with a small circuit to be installed inside the MSX (he said is just a matter of soldering 6 wires, something *really* simple to be done) - which disables the internal VDP - only when the VSU is connected - so without the VSU, the machine works normally, connect it, and the internal VDP is disabled.

i'm inviting you to read this:

http://www.msx.org/forumtopicl8936.html

Quote:

That Mickey Mouse thing is AWESOME. Give us more, SLotman! One question: would this also work on a plain GFX9000? I'm kind of curious, as the GFX9000 can do multiple layers quite easily as well.

Just checked those vids...

VDPX would handle that with insane ease and on top of it could do much more spectacular things

Quote:

Okay, you can play a MP3 file on your MSX but you can't do anything else at that moment because the system is completely occupied with playing that MP3.

Sorry for being offtopic, but this is not correct. Playing a 128kbps MP3 requires about 25% CPU time (including loading the MP3 datastream from IDE!). You can check this in SymbOS. So for a 64kbps MP3 you would need the same amount of CPU time like for playing an usual AY tune like PT3 etc.