Mapped RAM I/O port read enable strategy

Pagina 1/2
| 2

Door Eugeny_Brychkov

Paragon (1097)

afbeelding van Eugeny_Brychkov

03-10-2019, 09:41

I am revising GR8NET code of identification of the maximal size of the mapper I/O register. I know that applications reading these registers are not following standard, and generally hardware must not respond to port fc-ff reads, but these "low-level" applications exist and sometimes very useful. Bad or good, I want them to be properly supported, but avoid electrical conflicts of the data line.

I will give two examples:

1. standard built-in YIS503-3 memory mapper has 128k onboard and responds with D2..D0 to the page number reads (Yamaha violating standard?). All other bits D7..D3 are floating, effectivelly making them 1s due to pull-ups (however there're exceptions of older machines not having pull-ups and reading shit for unused data lines, let's omit them for now). In this situation I can safely identify the size of mapper (3 bits) by writing 0 into the port, and happily use D7..D3 for GR8NET mapper register read response.

2. two GR8NETs in the system, one having 512K of mapped RAM, and another having 1024K of mapped RAM. Not sure why this may be needed, but it is fairly obtainable configuration. Or, there's some other memory mapper in the system. The issue here is that these memory mappers, like GR8NET, are not able to output selected bits only, but 8-bits at once. Thus if first GR8NET is initialized in 512K mode, it responds with 111xxxxx, and it will not be possible for second GR8NET, which is going to be configured with 11xxxxxx, to identify that bit D5 is actually being actively driven high, and is not floating. Thus if it will configure to output this way, there will be electrical conflict within D5 line when reading previously written values having 0 in D5.

I am interested hearing your thoughts on this matter, in particular:

1. how to deal with these configuration situations?
2. should we think to "standardize" the mapper port read further the statement that it is not allowed to read it as hardware and many application break this rule? Example could be if device is not able to keep data lines floating, it will report largest register - e.g. in case of GR8NET full 8-bit register will be reported, not just a part of it with higher bits forced to active 1. Surely programs will identify wrong, bigger size of the mapper, but there will be no conflicts and "smart" applications will actually scan for RAM and identify that it is smaller than the mapper (then question: what mapper RAM controller should put into RAM space for out-of-physical-RAM locations - same RAM mirrored, or 0ffh?).

Aangemeld of registreer om reacties te plaatsen

Van NYYRIKKI

Enlighted (5385)

afbeelding van NYYRIKKI

03-10-2019, 11:08

Yes... If you can't keep the unused bits in Hi-Z mode, then report last written value.
I don't think the out-of-physical-RAM question is that important as the application should cope with the situation anyway. Only case where it really kind of matters is when copy of ROM in MSX tR internal memory mapper is pointed. In this case you need to use negative numbers as the internal mapper size can vary, so mirroring must be working... Funny detail is that these pages return 0ffh when the computer is on DRAM-mode, so tR even uses both approaches at a same time. Smile Maybe same rule should apply here... -> If you can't do Hi-Z, do mirroring.

Van Eugeny_Brychkov

Paragon (1097)

afbeelding van Eugeny_Brychkov

03-10-2019, 11:24

NYYRIKKI wrote:

Yes... If you can't keep the unused bits in Hi-Z mode, then report last written value.

You means all 8 previously written data bits - the maximum bits the device outputs onto the bus?

NYYRIKKI wrote:

Funny detail is that these pages return 0ffh when the computer is on DRAM-mode, so tR even uses both approaches at a same time.

I am going to use it in GR8NET too. I was asked to enable MSX-Audio sample RAM in mapped RAM mode 7, and, when enabled, there will be minimum 768kB of the mapped RAM, with remaining up to 1MB space filled with 0ffh, and starting mapped RAM page 40h the image of mapped RAM (with this "shadowed" sample RAM area) will repeat.

My second part os about standardizing this behavior. Newly made memory mapper devices to output the maximal number of bits they have to output, not forcing any data line to 1 as being "unused" in the mapper.

