On Sun, 28 Mar 1999, Alwin Henseler wrote:
>
> Jon De Schrijder <[EMAIL PROTECTED]> wrote:
> ...
>
> > *The size of a memorymapper is at least 64kB (four pages of 16kB)
>
> Makes sense. At least I've never seen, or built anything smaller...
see the ASCII specs in which a memorymapper is displayed as 'optional',
but it is at least shown as 64kB.
> > *Mapperports are of course writeable. It is not required for the mapper
> > to store all written bits. Storing more bits than are actually used by
> > the mapper is not illegal. (see the Philips MSX with 4 bit-mapper and
> > only 64kB RAM connected)
>
> Ehh, that's 3 bits for that Philips machine...
> For the rest: agree.
oops, sorry, 3 of course.
> > -Since all valid memory mappers contains at least 4 mapperblocks, at
> > least 2 bits are used for the mapperports. When writing data to a
> > mapperport, the two least significant bits can always be read back.
> > (useful to check if there is a memory mapper present in the system)
>
> I disagree (see below).
when all mappers support read-back, this should be no problem; however,
most programs that want to know if there is a mapper present, also want to
know the size of the mapper (with the RAMtest algorithm). So checking the
presence of a mapper by reading the ports is a bit obsolete.
> > -You can not determine the size of the mapper by just reading the
> > mapperports; you'll have to write different values to the mapperport(s)
> > and check for RAM.
>
> Absolutely.
Here we need to establish some extra rules; is the following allowed for a
mapper?
4-bit 128kB mapper:
0,1,2,3=ram
4,5,6,7=nothing (no ram, databus high-imped)
8,9,a,b=ram (other memory than blocks 0,1,2,3)
c,d,e,f=nothing
I think we should not allow such mapperconstructions (we can allow them,
but programs that can't detect the ram of 8,9,a,b should not be considered
as faulty) The reason to not allow such 'things' is to make life easier
for programmers. (otherwise you have to make tables of each mapper with
all valid mapperblocks)
I don't think such mappers exist today.
--> message for hardware designers: don't make such mappers.
all agree?
> About the software problems:
> -----------------------------------------
> I would suggest the following, separating normal programs, and
> resident software (drivers, TSR's, replayers etc):
>
> For normal programs:
> If there exists mapper support routines or MemMan: use it if
> possible.
> With no memory management (DOS1, and no MemMan loaded): assume
> default mapperblocks setting (3, 2, 1, 0 for pages 0-3).
I agree with the assumption of blocks 3210
>
> If (without memory management) a program ends with the mapper set
> differently from the default setting, you can call that a bug.
agree, so in that case it shall always end with 3210. (and to be more
precise: a program not altering the mapper, is not obligated to actively
setting the mapperports to 3210)
>
> For software that has to work together with other programs (TSR's,
> drivers, etc.): USE MEMORY-MANAGEMENT !!!
>
> Try to support DOS2 mapper routines. If not present, you could bring
> in your own memory manager (MemMan).
>
> If for some reason you have to work without DOS2 mapper routines, AND
> without MemMan:
> Then you have to read the mapper ports. Treat the value returned as a
> full 8-bit number. The mechanism with multiple mappers as described
> above, will return the value of the mapper controlling the largest
> number of bits. Higher bits are don't cares, and you don't even need
> to know how many bits are controlled.
that will do in most cases, but if you want to compare blocknumbers you
should mask the upper bits to obtain the correct blocknumber. (because
unused bits can return random bits) This can easily be done when you know
the size(number of bits used) by the largest mapper present in the system.
> This will work in 99% of all cases. If that still doesn't work: too
> bad.
agree
>
>
> For hardware builders:
> ------------------------------
> Try to include read-back for the mapper registers.
this should be really mandatory
> Preferably don't
> use more bits than is needed for your mapper.
not really necessary, but do it if you can. (some bad-programmed programs
rely on this)
> And if read back, don't
> control any bits that can't also be written on your mapper.
is the most important thing (necessary to avoid short-circuits with other
mappers)
> > Another issue: are there many mappers around with a read-back system not
> > complying with the rules above?
>
> In a home-built mapper I have, I left out the read-back for ease of
> construction, and to see what troubles this might give.
> You can run megaROMs on it as with any other mapper, DOS2 uses it
> just fine, MemMan uses it just fine. In a 2+, the memory count counts
> the correct size. And, if you select blocks 0-15 (it's a 256K
> mapper), you GET blocks 0-15.
>
> In other words: consider this a perfectly normal working mapper, even
> if its mapper registers can't be read back. You want to throw the use
> of this mapper away, simply because you can't handle write-only
> mapper registers?
Nobody can prevent you from using it, but if a program doesn't work when
it must rely on the mapper read-back because there is no other
alternative, you should not shoot at the programmer.
>
> > Last issue: the mapperports in DOS2 environment are backed up in RAM at
> > address #F2C7/8/9/A. In theory one should use the GET_Pn functions to
> > read these values. This has some disadvantages: it is slow (1 CALL/RET
> > and two JPs extra), it possible that there are no 'mapper support
> > routines' present in DOS2; so also no GET_Pn routine.
>
> Slow? Using these, a single OUT (xx),A would be replaced with
> something like:
>
> CALL PUT_Pn
>
> PUT_Pn:
> JP yyyy
>
> yyyy:
> LD (zzzz),A
> OUT (xx),A
> RET
>
> Slow? Like this, you can do a blockswitch ten-thousands of times each
> second. If that isn't enough, then don't complain about it, but write
> your program more efficient.
You should also take into account that the GET_Pn address has to be filled
in in all your CALL instructions, or you can use an extra JP and call that
JP. To be short: it would be much easier for programmers.
> > Can someone give a good reason why one should *not* use the F2C7/8/9/A
> > contents directly? (It won't be a problem to keep these addresses when
> > creating a DOS3 in future)
>
> There is one special use: the possibility to change mapper hardware
> without having programs stop working.
hmm... I don't think that a MSX3,... will ever use other ports for
memoryswitching. So I don't agree with that point. So my conclusion: there
is no reason why you should not use F2C7/8/9/A directly.
>
> That separates applications using a mapper, from the mapper hardware
> itself. Isn't that a good thing?
no, because these ports are defined in MSX standard.
It is just like with FFFF
>
>
> Maarten ter Huurne <[EMAIL PROTECTED]> suggested:
>
> > What if someone writes a mapper support driver for DOS1?
> > Shouldn't be too hard. Programs could even install such a driver
> > themselves so that they can switch the mapper using a single
> > interface.
>
> That would be perfect!
I rather prefer to install the DOS2 memory mapper support routines in DOS1
environment. That would be very easy for programmers.
>
> I think that DOS2 and its mapper support are essentially 2 separate
> things. Although I'm not sure if DOS2 itself could work without its
> built-in mapper support. But the other way round: why not?
I think that should be possible.
>
> The unavoidable question: who's gonna do this?
not me; too busy with other (MSX) things
CU
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
