Reading a file into "non-RAM" slots with MSX-DOS 2 functions

Page 2/2
1 |

By DarkSchneider

Paladin (941)

DarkSchneider's picture

14-02-2019, 14:31

A big problem is at the very moment slots are involved, we have different behaviours from RAM usage. That affects directly much to the software design itself, that is not good at all.

We change "access to RAM segments is fast" to "access to RAM segments could be fast". That implies to determine a segments handling policy, and depending of configuration even that policy change its behaviour.

One of the best features that is inter-segment calls, is literally destroyed, as you can't rely on it anymore.

By Grauw

Ascended (10013)

Grauw's picture

14-02-2019, 15:23

Basically my problem is that earlier you were advocating to everybody, without considering their use case, without considering the impact it has on the end user, "just don’t support secondary mappers", "it’s much simpler like this".

Rather the opposite, I think it should be advocated that by default, the majority of the use cases, one should just allocate from and use any slot. This provides a huge benefit to the user (being able to run software), and as someone who has been doing this (as well as convinced others to do so) in my experience it really is not more complex most of the time. As said, in general just store one more byte and do one additional call.

Then secondly, yes of course there are cases imaginable where you need to have more control. If your code exceeds 64K you may want to allocate the additional code segments in the primary mapper so you can do inter-segment calls. If a line split ISR must be able to switch page 2 really quick you may want to ensure all data accessed in page 2 is allocated in the same slot. With complex requirements comes code complexity, that is only natural.

However those are all exceptional cases, and you won’t typically encounter this complexity. The DOS2 mapper routines are nice in that they provide sufficient flexibility to let you do this, exactly for this reason ALL_SEG has several parameters, exactly for this reason ENASLT is not built-in PUT_PH! To give you the flexibility and extreme performance when you need it. The DOS2 developers could’ve simplified the API if they just transparently handled secondary mappers behind the scenes, but they didn’t for the sake of flexibility. But this flexibility shouldn’t be abused to not support user’s configurations if there’s no real good reason for it.

By Grauw

Ascended (10013)

Grauw's picture

14-02-2019, 15:24

Let’s put it like this, if I didn’t support secondary mappers in VGMPlay I would’ve made a lot of users unhappy, not the least of all turboR users. Whereas it took me very little time to support it, it was no hassle at all. So I want to convey this sentiment to others.

Being able to extend your memory with just a cartridge to suit software with larger software memory requirements is an awesome MSX feature.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

14-02-2019, 15:28

Even if you put the code on primary mapper, if it is at the same page (and for that is inter-segment) you couldn't call it if you have selected another slot on that page. Typical case when you execute code on page 1 that inter-segment calling code over the same page 1, because the function, and the inter-segment called function, are handling data on page 2 (used for data storage). So auxiliary functions (those parts of code large used by some others) change a lot.

I understand what you say, one could simply define a "first free segment" allocation policy, and run, then it will execute on each computer as it could.

But, what I say is that I see more worth to focus on the primary and design for that, what it can gives to software design. The sharing page mentioned before is one of them. So I am more interested in getting advantage of modern viable hardware than trying it to run on outdated hardware (even on MSX) sacrificing some of the design concepts for that.

So, in the case of special very consuming RAM software (maybe some kind of enterprise software), you could prefer to go for that way. But looking at modern hardware, while your software does not require more than 256KB, for me it is better to focus the design on the primary.

By Grauw

Ascended (10013)

Grauw's picture

14-02-2019, 15:36

DarkSchneider wrote:

So, in the case of special very consuming RAM software (maybe some kind of enterprise software), you could prefer to go for that way. But looking at modern hardware, while your software does not require more than 256KB, for me it is better to focus the design on the primary.

That is basically what I meant to say earlier:

Grauw wrote:

(That said, if your software only requires 128K of mapped memory, I think it is acceptable to only allocate from the primary mapper, since I can’t imagine a configuration where you would have enough total RAM and not have at least that much in the primary mapper. Nobody ever made 64K mapper cartridges, and the ST’s internal mapper is large enough as well.)

I said 128K here because of the 256K available in the turboR ST, 32K goes to DOS2, and 64K by DRAM mode (not sure if this is enabled by default?). I think COMMAND2.44 also takes a 16K segment? Either way, practically speaking, as long as the turboR ST does not get into trouble, I think it’s okay to allocate only from the primary mapper. Since it picks the largest mapper on other systems, and there are no mappers smaller than 256K, there won’t be any users hurt by this.

But if more memory is needed then one really should just take the small effort to deal with memory from different slots. It is not nice to tell ST users that their computer is useless because they didn’t expand the internal memory (harming the original state), while it is really just due to lazy programming.

So I guess we are agreeing on that? Smile

By RetroTechie

Paragon (1563)

RetroTechie's picture

14-02-2019, 18:34

Grauw wrote:

The only gotcha is disk transfer, which is unfortunate (and I don’t know why), but if that’s the only thing you need to deal with it’s easily worked around.

There is a technical reason: to simplify disk I/O driver software (the ROM stuff built into floppy & flash interfaces). Iirc I read that once in some obscure disk driver development docs, don't remember where exactly.

Under DOS1, a floppy driver needs to make whatever transfer is requested. When eg. disk I/O is in 4000-7FFFh area, that can't work directly since during transfers the disk interface's ROM is paged in there. So disk drivers use helper routines, that temporarily page the diskROM slot in 8000-BFFFh area (only containing a mirror of FDC registers), page the 'target RAM' into 4000-7FFFh, do the FDC <-> RAM transfer, and restore things afterwards. Some old diskROMs may do such transfers through a C000-FFFFh buffer area (copying data sector by sector), which is reaaallly slow.

If the same request is made under DOS2, DOS2 will work out what mapper RAM segment is paged into 4000-7FFFh area, page that segment into 8000-BFFFh, and call the disk driver with the target address in 8000-FFFFh range. So a disk driver that only needs to support DOS2, should only see transfer requests to/from page 2 & 3 area (dunno about page 0), can do away with all that code re-locating and slot-switching trickery, and thus be much simpler.

The above is only guaranteed to work if a) the target RAM is a mapper, and b) that mapper is the same mapper as used in page 2 and/or 3 (otherwise you'd have to do additional slot-switching in 8000-BFFFh area).

Thus DOS2's preference for sticking to one 'primary' mapper for disk I/O. Basically a performance optimization to make the common case faster & easier. The only thing that complicates or slows things down, is when a disk sector overlaps a page (1) boundary. Which again is DOS2's, not the disk driver's problem.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

15-02-2019, 08:35

Grauw wrote:

It is not nice to tell ST users that their computer is useless

Page 2/2
1 |