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

This way of using bank switching is specially useful to store data in high zones of RAM. This is, you can compile your MSX-C program using the basic 64Kb, but all data and variables used can be stored in high 64Kb using bank switching. By this way you have available all 64kb only for logic, so you can make very complex games. However as I said, personally I'm still far of exceed 64kb, first I need to learn how to use them!

@hit9918 Good luck with your project, it sounds promising.

You could make such assumptions, and then when someone tries to run your program with a ramdisk, and the data will be corrupted.

Why do you not want to use the mapper support routines? It saves you the trouble of detecting the mapper sizes and slots, for one thing, and has better compatibility and less risk of issues like the example above.

My personal preferred approach is to support DOS2 mapper routines by default (through a wrapper), and then add a compatibility layer to the wrapper which activates when DOS2 is not available. It is a bit of extra effort, but most of the effort actually lies in the DOS1 side of things. This is why VGMPlay currently only supports DOS2, I haven’t gotten around to writing the compatibility code yet.

Note MSX-DOS2 uses that 32K regardless of whether you use its mapper support routines or not... When you ignore it, you will overwrite MSX-DOS system code with unpredictable results. And often DOS2 is loaded by default, e.g. when you have a turboR, or a MegaFlashROM inserted... I don’t know, maybe it will work out, but it feels dangerous to me to ignore it .

Yes, I think so, unless you press a key during boot.

There is, when you don’t insert DOS2 .

If you need 128K, the software can abort with a not-enough-memory error, and the user can then choose to remove the cartridge or hold the boot key. I think that’s better than just using the memory anyway and getting something unpredictable like random crashes or something like that. Also, being able to run in the DOS2 environment will make it easier to run the software from HD, which I think is a big benefit.

DOS2 uses 32K for system purposes (for the msxdos2.sys code and storing data like file control blocks, buffers and mapper tables). When run from the DOS environment 64K is available to the program directly, with 32K more which can be allocated on a 128K system. When run from the Basic environment 32K is available to the program directly with 64K more on a 128K system.

Yeah, that’s what I meant by "My personal preferred approach is to support DOS2 mapper routines by default (through a wrapper), and then add a compatibility layer to the wrapper which activates when DOS2 is not available."

Note that when a DOS2 cartridge is inserted, it is active even when not in the DOS command line environment. So use of the DOS2 mapper routines is not really "optional" when they are present, at least if you don’t want to risk crashes or other odd (possibly destructive) behaviours. If that means there’s not enough memory you should tell the user and he can decide whether to remove the DOS2 cartridge or plug in a memory mapper.

Most DOS1 software just sticks to the usual 64K address space and does not use a memory mapper so it’s safe to run, but yes there is risk (and you can’t really tell either). It’s the compatibility cost of new OS features, and the reason why many DOS2 cartridges offer boot keys to skip DOS2 and why the turboR does this confusing thing where it disables DOS2 based on the disk boot sector.

The best new software can do is to be well-behaved by using the DOS2 mapper support routines when available.