Load games using MSX2CAS

We have often heard that there are output level problems with many handheld devices.
It is difficult to find the right setting. Some devices do, others don't.
Some cut hights, some compress.
You have been looking for a solution to this problem on other channels for a while now. Fact is, you are not doing anything wrong. In my eyes it is the level of the playback device.
It is certainly easier with devices like the CasDuino or a ROM loader cartridge. Of course there are costs involved in buying such a device but it also promises to be easier to use.
And more pleasant lifetime. Isn't that what we are looking for?

Of course it can also be due to the technology of your computer, but general loading problems for the AX-200 are not known (at least I didn't heard about any (that massive)).
The easiest way would be to verify your workflow on another (working proofed) machine.
For this test setup you are surely in demand.

That depends on the information in the header.
See:
https://www.msx.org/wiki/MSX-BASIC_file_formats

28815 only for basic programs. Such restriction doesn't apply to binary files (the ones you bload)

I'm not a programmer, but I've understood the issue as following (roughly):

A binary file (which is loaded straight from BASIC) can only load into those addresses which are free when BASIC is loaded at MSX boot (not on top of blocks already containing the routines, on which the program is still reliant on). After the first binary block, which will be run, has been run, the binary file can take over. That is what the ,r -parameter does; it runs the binary code, again at an address, which is specified in the header. Some loaders (loaded with load"cas:",r or just run"cas:" - these two are equivalent commands) might load several binary blocks, and in that case, usually only the last one will be run (you can list the BASIC program beforehand and see what it does).

Now, after the binary program is in charge, it can do whatever it wants. It can erase those parts of the RAM which are occupied by MSX-BASIC (and whatnot; actually, it would be more correct to say change slots), in case the program does not need them; however there might be some limitation here, for example space reserved by disk drive controllers can not be overwritten (many games insist on disabling disk drives and even print errors, requesting a reboot with SHIFT held down). I'm not sure why the disk controller reserves memory this way... maybe someone more inclined into programming and the internals of the MSX might shed a light on this with layman terms =)

The binary program might do other stuff, too, such as copy parts of the binary file elsewhere in the RAM, copy parts of itself into VRAM etc... (again: I'm not a programmer and don't know what kind of tricks are useful and commonplace, I'm talking in terms of what is possible in principle).

Some programs might use BIOS ROM (or any other memory mapped device in some other slot); i.e. change the slot for each of 0000-3FFF,4000-7FFF,8000-BFFF and C000-FFFF pages as it pleases; they should keep track of at what slot the RAM resides. But some programmers made assumptions, such as not take into account the RAM could be in subslot(s) - or just made an error in the routine, which works in most, but not all cases. This causes the errors; the program thinks it is changing the slot to RAM while it is actually not doing that (but changing to some other slot). Note: in principle this has nothing to do with the size of the program; size!="what memory addresses a program uses" !

EDIT: See: https://www.msx.org/wiki/Slots . Don't care about memory mapper information on that page, as memory mappers are a bit more complicate thing, but vast majority (=probably all) of cassette software uses only 64kb max, i.e. it does not use mappers.

However, it is quite useless to speculate much further; you could list the games which are giving problems, and there 1) either might be known problems with those games (also list the sources/MD5SUMs etc., there might be several versions floating around the net) and 2) those which do not have known problems, could be tested on another computer where the RAM is split in the same way as on the AX-200 (or, by someone else on the AX-200).

One thing which hasn't been mentioned is the universal poke (see the incompatibility page). Have you checked the games which are giving problems, for BASIC loaders which might have poke commands in them?