Oh, I wasn’t planning on going anywhere, I didn’t mean to imply anywhere that I would, sorry if you got that impression.
You did not understand what I mean. If the status registers should have been on all MSXs from the second generation with all the bits active in standard. Manufacturers would not have made mapper with readable registers so the cost of their RAM expansions would have been reduced. And if the standard had clearly specified that the registers must store the last value entered and be readable, this would have simplified the task of the programmers. It's just an observation.
I understood that , but why do you say they should have been readable with all the 8 bits? The value can simply be mirrored in RAM. This is how every megaROM mapper works as well as many other write-only registers on MSX. There is no reason to require MSX2 computers to implement four readable 8-bit mapper registers, this just increases the baseline cost of every MSX2 computer unnecessarily.
Readable mapper registers offer no practical benefit I think, the CPU cycle cost of storing a mirror value is extremely minimal and I find it hard to imagine applications where this would matter. And you still need mapper support routines, they’re needed to facilitate allocation, also accessing hardware through a BIOS is the usual method on MSX. (I fully agree that not including the mapper support routines in the MSX2 BIOS, and thus not having RAM mirrors defined for the mappers, was a big omission.)
If you do not have a standardized bios support for ram mappers (able to return the status of the mapper from a ram copy of its registers) , then you need to read their value from their ports.
then you need to read their value from their ports.
Why would you need to? The mapper pages are assigned 3-2-1-0 so the initial state can be assumed, and the running program can keep its own mirrors when it changes them. Any MegaROM game does exactly the same thing.
There is no need to read, and doing it will make the software not interoperable on several real existing MSX configurations which are perfectly fine standards compliant machines (e.g. consider the Panasonic MSX2+ series vs. badly written software). It should not be endorsed in any situation.
The standardised BIOS was introduced with MSX-DOS2 (rather than a specific MSX generation), this should be used if possible and allows sharing the memory with other processes like RAM disks and TSRs. Direct access is a fallback (e.g. for a disk game), in which case you can always assume the default initial state and exclusive access, because there is no allocation mechanism which would allow several programs to peacefully live side-by-side anyway.
the default setup is no help when he really needs the mapper
it is this
;DOS2 mapper mirrors mirfc = 0xf2c7+0 mirfd = 0xf2c7+1 mirfe = 0xf2c7+2 mirff = 0xf2c7+3 ;first set mirror byte, then hardware, other way around is fatal set0: ld (mirfc),a out (0xfc),a ret set1: ld (mirfd),a out (0xfd),a ret set2: ld (mirfe),a out (0xfe),a ret set3: ld (mirff),a out (0xff),a ret get0: ld a,(mirfc) ret get1: ld a,(mirfd) ret get2: ld a,(mirfe) ret get3: ld a,(mirff) ret in an interrupt. "of course save a register before usage". call get2 ;save push af ld a,(my tiles bank) call set2 la la la otir la la la pop af call set2 ;restore at initialization set all pages. to set the mirror variables consistent with hardware: ld a,0 call set3 ld a,1 call set2 ld a,2 call set1 ld a,3 call set0 ret the program counter should not be in the RAM pages 0,1,2 . for reasons of MSX1 initialization.
Sure, you could even explicitly set the mapper pages to the initial state if you’d want to… But non-initializing mappers on MSX1 computers are pretty much useless. Even if it manages to boot into DOS or Basic it’s mostly luck, if you load a program that’s larger than a few kB you will overwrite the system area and mess things up badly. I don’t think it’s a case that needs to be supported.
(And either way it’s not related to the topic of readable mapper registers.)
about the wiki, there is a problem with different genres that you tried to bring together, but dont go together!
grauw has dragged the discussion to modern programming, while gdx was actualy working on a history text.
and that history text can not be modded to proper programming, because that would mean to throw it into trashcan. but one could need it, as a doc for use together with old software.
but then it could need some TAGGING. "this is history".
It’s not about modern programming. I have no problem with documenting what is the reality either. However I do have a problem with:
1. Presenting something which was never part of history as a historical fact.
That distinction about internal and external mappers vs. read-back is a modern theory. It is never mentioned in official documentation, and I also don’t recall ever reading this in magazines or other texts of the 80s, 90s or 00s. The first time I read about it is in some forum discussions here where people theorized about underlying reasons for some parts of MSX which seemed less than ideal.
2. Not making it extremely clear that mapper registers should not be read.
Even when I started assembly programming in the 90s I already knew that reading mapper registers is bad, this was mentioned in several magazines and documentation texts (which were my main source of information back then), so this is not “modern” knowledge. Apparently not everyone did know back then though, as a result some badly written 128K European software does not run on all machines. But nowadays there is no excuse to make the same mistake. When a description talks about the read-back, it should tell the full (messy) picture, and be really clear that read-back can not be relied upon.
@gdx I see you already changed the text to something I’m more happy with . I made some improvements, improving the phrasing, adding some more details, and also adding a more explicit warning to the reader about interoperability before describing the details.
Edit: I noticed the information was repeated in the read-back section. I made the note in the I/O ports section really short, and refer to the read-back section which I expanded.
I understood that Smile, but why do you say they should have been readable with all the 8 bits? The value can simply be mirrored in RAM.
Readable mapper registers offer no practical benefit I think, the CPU cycle cost of storing a mirror value is extremely minimal and I find it hard to imagine applications where this would matter.
You forget the slots! When changing the slot that contains stored values, them are no longer readable, same with the mapper segments. It is best to have these values always available to handle RAM. We have the same problem with the secondary slots! And that is a problem for many programmers, you can not say the opposite. About the cost, adding a few readable bits (since all MSXs having a Mapper already have readable ports) is insignificant in relation to the total cost of the machine. This derisory cost brings a real advantage (accesses to RAM faster and easier, and expansion RAM cheaper).
The whole design of the memory management is the most critical aspect of msx systems.
Bios and ram copies of read only registers + slot and ram mapped subs lots = eternal doom and desperation
I often wonder about how happier would have been the life for programmers if they had chosen to put on readable ports all slot and mapper registers, anyway things have been done in different ways...