Mapped RAM I/O port read enable strategy

Pagina 2/2
1 |

Van zPasi

Champion (471)

afbeelding van zPasi

03-10-2019, 16:09

Eugeny_Brychkov wrote:
gdx wrote:

The ideal is and put a switch to disable reading

Complicates hardware design and increases cost.

How about making a "soft switch", that is an additional mode register?

Van gdx

Prophet (3037)

afbeelding van gdx

03-10-2019, 16:37

Put a switch is ideal for the user but yes, make properly a hole in cartridge is annoying when we need make many expansions. About cost and PCB design it doesn't change a lot.

A soft switch seems difficult to realize if it should take into account this case of several mappers but I do not see the point of putting more than one GR8NET on a MSX. So it must be feasible.

Van zPasi

Champion (471)

afbeelding van zPasi

03-10-2019, 17:15

Wait a minute, in GR8NET there already is a "soft switch", that can be set using the second parameter of the CALL NETSETMAP command. "Valid values are 0 (read disabled), 1 (read enabled), and 2 (auto-detect, default)."

Now I'm a little lost about what this thread is all about ? Crazy

Van Eugeny_Brychkov

Paragon (1097)

afbeelding van Eugeny_Brychkov

03-10-2019, 18:42

zPasi wrote:

Wait a minute, in GR8NET there already is a "soft switch", that can be set using the second parameter of the CALL NETSETMAP command. "Valid values are 0 (read disabled), 1 (read enabled), and 2 (auto-detect, default)."

This parameter defines how firmware configures mapper RAM register read. But if enabled (forcefully by user or by firmware), output of all 8 bits is performed because GR8NET can not output individual bits and float rest of them. Because it uses 5V to 3.3V level shifters and FPGA is not directly connected to the MSX bus.

Van NYYRIKKI

Enlighted (5385)

afbeelding van NYYRIKKI

04-10-2019, 10:56

Eugeny_Brychkov wrote:

It is not going to drive anything, it is going to respond to CPU reads.

I'm still don't get the idea... How do you know if there is some other cartridge responding or not? I guess that if you don't drive the bus you need to avoid responding to CPU read in order to figure out if some other device is responding, but in this case the CPU might not get response at all if there is no other mapper.

Quote:
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.

Only last write to particular register needs to be remembered, I don't think sequence is important... With device like MSX-MUSIC this should be really simple: Just save index written to #7C and then write data to that offset when #7D is written... With VDP this is more difficult as there is not only port #99, but also ports #9A and #9B to take care of... Maybe even VRAM memory pointer should be calculated from #98 writes to figure out what VRAM address VDP is currently reading or writing, but you don't need to mirror the data as it is already in VRAM.

I think it would be enough then that there are some GR8NET specific I/O ports (or memory locations) to select offset in GR8NET internal memory space and then read the values back. Naturally this needs a TSR in MSX memory space to handle savestates, but I think you could leave that part for software developers to figure out.

Van Eugeny_Brychkov

Paragon (1097)

afbeelding van Eugeny_Brychkov

04-10-2019, 11:03

NYYRIKKI wrote:

How do you know if there is some other cartridge responding or not? I guess that if you don't drive the bus you need to avoid responding to CPU read in order to figure out if some other device is responding, but in this case the CPU might not get response at all if there is no other mapper.

Normally, with pull-ups on the bus, if none talking I read 0ffh. As soon as I extend mapper size to 8 bits, I now test for 0 after writing 0 into the mapper register; if I get 0 back I do not enable my read.

NYYRIKKI wrote:

Naturally this needs a TSR in MSX memory space to handle savestates, but I think you could leave that part for software developers to figure out.

I do not think so. This is key part of the savestate mechanism, and I do not see the reliable way to save state in games using TSR routine. If this issue will be sorted out, then we can approach implementation of other parts.

Van NYYRIKKI

Enlighted (5385)

afbeelding van NYYRIKKI

04-10-2019, 13:05

Eugeny_Brychkov wrote:

Normally, with pull-ups on the bus, if none talking I read 0ffh. As soon as I extend mapper size to 8 bits, I now test for 0 after writing 0 into the mapper register; if I get 0 back I do not enable my read.

Oh, now I understand... This detection is done in software initialization that controls the hardware, not directly with hardware on power up.

Quote:
NYYRIKKI wrote:

Naturally this needs a TSR in MSX memory space to handle savestates, but I think you could leave that part for software developers to figure out.

I do not think so. This is key part of the savestate mechanism, and I do not see the reliable way to save state in games using TSR routine. If this issue will be sorted out, then we can approach implementation of other parts.

This is a bit sad as I see this as a solution to lot of problems interacting with random software, not only as key part of savestate mechanism... To me having a solution that works 50% of the time is heck of a lot better than having no solution at all... and in general it would definitely be a step to a right direction.

In Playsoniq they solved similar issue in quite nontraditional way... Roughly explained they expect that the software is running from Playsoniq internal memory and when they need the CPU attention they disable the RAM at M1, record address bus and then start to feed their own custom jump routine. When these are delivered to CPU they enable their own program to memory space and in the end jump to address that was in address bus during M1 and enable RAM back.

This is a bit ugly and it can break the program only when there is /SLTSEL, /RD and /M1 active, so it is still not 100% fool proof solution for any MSX program, but I think it is the most complete solution I've heard so far...

Pagina 2/2
1 |