At 04:23 AM 03/27/99 +0100, you wrote:
>Can you all agree with the following?
>
>*Mapperports may be read. However, the returned information is limited
>(see below)
I'd say: only read mapper ports if there is absolutely no other way your
program could function.
>*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.
You say: "should". But do existing mappers comply to this demand?
>-->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.
Writing such a TSR is dangerous stuff anyway. There is no guarantee that
the non-TSR program using the mapper won't overwrite the page the TSR is
in. So if you're writing TSRs, I strongly suggest using DOS2 or MemMan.
>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.
DOS1 doesn't use the mapper, so the state the BIOS set will still be there.
>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;
Just assume it's 3210. Writing programs is enough work already, adding
complex mapper init routines is not something programmers are looking
forward too.
Besides, what kind of program would leave the mapper in a different state
than when it was started?
>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),
Only a problem is you do _very_ frequent page switching.
>it possible that there are no 'mapper support
>routines' present in DOS2; so also no GET_Pn routine.
Is there any DOS2 without mapper support?
There may be even DOS1 machines with mapper support...
>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 may be a machine out there that stores the page numbers somewhere
else. I haven't seen one yet though.
I have a little idea:
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.
Bye,
Maarten
****
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/)
****
