Wiki editing discussion

Page 24/38
17 | 18 | 19 | 20 | 21 | 22 | 23 | | 25 | 26 | 27 | 28 | 29

By wolf_

Ambassador_ (9734)

wolf_'s picture

15-11-2018, 22:54

Keep in mind that you can also split the article into chapters, with each chapter being a new wiki page. You could even offer multiple explanations by making articles with titles like 'Z80 registers according to gdx' and 'Z80 registers according to NYYRIKKI', and link to both of 'm in the main article. That structure could even invite more coders to vent their ideas about certain aspects of z80 asm.

By gdx

Prophet (2658)

gdx's picture

16-11-2018, 01:00

NYYRIKKI's explanation is the same as mine but in more detail (much more detailed!). In addition NYYRIKKI's English is probably more natural than mine. The difference that I note is how to name the auxiliary registers and some flags.

By NYYRIKKI

Enlighted (5252)

NYYRIKKI's picture

16-11-2018, 03:55

@gdx: Thank you for your kind words. I'm aware that I've not been very consistent naming some of the details, but as a guideline I've used the "Undocumented Z80 documented"-manual. I would not say my English is very good though. I must say that I would like to find a nice way to put these flag addresses, values, names, call signs, aliases, meanings and descriptions in some sort of a reasonable table.

@wolf_: As we are talking about digital truth, there is not really space for "ideas" or variations. The difference is that traditional documentation tends to give all the details for people, so that they can then form a "big picture" in their heads. Since this means reading out hundreds of pages of (quite a dull) documentation, that is quite an effort. What I'm trying to change here is that I want to give people the "big picture", so that they can then dig in to the details when they need to. This means that all the things that I write are not absolute facts, but I've put very much effort to avoid giving impression that they would be while they are not.

As a side note: From my personal experience one of the most destructive forces in the universe is claiming that something is a fact while it is not. When people stop trying stupid things and start accepting false facts, it stops all the creativeness in a heart beat. Therefore I feel it is our responsibility to try to avoid that.

By gdx

Prophet (2658)

gdx's picture

17-11-2018, 00:43

NYYRIKKI wrote:

Since this means reading out hundreds of pages of (quite a dull) documentation, that is quite an effort. What I'm trying to change here is that I want to give people the "big picture", so that they can then dig in to the details when they need to. This means that all the things that I write are not absolute facts, but I've put very much effort to avoid giving impression that they would be while they are not.

It is for this purpose that I created this page. Smile
It must be as simple as possible and contain only the essential.

By gdx

Prophet (2658)

gdx's picture

11-12-2018, 07:59

About status registers of Memory Mapper, what is the explanation that seems most likely to you?

  1. "About reading, only registers of the internal Mapper are meant to be readable but many cartridges implemented the reading because they were originally intended for MSX2 without Memory Mapper. Therefore if multiple Memory Mapper of different sizes are installed the read values will be wrong."
  2. "About reading, the Memory Mapper registers are readable, they indicate the current segment selected on the corresponding memory bank(s). However, almost all the Memory Mappers do not handle all bits to save components. Unused bits can be mirrors of the bits used, remain either seted or reseted depending of Mapper. This can cause conflicts in case of several extensions present. So, avoid considering the read values especially for the six most significant bits."
  3. Another. (Explain please!)

The one is the current explanation.
https://www.msx.org/wiki/Memory_Mapper

By Grauw

Enlighted (7964)

Grauw's picture

11-12-2018, 09:16

3. No speculation, and simply state that mapper registers must not be read according to the standard, backed up by the facts that some mappers can not be read, others do not read back all bits, and some computers block reading of external mapper registers. Ample reason without having to guess the underlying motivation.

I don't like 1 at all. Please quote supporting official documentation which confirms this to be true, I think this internal/external stuff is purely someone's imagination, presented as truth throughout the wiki page and spreading the myth. Fake news! Tongue

No. 2 is too soft, first saying they are readable (not always true), presenting missing bits as mapper implementations having bugs ("unhandled"), and merely recommending to "avoid" reading them (the rule should be clear: do. not. read.)

Imo, the real reason is reducing cost & bus conflicts / stress if multiple devices respond at the same time, but this is again speculation unless someone can find this mentioned in some official technical manual.

By gdx

Prophet (2658)

gdx's picture

11-12-2018, 11:07

Grauw wrote:

3. No speculation, and simply state that mapper registers must not be read according to the standard, backed up by the facts that some mappers can not be read, others do not read back all bits, and some computers block reading of external mapper registers. Ample reason without having to guess the underlying motivation.

In fact, the standard is not so precise until MSX-DOS2. The fact that some computers block reading of external mapper registers rather confirms the first explanation. This one comes from a document that I can not find anymore.

Grauw wrote:

I don't like 1 at all. Please quote supporting official documentation which confirms this to be true, I think this internal/external stuff is purely someone's imagination, presented as truth throughout the wiki page and spreading the myth. Fake news! Tongue

