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

The BIOS functions don’t support block read and write, if you want to do that you need to select the slot into an address range, copy the data, and switch it back. So indeed you could make a library function which selects the slot, memcpy it to or from another array outside the switched page, and then switch back to the original slot.

What I meant with byte array access though is, select a different mapper bank at address 8000H-BFFFH and have an array pointing to 8000H, I think something like:

TINY * memoryData = (TINY *)0x8000

Then you can access the data with memoryData[0x0], 1, 2, etc. up to 3FFFH. Could also be an array of structs as long as it doesn’t exceed 16K. But in general array-based access seems most convenient, because you don’t want to pack the values yourself. Alternatively, a single big struct containing all the substructures.

For something like loading graphics data into VRAM, or reading MML or tracker music data a byte array should work fine. For writing SCC sound data a struct may also be convenient, so you can access the registers in a structured way.

Actually, what do you need all that memory for? 64K ought to be enough for everyone…

Why I ask is, which is a good way to address the other slots and extra memory depends also on what you want to use it for.

@Axelstone, rdslt works, except that it can't flip the mapper. It could read when you plug a vintage 16k RAM cartridge
If you flip the mapper before the call to rdslt, one again got the same problems as mentioned above.
the p3bios slotread is with full address, slotid + mapper.

The DOS2 mapper support routines do provide slot IDs if you opt to allocate a segment in a nonprimary mapper, you just need to do the actual slot selection via the standard BIOS *SLT routines. One of the important goals of DOS2 mapper support routines is to be high-performance (so people won’t hesitate to use them), as well as not consume too much memory from the top of the TPA, those are good reasons why it doesn’t deal with slots.

But of course you can make your own little wrapper which compares the mapper slot ID to the currently selected slot ID (non-trivial to determine unfortunately), and first switches the slot if necessary.

You mean writing to an I/O port... But there’s two problems about this (and the reason mapper support routines were introduced in DOS2):

1. If multiple programs are using memory, e.g. ram disks or TSR software or whichever, without mapper support routines a program has no way of knowing what memory is in use and they will start to overwrite each other.

2. The mapper bank selection registers can’t be read reliably, so to properly support temporary mapper switches which need to restore the original bank afterwards (again, consider ram disks, TSRs, etc.), a mirror needs to be maintained, which is why you should not directly use the I/O ports.

Writing to that address does nothing except mess up the internal state of DOS. Those are RAM slot IDs mirrors of the memory selected in each page of the addressable space (= the default slot configuration when starting a DOS program). They’re not mapper bank selection registers nor mapper bank numbers. You shouldn’t change them, and writing to them has no effect. When you say "tested and works", your test must be broken...