Hi all,
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
*The size of a memorymapper is at least 64kB (four pages of 16kB)
>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. -
*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.
*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)
*When powering up the system, the bios should initialize the mapperports
by writing the apropriate values to it.
*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.)
-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.
-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)
-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.
-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.+++
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!
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.
The worst problem is the software problem: like stated above: the
read-back value returned from a large mapper (>=1024kB) is not correct.
This means it is not possible to know which mapperblock is paged in.
This information is vital for all kinds of purposes (TSRs, ...)
Lucky for us, there is a work-around: when writing to a mapperport, also
store a backup of the value in RAM. This feature is supported by DOS2,
but it isn't by DOS1.
-->when using DOS2, use the backup values in RAM (all problems gone)
-->when using DOS1 and *your* program modifies the mapperstate: make
your own backups in RAM. You will have to initialize these backups at
the beginning of your program (see below)
-->when using DOS1 and you want to know in which state *another* program
has set the mapper (applies only for TSR's): only one solution: just
read the mapperports. This will work 100% for non-S1990 computers and it
will work 100% for S1990-computers with mappers <1024kB.
About initializing your own backups in DOS1: I think the mapperstate is
always 3, 2, 1 and 0 when you start your own program from BASIC or from
MSX-DOS. But perhaps there were some 'shell programs' created, letting
you return in BASIC or MSX-DOS with another paging state than those
3,2,1,0. The question to you all is: should we take this into account or
can we assume 3210 right away. An intermediate solution: read the
mapperports (reading bit 0 and 1 should be no problem) and see if these
are 3210; if so, there is a big chance the mapper state is indeed 3210
and otherwise generate an error or performs some complex algorithm to
see if you are working on a S1990 machine (could be as follows:
determine size of the largest mapper you want to use, if <1024kB, no
problems; if >=1024kB: write 0 to bit 5 of a mapperport and read back:
if it is 1 you are working on a S1990 machine)
Another issue: are there many mappers around with a read-back system not
complying with the rules above? All mappers I know of are ok. Some of
you were talking about mappers with inverted output, no output at all,
... but have you actually seen such devices? Today it seems such devices
are not obeying the MSX rules because they are not supporting read-back.
If there are not too many, we can just ignore them. But if there are a
lot on the market, we can make the above algorithm for determining the
initial mapperstate in DOS1 a bit more complex: first check if the
mapper supports read-back, if so; do as above, if not assume 3210.
Checking whether a mapper supports read-back can be tested by writing
datapatterns to bit 0 and 1 and see if they can be read-back.
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.
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)
My conclusion:
*for people making a memorymapper: best thing to do is to provide
read-back as descrived above.
*for programmers: read only the mapperregisters in some special cases
When you all agree, it is important that hardware/software developpers
take notice of this.
Spread the word around...
jon
****
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/)
****
