I want to learn MSX-C, where do I start?

Ok, now I appeared as hacker with otir. And will argue point by point how I am tidy and high level

Look at this very high level code

struct OBJECT { char Y; char X; char P; char C;.... my other things, dx,dy, .... };


struct OBJECT objects[128];
struct OBJECT* spritelist[64]; int spritelistlength = 0;

void dumpSpriteAttributeTable() {
	int i;
	setSpriteAttributeTableVRAMAddress();
	for (i = 0; i < spritelistlength; i++) {
		otir(VDPport, 4, spritelist[i]);
	}
}

And the otir copies directly from the object to vram without a copy in RAM.

And the spritelist has spritesort abilities that the ordinary app can only dream about because it is too directly wired, not high level enough
Why did I make the spritelist 64 sprites? Because you never know what the sprite engine can do, this is very high level
The sprite engine does wildly shuffle in the sprite list, but your objects are not touched, because that thing is so bloody abstract and high level

I use this highly abstract object oriented coding in my highspeed asm game

question: what if I call screen(8) on MSX1? I use "a bios call, no coding registers, oh so high level", but the app will do nothing but garbage. the otir() is no worse!
on MSX1 you must use the screen(2). and the otir29().
and no, things are not dependant on screen mode.

the MSX has a vram file streaming device
question: what happens if you call fread() without opening the file? it crashes!
otir() has the same characteristics as the very high level fread(), you better first open the right file

otir(VDPport, amount bytes, array) also can be used on the 9990.
similar to fread() asking to pass the right file descriptor, otir() asks to pass the right VDPport descriptor - again otir() is no worse! but same as the high level function

otir(), the most abstract universal streaming device function ever
spritelist, the most abstract high level universal speed sprite datastructure ever

The thing is. The programmers who want BASIC in C. That is what created the tension.
There is a way to code C without the nasty operators "*" and "&" popping up.
Memory acess wise with arrays one can really code it much like BASIC.
So when I cross that red line, I am practicaly using an unknown language and the reaction is meeeeh.

Silimar situation on the library side.
You got to admit, the comparison of otir() and fread() was a surprise.
the keywords "high level" just dont cut it.
what actualy is wanted is a SAFE LANGUAGE.
And sometimes one can get the C typechecking relatively far.
When making a library for the MSX, one should hunt for avoiding the nasty operators (not in implementation, but in usage).

@DarkSchneider, I added some thoughts to your code.
grouping things in loops and then in a copy of 4 bytes at once. then the struct yxpc needs to be in vram order.

struct {y, x, p, c...} sprite_data; // an entry for SAT
sprite_data sprites[32]; //our 32 sprites = to the full SAT

put_sprite(TINY index, sprite_data *data)
{
sprites[i].x = data->x;
--- //copy all the other data
}

toRAMSAT(sprite_data *data) {
	for (i = 0; i <32; i++) {		//a loop instead one function call per sprite
		sprites[i].x = data->x;
		...
	}
}

toRAMSATfast(sprite_data *data) {
	for (i = 0; i <32; i++) {
		memcpy(sprites[i], &(data[i]->y), 4);	//a memcpy to copy 4 variables at once
	}

}

tovramdirect() {
	setSATvramaddress();
	for (i = 0; i <32; i++) {
		otir(VDPport, 4, &(data[i]->y));	//copy to vram directly
	}
}

In the demo I posted there is otir() for sdcc.

/facepalm

No. This name comes from the LDIRVM BIOS call, which (oh, coincidence) does the same thing as ldirvm().

What about the IX register to call EXTROM?

OK, I found it, using calsub().