Memory Mapper Segment availability/allocation under MSXDOS/Nextor

Page 3/3
1 | 2 |

By DarkSchneider

Paladin (880)

DarkSchneider's picture

09-05-2019, 13:45

Well in that case it fits for some case, for auto-boot programs using MSX-DOS, it would load MU at boot, and no need to worry about exit because is reseting the computer.
But the free memory segments code should not be required (so present) to be fully standard compliant.

In a DOS TPA would not fit, because you would have to apply not standard rules, but "MU" rules. In a prompt environment you don't know what the user have installed, so can't use any specific but the standard.

By Grauw

Ascended (8507)

Grauw's picture

09-05-2019, 18:33

So you free the segments you allocated before terminating. I do so in VGMPlay. Though it only works on DOS2 because I use the DOS2 function calls for disk access. Big smile

By DarkSchneider

Paladin (880)

DarkSchneider's picture

10-05-2019, 10:27

Free segments using DOS2 standard functions is OK. Not required but also not prohibited.

While the code is DOS2 compliant, it is OK. But I'd not condition the code thinking about "MU" or any other thing, because what the user will have installed is unknown.

Then at that point, it is more about how much granularity you want to put on software requirements, if you only use the memory mapper, you could put in requirements something like "128KB of DOS2 memory mapper RAM". But think the more granularity, the more expertise users should be. In real world to simplify the usual is to split by system, so MSX-DOS, MSX-DOS2...
It is like when using the V9938, we usually don't put "V9938", but MSX2.
Because for requirements usually the best is to give them in discrete form using the official devices as reference, in this case all devices that implement DOS2 memory mapper are full DOS2 devices I think. If something like a "DOS2 memory mapper device" had been launched, probably there were no problem requiring it instead "DOS2" (without more detail) even if you only use some part/s.

By Grauw

Ascended (8507)

Grauw's picture

10-05-2019, 12:17

In the end the Extended BIOS Mapper Support Routines are the only standardised means to use the mapper. It is unfortunate that these support routines aren’t present by default on MSX2 and up, however MSX-DOS2 cartridges are very common nowadays and there’s also the alternative of MU.COM if you don’t have one of those. Without these, I think it’s generally better to try and avoid using the mapper, because you don’t know what you’ll be conflicting with, it’s just a dangerous endeavour.

Obviously it is easiest to just make MSX-DOS2 software, because then the mapper support routines are pretty much guaranteed to be there. Software which needs more than 64K usually falls in the "utility" category and not the "game" category anyway, and then it’s okay.

But if the software does not otherwise depend on MSX-DOS2 (not using DOS2 function calls), I think the requirement should say something like "Extended BIOS Mapper Support Routines (MSX-DOS2)". Ideally actually it provides its own mapper support routines library when none is already present, then there is no need to mention any particular requirement at all.

Page 3/3
1 | 2 |