On Mon, 29 Mar 1999, shevek wrote:
> On Sat, 27 Mar 1999, Maarten ter Huurne wrote:
>
> > Besides, what kind of program would leave the mapper in a different state
> > than when it was started?
>
> I am busy on a muli-tasking system that cuts programs off on the
> interrupt. It is very well possible that one program sets the mappers is
> some state and when an other program is called, it's memory-status will be
> saved. Therefor I need a way to read all settings:slots, subslots and
> mappers.
Like said before: for this kind of TSR things in DOS1 without Memman you
really have to read mapperports! (and I think that you have to read
mapperports when using Memman too, because MemMan will probably just
return a mapperport value that was last written to the mapper by MemMan;
so if an 'old' dos1 program does its own mapperswitching, MemMan won't
detect this (unless Memman uses itself mapper read-back))
About your other mail (sorry, I can't cut/paste here; using a simple
stoneage terminal, perhaps running on a Z80 :) )
you said to leave the mapper-read back mechanism 'undefined'; I don't
agree with it, since mapper-read-back is necessary for the TSR stuff. Also
all official mappers support read-back.
The cost/design of the read-back mechanism is almost zero (two extra
74LS670 ic's if I'm correct)
About the minimum of 64kB size: that is defined by ASCII with the picture
of the 'optional' mapper (64kB at least and the rest optional)
About the unused bits you stated: 'these are pulled up by MSX databus',
well this is true for a lot of computers, but not for all of them.
++++
This brings me to a new problem we didn't observe yet: when a mapper is in
a slotexpander and the mapperports are read: if unused bits are high-imped
and cause a zero on the bus by accident, this zero is actively put on the
MSX databus by the buffers of the slotexpander! This can cause a
short-circuit with a larger mapper that want to return a 1 on the bus.
Same story if a random 1 is created and put actively on the MSX bus when a
larger mapper want to return 0 on the bus
Because of this the readback of the bits 'in conflict' may be wrong. Some
TSR stuff won't work.
Solutions: use 8-bit registers to store the mappervalues, even if the
mapper is smaller than 4MB. (most of the time this will not be a big
problem because a lot of mappers use already 5 bits and have still 3
unused bits on the 74LS670 chips)
Note: slotexpanders not having a buffer between the expansion slots and
the msx bus, don't have this problem of course.
So, the perfect mapper:
*stores the complete 8bit values that were written to its ports
*provides read-back for the whole 8bit value
*is at least 64kB
*has all useable RAM in consecutive mapperblocks: 0,1,2,3,4,...,
Such mapper(s) will work in all cases witthout problems, except on
computers with the engine-problem. Here the read-back won't be correct in
some cases.
Greetz,
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/)
****
