look at this, say I got a
struct sprite { char Y; char X; char P; char C } spr;
this is the BASIC way
putsprite(i, spr.X , spr.Y, spr.C, spr.P);
and this is the C way
otir(VDPport, 4, spr);
Instead all the Y X P C getting shoveled forth and back on the parameter passing stack,
the z80 otir instuction copies these 4 bytes directly from RAM to the VDP port.
and it goes without vram address setup because it goes in a loop for sprites.
"why reinvent the wheel",
without having a library with putsprite, it was magicaly created out of nothing with otir() 
@hit9918 I think that you are not understanding the philosophy behind the use of a compiled language. Libraries is one of its best feature against not structured languages as Basic or even ASM. They have 2 big advantages:
- Designed once, used by everyone. They are suppossed to be well tested libraries, so you are using a good solution for your needs.
- Code readable. Since everyone uses the same functions, is really easy to read examples since it uses everyone codes in a similar way.
The idea of "make for yourself" is applicable to ASM, but in structured languages as C the idea is the opposite: never reinvent the wheel unless absolutely necessary. 
@hit9918 that so direct access to hardware should be avoided in MSX when possible, its open architecture design is more oriented to use its API included in the BIOS, instead the Z80 and ports so directly.
@hit9918 I think that you are not understanding the philosophy behind the use of a compiled language.
Dear AxelStone and Darkschneider, very good, I too speak more freely
All the concerns you bring up, they are not true.
"structured", the otir() was using a struct, the putsprite() did not, an irony.
"open architecture", the otir() to the VDP port of peek(6) is standard,
and if it werent, then the MSX would have NO GAMES.
I did not suggest to OUT to the floppy controller, but with the VDP it goes fast and elegant.
The question is whether we are actualy having a technical argument.
Are there more urgent showstoppers that prevent making a game or kill motivation?
Better than otir(), you could use i.e. a fixed-size zone in RAM equal to the SAT (Sprite Attr Table), and then use LDIRVM (BIOS function) to copy it to VRAM all-at-once. Working on RAM is much faster for CPU than writing small amounts of data to VRAM many times, and then write to VRAM all at once
Let me mention that you did throw away putsprite(), the thing I am always talking about
Who actualy has which position, confusion
The otir() requires that you get the VDP port from the bios variable. Then it is the same compatibility as LDIRVM.
The MSX C code of LDIRVM that was posted, it has exactly the 29 cycles loop as the otir29() I posted, that is the slower loop for MSX1.
But the MSX2 can go in 18 cycles with otir().
@hit9918 Well you can develop in the way you feel more confortable, there is no doubt about this. I simply suggest that if you are going to use MSX-C the idea is to use the provided libraries instead of making news. You talk about kill motivation, but I think that all of these libraries allows you to focus in game development itself instead of making libs for everything by yourself.
You allready have functions to copy ram<->vram, putsprites, handle memory, initgraphics...Thats good, you can focus on game logical instead in thecnical issues. I'm not going to discuss if putsprite could be made in less cycles, I'll simply use it
Obviously if there is a growing comunity around MSX-C, it'll be very possible that to people make revised versions of existing libraries in order to improve them, or even add not existing libs as moonsound support.
The main reason to use msx-C instead of hitech-c or sdcc is its library
It could even very interesting to find a way to reuse such libs in other compilers
I think it's a definitive advantage, MSX-C library is very impressive, it's implemented basically all needed functions. As you say, it should be great to get all these libs compiled for other enviroments as sdcc or hitech-c. By the moment, we can use them in MSX-C