Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#220 io-base configuration for the MemoryMapper

SD Snatcher

This feature request is a subset of the RFE #3209252: Acid2Test

Currently, the memory-mapper I/O address is hardcoded and cannot be changed. It simply ignores the <io base> tag on the hardwareconfig.xml file. It would be a needed for the Acid2Test that the MemoryMapper I/O address could be configured, like this example shows:

<MemoryMapper id="Main RAM">
<mem base="0x0000" size="0x10000"/>
<io base="0xFC" num="4" type="O"/>
<io base="0xFC" num="4" type="I"/>


1 2 > >> (Page 1 of 2)
  • The hardcoded I/O addresses are in MSXMotherBoardImpl::createMapperIO(). The purpose of that method is to have only one MapperIO instance per machine, to make sure that if multiple mappers are present, they all switch on one I/O port write.

    Inside MapperIO itself we assume that the mappers are aligned on a multiple-of-four port number. I think that is an acceptable restriction. In any case, many other devices also have such restrictions.

    One way to allow different I/O addresses would be to explicitly add support for that in MSXMotherBoard, by keeping a MapperIO object per 4-ports block (NULL for most entries).

    Another approach would be to get rid of MapperIO and use a generic I/O (de)multiplexer when multiple devices share the same port. We must have something like that already to support for example an FM-PAC in a machine that has MSX-MUSIC internal, but I don't know the details. One complication is that some MSX engine models (like the one in the turbo R) only support reading 5 mapper bits instead of 8. That is also handled in MapperIO at the moment, so it would have to be implemented differently if we want to drop MapperIO.

  • Memory Mapper I/O ports are specified by the MSX standard. Having them in another location is a violation of the MSX standard. BACK TO SCHOOL, FRS!

  • SD Snatcher
    SD Snatcher

    Hi Patriek,

    Please hond on the torches. I believe we're all friends on a hobby we like: The MSX system. It just doesn't make any sense to get into some fight, because the meaning of a hobby is having fun.

    That said, please let me try to clarify some points:

    1) Please note that I did made my research before making the proposal. And I came to ask the features for openMSX team in good faith, for something I believe that can help our small community. It all began when I noticed on the MRC forums that our developers are having a lot of compatibility issues when releasing their software, and then I researched and proposed some drafts to help MSX developers to stress-test their software more effectively without having to spend too much resources (such as buying a lot of different MSX machines and extensions, then trying every combination).

    2) The MSX Technical Handbook clearly states that all I/O ports are specified on the MSX standard just as a reference. I quote page-42, "Notes on I/O Address Assignments", which states that: "Although I/O addresses are defined above, the software must not access those devices directly using the above ports. All I/O accesses must be done using BIOS calls, in order to make the software independent of hardware differences. MSX manufacturers may change some of the hardware from the standard MSX system and maintain software compatibility by rewriting BIOS. The hardware differences would thus be trans­parent to the software."

    The important part if the quote above is that MSX manufactures *may change the hardware* and rewrite the BIOS to keep compatibility. This leads us to the following corollary:

    Corollary-2a) The MemoryMapper is part of the MSX system. User software should never access its I/O ports directly. Thus, manufacturers may change the MemoryMapper I/O ports and rewrite the BIOS to keep compatibility.

    3) Wisely, openMSX was built strictly following the the recommendation quoted on (2). Unlike other emulators with hardcored I/O ports for everything, openMSX allows any device to be easily assigned to a different I/O port just by modifying the hardwareconfig.xml file. This is a level compliance to the MSX standard that I'd never seen before, since for others it's much easier to hardcode everything and proclaim that "no other real MSX machine ever used different ports".

    4) Apart from this flexibility for nearly all devices, unfortunately the MemoryMapper and the expanded-slot-registers are still some of the very few devices that do have hardcoded addresses. I'm just asking for the MemoryMapper and expanded-slot-registers to follow this same wonderful flexible design.

    5) Is having I/O ports defined by the MSX standard a factor that impedes the respective device to be configured on the hardwareconfig.xml file? If so, why the PSG and PPI ports can be configured? Shouldn't they be hardcoded as well? Don't get me wrong: I think the current flexibility is great!

  • 1) MRC sucks
    2) Show me the MSX-BIOS routines that deal with the MSX Memory Mapper.
    2a) Circular illogic.
    3) yawn
    4) RTFM
    5) Read the MSX standard again.

  • SD Snatcher
    SD Snatcher

    1) Allow me do disagree. I think they're an important place where the MSX community likes to exchange news and ideas

    2) "BIOS" isn't restricted to the MainBIOS, you know. The standard was designed in a way that every extension device has it's own BIOS. There's the DiskBIOS, the RS-232C BIOS, the MBIOS, the FM BIOS and so on. The MainBIOS makes use of the MemoryMapper I/O ports, and the MemoryMapper interface is exposed by the DiskBIOS v2 (aka MSX-DOS 2). You can use this documentation as a reference:

    2a) Are you sure of that too? The real Circular Logic would be "The MemoryMapper is part of the MSX-System because it has defined I/O ports. The fact that the MemoryMapper has defined I/O ports is because it is part of the MSX-System"

    Here are the definitions of Corollary and Circular Logic, as a reference:

    3) If you don't like openMSX, what are you trying to accomplish here?

    4) Be more specific. What part of what TFM are you referring to, so one an build an solid argument? If you can't specify that, you'll just be making yourself a fool in public. I certainly hope that's not the case, as there's a very big public on the Internet, you know.

    5) See (4) and it also seems that didn't take the MSX Technical Handbook quote into consideration.

  • If you're gonna put words in my mouth I'm done with this discussion. You seem to have problems with reading comprehension.
    With every message you are showing poor understanding of the MSX standard...

  • SD Snatcher
    SD Snatcher


    What part of "MRC sucks" or "yawn" could I have comprehended better?

    You're still making personal attacks without proving your point... If I "have a poor understanding of the MSX standard" as you say, please prove yourself. I'll be glad to converge to a common conclusion.

    How are you so sure that isn't your point of view that is based on idiosyncrasies and personal beliefs? Is your opinion immutable or are you open to discuss ideas?

  • Let's be pragmatic about this request. This test has little practical value (to use Maarten's terminology, this is definately a category B test). Before there was DOS2 I don't know of any standard to access the memory mapper (there was memman, but this wasn't really a standard). So many MSX programs really have no other choice than to access the mapper IO ports themselves. Also ALL existing memory mappers use the same IO ports.

    In general I agree with making stuff configurable in in the hardwareconfig.xml files. But in this case (and this is mostly an internal openMSX implementation detail) this is more difficult because different memory mappers in a single MSX machine don't work completely independent (when reading the IO ports, the different memory mapper implementations 'somehow' have to communicate to 'emulate' the bus conflict).

    Because of these two reasons (little practical value and not trivial to implement in the current openMSX structure). I'm lowering the priority of this request. FRS, if you don't mind i'd even like to close this request. Can you do that if you agree?

    What _would_ be useful is a test on reads from memory-mapper ports. These will in practice often go wrong when there are multiple memory mappers (of different sizes) or on turbor machines with an external memory mapper bigger than 512kB.

    • priority: 5 --> 2
  • SD Snatcher
    SD Snatcher

    • priority: 2 --> 5
1 2 > >> (Page 1 of 2)