Making proper external mapper for Turbo-R

Por Eugeny_Brychkov

Paragon (1132)

imagem de Eugeny_Brychkov

20-03-2020, 10:54

Following this short conversation I am trying to identify the way for dealing with this issue with T976x chip properly.

The problem is to identify if this chip is installed in the system, and turn mapper register read-back off. That would be a bad idea to rely on the reading different values from the mapper register exploiting the electrical conflict, as article states if external mapper's drivers are strong enough the readback will be correct however there will be heating.

The second idea was that there must be a way to detect this chip through other means. The wiki article states that they insert 1 or 2 wait states for VDP access; GR8NET is able to detect this (0, 1, 2 or bigger).

Question: can I reliably rely on the fact that 1 or more VDP wait states are detected? Would there be any false positives - in other words are there any other chips inserting wait states for VDP?

Entrar ou registrar-se para comentar

Por Grauw

Ascended (8900)

imagem de Grauw

20-03-2020, 11:57

I honestly would not go through such lengths. Software is not supposed to use read-back, and if you would sum the average amount of times and duration that some software does it over the total 3579545 clock cycles per second, it is absolutely minimal. No mapper has taken any measure against it before and systems are fine.

I feel like this kind of detection you mention has a high likelihood to cause issues rather than resolve them. Since VDP waits are necessary for turbo, think about all those different 7 MHz turbo circuits out there, or the turboR in R800 mode, or future homebrew systems with turbo CPUs. There is no way to say or guarantee that the T976x MSX-ENGINE is the only one inserting a particular amount of waits. Particularly for circuits which insert a variable amount of waits depending on the time of the last access like the turboR’s S1990 does.

Also I feel like mappers should not need complex logic to be called a “proper mapper”. Rather there is just some improper software, it’s causing compatibility problems for them, but that’s their own fault.

Por gdx

Prophet (3427)

imagem de gdx

20-03-2020, 12:32

I think to enable reading registers the manually setting of the bit of a register using expanded I/O port for example is enough. (Activable like the turbo mode of Panasonic MSX2+)

Por Eugeny_Brychkov

Paragon (1132)

imagem de Eugeny_Brychkov

20-03-2020, 14:00

I took a look at the designs of the machines listed to contain T976x chip:

  • Panasonic machines all contain 100 Ohm resistors. Clever and cheap solution to protect system chips;
  • PHC-55FD2 contains buffers (245 for data and 4*367 for others);
  • Sahkr AX-370 and all other Sanyos contain no buffers and no resistors.

Panasonics are the best.
PHC-55FD2 may have inherent problem as even if external mapper does not output all 8 bits but drives BUSDIR then 245's output will get into conflict with the internal mapper.

Por hit9918

Prophet (2886)

imagem de hit9918

23-03-2020, 17:01

I found the idea of a gigamapper nice. but with 256 megs there would be too much boot time. to make a memory allocation list.
so it would be nice if one could snip the RAM size. a mask register ANDed to the mapper high byte could configure anything from 256 megs to 4 megs.

Por gdx

Prophet (3427)

imagem de gdx

24-03-2020, 01:08

Playsoniq cartridge use I/O ports &HF8-&HFB with &HFC-&HFF to extend the memory mapper to 1024 MB but some MSXs don't like it.