Jon De Schrijder <[EMAIL PROTECTED]> wrote:
> Can you all agree with the following?
> It is important for both MSX software- and hardware-developers that we
> all can come to an agreement.
> Probably there are still memorymappers procuded nowadays and also
> software depending on these.
>
> Go get some coffee (don't spill on the keyboard ;) ) and read:
>
> *memorymapped RAM is optional for MSX2
It is.
> *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...
> >Here i have the msx technical databook , micro$oft 5 feb. 1986 rel.6.0
> >It says on MSX2 memory mapper specification chapter 1 line 4
> >
> >- The mapping registers are at FCH to FFH of I/O address. The are both
> >read and write addresses. -
Some read that as: mapper registers can be written to, and should be
able to read back as well.
I read the above as: you can write to mapper registers, and you can
read back from the same I/O ports. But that doesn't say you can
assume to get back something usefull.
> *There can be more than one memorymapper in an MSX2 or higher.
> even if it was not meant to be that way, we all know that there are no
> real big technical problems related to it and that the advantage is
> enourmous.
Practice shows it...
> *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.
> *When powering up the system, the bios should initialize the mapperports
> by writing the apropriate values to it.
No need to "should" this, the BIOS does it already.
> *Mapperports may be read. However, the returned information is limited
> (see below)
>
> *The read-out mechanism of a mapper should comply with the the
> following: when reading a mapperport the last written BITS should be
> returned. So only the bits that were actually stored when the mapperport
> was written, should be outputted on the databus. The other bits of the
> databus should remain in a high-impedance state.
>
> As a result of this the following things are true:
> -There occur no short-circuits on the databus; or a databit is not
> controlled at all (high-imped) or it is controlled by one or more
> mappers at the same time; in that case all mappers return the same
> databit (the databit that they stored when the mapperport was written)
> (Note also the fact that it is no problem when there exists a small
> delay between the several mappers when outputting their data, because
> the 'slow' outputs will still be in a high-impedance state and will not
> affect the 'fast' outputs.)
This would be the desired behaviour of mapper registers.
> -It is possible that databits not controlled by any mapper return random
> bits. There is no reason to assume these bits to be 1 or 0.
Agree. Assume as little as possible!
> -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).
> -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.
> -You can obtain the paging state of all memory mappers just by reading
> the mapperport(s). However in most cases you have to mask some upper
> bits depending on the detected size of the largest mapper.
>
> +++As far as I know, there are no official MSX products violating the
> rules above.+++
I'm not sure. But you wrote a good guideline here. They should have
written something like this in the MSX2 spec's.
> But then there was the HORRIBLE S1990 engine used in some MSX computers
> (Turbo-R and some 2+ models I think) :(((((( And this, ladies and
> gentlemen, screws up the whole story above!
It's not the S1990 engine that does it. That's a Turbo-R specific IC.
The 'bad guy' here is the T9769 MSX2+ engine, used in Turbo-R as
co-engine, and as main part in many Japanese-built MSX2+ machines
(Sanyo Wavy, Panasonic FS-A1W(S)X and others). This IC includes the
Z80, memory mapper, slot control, keyboard control, clockchip etc.
> In these computers bit 5, 6 and 7 are always read back as 1; no matter
> if there is a large memorymapper present that uses bit 5, 6 or 7 to
> store mapperbits. Even worse: connecting such big mapper and writing 0
> to those bits is no problem, but when reading the bits there occurs a
> short-circuit. (5V from S1990 and 0V from the mapper read-back system)
> Nevertheless as far as I know this hardware problem is not that worse.
Short-circuits with limited currents, and very small part of total
time.
I consider the above a true design error, but could imagine why this
might have been done: maybe the idea was that: a) there wouldn't be
any mappers >512K used on these machines, and b) most likely, such a
mapper up to 512K would be the internal one.
Shortsighted ofcourse, but hey, all humans can make mistakes...!!
BTW: It is possible to 'overpower' the internal mapper-readback, and
thus avoid the software problems. In contrast to what some say, this
is not likely to cause permanent damage: there occur short-circuits,
but limited, and very short duration.
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).
If (without memory management) a program ends with the mapper set
differently from the default setting, you can call that a bug.
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.
This will work in 99% of all cases. If that still doesn't work: too
bad.
For hardware builders:
------------------------------
Try to include read-back for the mapper registers. Preferably don't
use more bits than is needed for your mapper. And if read back, don't
control any bits that can't also be written on your mapper.
> 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?
With the above software recommendations, it would work fine: using
DOS2 mapper support, using MemMan, for any normal program (yep, my
R-Type crack works fine with this mapper as well ;-), only
troubles with TSR's that don't support any type of memory management.
Although I don't think there are a lot of mappers like this
around....
> 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.
> 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.
Suppose you would build a new type of mapper, that is controlled by
memory-mapped I/O, rather than I/O ports FC-FFh, or uses a different
set of I/O ports.
When all programs would support the DOS2 mapper routines, you could
slightly modify these mapper support routines, and all programs would
support the new mapper type just like that.
That separates applications using a mapper, from the mapper hardware
itself. Isn't that a good thing?
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 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?
You might even include this in a add-on ROM, so that a non-DOS2 using
machine could have mapper support, right after power-on.
Or: modify a DOS2 ROM, so that you could use its mapper support,
without DOS2 file system.
The unavoidable question: who's gonna do this?
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page
****
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/)
****
