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.
Surely you would store the mapper mirrors in page 3, and surely you’re not swapping out page 3... That’s a recipe for problems of all sorts. Also I don’t know how slots are relevant for mapper readback, yes they’re overly complex but it’s dragging an unrelated topic into the discussion about readback.
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).
So I have a problem with the statement "accesses to RAM faster and easier". We’re talking about the difference between:
ld (Mapper_MIRROR_8000),a out (FEH),a ... ld a,(Mapper_MIRROR_8000)
And:
out (0FEH),a ... in a,(0FEH)
I can not for the life of me imagine any case where you would need to so frequently switch between RAM banks that these 16 cycles would matter. And if there were a use case for it, any kind of performant code would do block memory access anyway, to avoid the switching cost for every byte processed entirely.
Note that the above example is the same as:
ld (ROMMapper_MIRROR_8000),a ld (7000H),a ... ld a,(ROMMapper_MIRROR_8000)
Or:
ld (RG9SAV),a out (99H),a ld a,9 | 128 out (99H),a ... ld a,(RG9SAV)
Mirroring of write-only registers is easy and we do it all the time.
Anyway, I guess it’s really no use to talk about what could’ve been.
I was thinking, it is said that the T9769 MSX-Engine (used in e.g. Panasonic MSX2+/turboR computers) blocks the reading of the external mapper port.
It could indeed first decode the address, and only then decide to pass on the data if it’s not internal. I suppose it could be done to protect the MSX-Engine from short-circuiting due to bus conflicts on reads. Having 8 ternary gates for those data lines seems mostly just unnecessary extra logic though (=cost).
Another possibility is that where most internal mappers return hi-z for the unsupported bits (floating), allowing external mappers to control them, the T9769 MSX-Engine explicitly returns 1 for those bits, and when an external mapper returns different values a bus conflict occurs (short circuit) and the MSX-Engine simply wins out.
In the former case they have a legitimate reason to implement this blocking, the MSX-Engine is a difficult-to-replace chip after all. In the latter case reading from the mapper ports could perhaps actually risk damaging the MSX.
In the former case they have a legitimate reason to implement this blocking, the MSX-Engine is a difficult-to-replace chip after all. In the latter case reading from the mapper ports could perhaps actually risk damaging the MSX.
If so, what I saw about external and internal mappers is true. I recall that it said that only internal mappers can be readable. It also said that it was optional but all manufacturers of MSX (with mapper) put this option.
ld (Mapper_MIRROR_8000),a out (FEH),a ... ld a,(Mapper_MIRROR_8000)
And:
out (0FEH),a ... in a,(0FEH)
I can not for the life of me imagine any case where you would need to so frequently switch between RAM banks that these 16 cycles would matter. And if there were a use case for it, any kind of performant code would do block memory access anyway, to avoid the switching cost for every byte processed entirely.
The problem is not the speed... Let me give you more practical problem to think:
We are on 90's with no emulators around... I'm sitting in a poor household in Netherlands and I'm about to loan a Dutch game from a friend for the weekend, but I know it has a nasty copy protection. I know from manual it uses only 128KB memory, but I have 256KB memory, therefore I decide to make a little TSR that hooks in to disk routines, dumps the call addresses, names of the files, their block reads as well as PHYDIO usage to my printer in clear text while I play. Since I don't know what addresses are free on the first 128KB I put the TSR to last free page of the memory. The problem here is that I don't know where "Mapper_MIRROR_8000" is located or if such is used at all. It might be that the game uses fixed mapper pages all the time. Now how do I solve this problem?
If you rather think something less provocative, think ie. using DOS1 & RAM disk to load such 128KB game.
In the former case they have a legitimate reason to implement this blocking, the MSX-Engine is a difficult-to-replace chip after all. In the latter case reading from the mapper ports could perhaps actually risk damaging the MSX.
If so, what I saw about external and internal mappers is true. I recall that it said that only internal mappers can be readable. It also said that it was optional but all manufacturers of MSX (with mapper) put this option.
Not sure which of the two cases you are referring to, but I wrote the post to highlight the second theory (originally I said "more likely", although I later adjusted my words), and in that case it could actually be harmful to read. And regardless of all, as we know reading mappers is not standard, not reliable and not interoperable.
Either way I don’t really see any evidence here about the internal / external mapper theory? Really you need to find that document that you recall, so that we know what source you have, how authoritative it is and what the exact phrasing was.
The problem is not the speed... Let me give you more practical problem to think: [hacking a game]
[...]
If you rather think something less provocative, think ie. using DOS1 & RAM disk to load such 128KB game.
Both present cases where there is non-exclusive access to RAM (with a TSR of sorts). In case of non-exclusive access you MUST use mapper routines with an allocation mechanism like DOS2 has, or there is no system in place to prevent TSRs from overwriting the main program memory or vice versa.
That’s what I meant by saying in nonexclusive scenarios mapper readback is useless without BIOS allocation routines, and if you have allocation routines you don’t need readback because they can provide it for you. And in exclusive scenarios mapper readback is useless as well because you can keep mirrors yourself if you need them, so you don’t need readback either.
(Of course the hacker can make assumptions about the memory use of his specific system and the specific program he’s hacking, but that’s not something you can expect of the general end user.)
Mars, are you sure about the 128kB ram in the MB-H50N? What's your source of that information?
It is written RAM 64kB, ROM 32KB on the box.
Mars, are you sure about the 128kB ram in the MB-H50N? What's your source of that information?
Read comment 646 on this page: https://2ch.live/cache/view/i4004/1031735952
If the additional 64kB is not accessible as there is no memory mapper, then why designate it with a different type? You only want to do that if it is relevant to the user, and a hidden and inaccessible 64kB has no meaning to a user. Also, if 128kB was cheaper in 1986, why do almost all the Japanese MSX2 and every 2+ system only have 64kB?
It seems to be a very personal decision of Hitachi and NEC. Don't forget that Hitachi has never released a MSX2+ and that the last machine released by Hitachi, the MB-H70, was actually manufactured by Mitsubishi and is actually a 'simplified' ML-G30, with many features removed!