This does not prove anything either.

Grauw wrote:

No. 2 is too soft, first saying they are readable (not always true), presenting missing bits as mapper implementations having bugs ("unhandled"), and merely recommending to "avoid" reading them (the rule should be clear: do. not. read.)

No. 2 is a reflection on my part but you are right. The 2 least significant bits are not necessarily correct if we take into account the mappers without readable registers.

Grauw wrote:

Imo, the real reason is reducing cost & bus conflicts / stress if multiple devices respond at the same time, but this is again speculation unless someone can find this mentioned in some official technical manual.

I think the real reason is that the Memory Mapper has been poorly standardized. The status registers should have been on all MSXs from the second generation with all the bits active. This would have avoided all problems, reduced the costs of Ram expansions and simplified the programming.

By Grauw

Enlighted (7964)

Grauw's picture

11-12-2018, 17:45

gdx wrote:
Grauw wrote:

3. No speculation, and simply state that mapper registers must not be read according to the standard, backed up by the facts that some mappers can not be read, others do not read back all bits, and some computers block reading of external mapper registers. Ample reason without having to guess the underlying motivation.

In fact, the standard is not so precise until MSX-DOS2. The fact that some computers block reading of external mapper registers rather confirms the first explanation. This one comes from a document that I can not find anymore.

Doesn’t really matter when the standard became precise… Since proper BIOS mapper support routines were not introduced until MSX-DOS2 (royally late), it makes sense that this is one of the first places where it is specified very explicitly.

Additionally, the MSX Datapack appendix A.4 specifies that I/O ports FCH-FFH are write-only.

And for good measure, the TurboR Technical Handbook states that FCH-FFH should always be accessed through the (extended) BIOS.

Now unless someone can find sources of information which specify that “only registers of the internal Mapper are meant to be readable”, this claim should be removed.

gdx wrote:
Grauw wrote:

I don't like 1 at all. Please quote supporting official documentation which confirms this to be true, I think this internal/external stuff is purely someone's imagination, presented as truth throughout the wiki page and spreading the myth. Fake news! Tongue

This does not prove anything either.

I don’t think the burden of proof lies on me.

gdx wrote:
Grauw wrote:

Imo, the real reason is reducing cost & bus conflicts / stress if multiple devices respond at the same time, but this is again speculation unless someone can find this mentioned in some official technical manual.

I think the real reason is that the Memory Mapper has been poorly standardized.

That may be right, and we’re free to speculate about the underlying reasons, but my problem here is that it is presented as fact that there is some distinction between internal and external mappers, and that the former should have read-back while the latter should not. This comes from the imagination of the author and should be presented as being speculation or even better not be presented at all and remain in forum discussion threads.

gdx wrote:

The status registers should have been on all MSXs from the second generation with all the bits active. This would have avoided all problems, reduced the costs of Ram expansions and simplified the programming.

It wouldn’t have reduced the cost of RAM expansions, because readback is not needed for standards compliant software. It would have increased the cost of MSX2 computers though. A mirror can be maintained in RAM and this is what the DOS2 mapper support routines do. Wishing it was readable is the same as wishing the VDP registers were readable. A nice wish, but not the reality.

By Grauw

Enlighted (7964)

Grauw's picture

11-12-2018, 17:37

Quote:

About reading, only registers of the internal Mapper are meant to be readable but many cartridges implemented the reading because they were originally intended for MSX2 without Memory Mapper. Therefore if multiple Memory Mapper of different sizes are installed the read values will be wrong.

So in summary I think this paragraph currently in the “I/O Ports” section on the wiki page should be removed, because it’s unsubstantiated. Your alternative 2. is incorrect because it says they are readable, which directly contradicts with MSX Datapack appendix A.4, and presents the cases where they are not as faulty, which is speculation that only makes sense under the prior assumption.

I do think it is worth mentioning that in some cases they are readable, so I would replace that paragraph with something like:

“Even though the mapper registers are specified to be write-only, sometimes they can be read. This can not be relied upon however, due to it sometimes being absent or returning a masked value, it being blocked on some machines, and the possibility of bus conflicts. So the programmer should not attempt to read these, because software that does will not be interoperable.”

I would amend the wiki, but I don’t want to while this discussion is still going on.

By gdx

Prophet (2658)

gdx's picture

12-12-2018, 01:33

Grauw, Do not go away! I asked these questions to clarify the subject.

Grauw wrote:
gdx wrote:

The status registers should have been on all MSXs from the second generation with all the bits active. This would have avoided all problems, reduced the costs of Ram expansions and simplified the programming.

It wouldn’t have reduced the cost of RAM expansions, because readback is not needed for standards compliant software.

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.

Page 24/38
17 | 18 | 19 | 20 | 21 | 22 | 23 | | 25 | 26 | 27 | 28 | 29
My MSX profile