pitpan, you are saying that you did a reset of that bit before the HALT loop, and then you set the bit just after the loop?.

if it is that case, why you writes the R0 register? for what? if there is only one screen mode bit selector.

No, I just reset that bit once, when setting the screen mode.

so, why will the VDP just stopping refreshing IF you halt only the CPU work, and that not include stoping the refresh system of the CPU itself.

you can make a small example of the problem... that we can run and test in our msx1 / msx2?

overall, i wonders SHOWING how making longer the HALT/LOOP makes the difference....

I have finally fully understood the problem. Let me describe it briefly:

-When you reset the most significant bit of VDP register 1, then the TMS9918 selects the 4 KB memory interface. This means that only the TOP MOST 4 KB are refreshed (dynamic memory needs periodical refreshment to avoid data corruption).

-As far as the screen is ON (blank bit set to 1), there is no problem with the screen displayed, because the VDP reads the VRAM to compose the screen, therefore the VRAM is refreshed and its contents preserved.

-When the screen display is OFF (blank bit reset to 0), then, after a short period of time, the contets will get corrupted. The first 12 KB (need to confirm this) are deleted (255 and 0 written everywhere).

You can check what I am explaining here using the following example in BASIC:

10 COLOR 15,0,0
20 SCREEN 2
30 FOR I=0 TO 255
40 LINE (I,0)-(255-I,191),RND(1)*14+2
50 NEXT
60 VDP(1)=VDP(1) AND &h7F
70 DEFUSR=&h41:A=USR(0)
90 IF INKEY$="" THEN 90
100 DEFUSR=&h44:A=USR(0)
110 GOTO 110

Push any key once that the screen is blanked, and you will see that the two top thirds of the screen have been replaced with white and black horizontal lines.

Note that this will only show the "TMS9918 WEIRDNESS" on MSX1 computers featuring TI chips. Therefore, no visible effects on MSX2 or higher computers, with V9938 or V9958.

Pitpan - would you mind it if I add this little program to the set of tests to the MSX Emu Comparison?

ahhha! you don't mention the turn off/on of the screen before... now i see all the picture.

Tried this on my Yashica YC-64 (50Hz interrupt).

Did some rough measurements in basic: after about 21 jiffies the corruption starts to occur. After about 63 jiffies the corruption is complete This varies a little bit though. Will be very hard to emulate the actual decay. I'd say: practically impossible. It's very different for every system and chip, I guess.

Snout: of course that you can include it, but I don't know if it is an interesting feature to be implemented. What I will try to do is my own research to understand perfectly the TMS9918 timings, that are different from the V9938/V9958 timings. That perhaps could be implemented.

Manuel, thanks for the calculations. My guesstimations were around those values, so I think that the "VRAM refreshment" problems are a satisfactory explanation to the phenomenum.

pitpan, Can you describe how the pattern of the corrupted VRAM looks (like if it is a regular pattern with 0's and 255's).

Quote:

pitpan, Can you describe how the pattern of the corrupted VRAM looks (like if it is a regular pattern with 0's and 255's).

How the bits look in non-refreshed dram is dependent on many factors, like the type and manufacturer of the DRAM. This has nothing to do with the TMS9918/28, besides this IC not sending out refresh signals. There is often a pattern since the dram IC's behave identical ofcourse, but the pattern can be random.

HansO, so it depennds on the DRAM what happens? pitpan said it converged to 0 or 255 after a while but you're saying this depends on the DRAM? Do you know how long it takes from the decay starts to all dram is cleared (in seconds or microseconds)

I'd like to test it myself but my MSX1 is broken.

Another question is what happens if you disable the display but reads from the vram. Does refresh occur then and if so on what part of the memory?

dvik: i reported about decay times above. The pattern I see on my Yashica YC-64 is that the upper 3/4 of the screen is blue with white stripes on every other line.

manuel, did you look at the VRAM? It sounds like your VRAM was cleared to the values 0x55 and 0xaa.

Every type and brand of dram has a different way of responding on lack of refresh. Even the way refresh is to be done can be different!
Reading of DRAM is not sufficient to have the refresh occur. In fact refresh is mostly done by recharging the storage cell. So there is always special circuitry in and outside the dram memory to have the refresh/rewrite occur.
Since most MSX1 computers have the same type of DRAM for videoram and the circuitry around videoram is identical - all is done by the TMS9918/28 - it might be the patterns that appear will be identical. So I suggest you take the behaviour in time and pattern as described by Manuel as a good approximate behaviour.

The value of this for accurate emulation is not much more then helping Pitpan debugging, no program other than his faulty one use this effect since it is useless. But striving for perfectness is always good!

Thanks for the explanations HansO and manuel. If anyone could make a screenshot of this it would be very helpful.