Van gdx

Prophet (3037)

afbeelding van gdx

03-10-2019, 11:38

The ideal is and put a switch to disable reading, when is enabled the best is to put the unused bits at 1, but only if it does not force the same bits of the other larger mappers. Otherwise the standard says that unused bits can be anything.

Van NYYRIKKI

Enlighted (5385)

afbeelding van NYYRIKKI

03-10-2019, 11:35

Eugeny_Brychkov wrote:

You means all 8 previously written data bits - the maximum bits the device outputs onto the bus?

Yes, this is what I meant.

Van Eugeny_Brychkov

Paragon (1097)

afbeelding van Eugeny_Brychkov

03-10-2019, 11:52

gdx wrote:

the best is to put the unused bits at 1

This is exactly the wrong thing to do. Unused bits must be Hi-Z, or be used.

gdx wrote:

The ideal is and put a switch to disable reading

Complicates hardware design and increases cost.

Van Eugeny_Brychkov

Paragon (1097)

afbeelding van Eugeny_Brychkov

03-10-2019, 11:51

NYYRIKKI wrote:
Eugeny_Brychkov wrote:

You means all 8 previously written data bits - the maximum bits the device outputs onto the bus?

Yes, this is what I meant.

Thank you, agreed. I will be checking if there's already existing mapper with 8 bits, it there's one, I will disable reading (as other mapper will respond), but if there's no one, I will enable reading.

And hopefully there will be no device on the bus reporting unused data lines as 'always 1'.

Van NYYRIKKI

Enlighted (5385)

afbeelding van NYYRIKKI

03-10-2019, 12:20

Eugeny_Brychkov wrote:

I will be checking if there's already existing mapper with 8 bits

I just wonder, how "ok" it is to drive other cartridges from your own cartridge? I don't expect there is problem with it and I guess during boot initializing I/O #FF-#FC to fixed values 0-3 in the end can be only good thing, but does the MSX standard say anything about this subject?

Van NYYRIKKI

Enlighted (5385)

afbeelding van NYYRIKKI

03-10-2019, 13:00

BTW now that we are talking about having multiple devices on same I/O port, have you ever thought about keeping copy of MSX write only devices registers inside GR8NET? If we could ask from GR8NET about what were the last writes to VDP and OPLL registers, we could implement ie. game savestates... or for example a game cheat finder that has GUI.

Van Eugeny_Brychkov

Paragon (1097)

afbeelding van Eugeny_Brychkov

03-10-2019, 13:25

NYYRIKKI wrote:

I just wonder, how "ok" it is to drive other cartridges from your own cartridge? I don't expect there is problem with it and I guess during boot initializing I/O #FF-#FC to fixed values 0-3 in the end can be only good thing, but does the MSX standard say anything about this subject?

It is not going to drive anything, it is going to respond to CPU reads. Electrically if all the devices respond the same on the selected lines, there must be no much problem. Currents still can flow, but not that when devices say different logic levels. It seems this multiple memory mapper configuration is a dark spot in the MSX standard, seems not to be defined or regulated.

NYYRIKKI wrote:

BTW now that we are talking about having multiple devices on same I/O port, have you ever thought about keeping copy of MSX write only devices registers inside GR8NET? If we could ask from GR8NET about what were the last writes to VDP and OPLL registers, we could implement ie. game savestates... or for example a game cheat finder that has GUI.

I had these ideas in the past, but the architecture needs to be defined upfront: how many writes to remember, does it need to remember sequence of access (e.g. for VDP), and what devices are to be supported. And most important - how to trigger savestate event.

Van Grauw

Ascended (8456)

afbeelding van Grauw

03-10-2019, 16:00

IMO unused bits should be either left floating or return the last written value in full. It should never force bits to 1. That is the only way to avoid bus contention. There is an unfixable fundamental issue with reading, exactly why it is not allowed, and software which does it anyway will always have compatibility problems with several machines and configurations.

Pagina 1/2
| 2