Hi! Recently I have experienced some problems debugging one of my work-in-progress games. While the game worked smoothly on any MSX2/MSX2+/Turbo-R and emulators, it had severe graphic glitches when executed on a MSX1 machine. After a five-days nightmare, I was able to correct the problem: I was reseting the most significant bit of the VDP register 1. According to the TMS9918/TMS9928/TMS9929 specs, this bit has the following meaning: 0- 4 KB VRAM installed; 1- 16 KB VRAM installed.

According to the MSX TECHNICAL DATABOOK and other MSX references, this bit is meaningless for the MSX, because it has always 16 KB of VRAM. The evidence shows that this bit does produce some effects on MSX1 computers. I suppose that it changes the VRAM mapping or the way the VDP processes the VRAM addresses. I have discovered that the issues arise when the V-blank interruption is acknowledged.

Does anyone have any clues about this? Any information regarding this topic? It will be useful to know exactly the meaning of this bit on the MSX1 computers, so this particular problem could be fixed in all emulators. None of the emulators support this bit at the moment, they just ignore it, as the MSX specification claims. But the tiny TMS9918 seems to be more tricky than expected!

Ideas?

I don't have an answer to what it means, bit I did notice that every game I checked the vdp settings of, had this bit set. The effect could just be undefined of course.

I never read that it was ignored... But it seems reasonable that this bit has to be set to the correct amount of VRAM. Clearly the TMS9918 changes the way it addresses VRAM based on this bit, otherwise there would be no purpose in having such a bit! Remember, the TMS9918 is a very general VDP which was designed to be used in more computers than just MSX, with different amounts of VRAM. Along with your reasoning, if another computer has always 4kB of VRAM, would this bit be ‘meaningless’ for it as well?

Of course it’s very well possible, likely even, that on v9938, which handles different amounts of VRAM, this bit doesn’t do anything anymore.

Personally, I always base the changes I make to the VDP registers on the mirror which is in RAM (at least, for the mode registers etc), changing bits with AND (to clear) and OR (to set). I really think that’s the best approach .


~Grauw

About the effect of that bit, it is stated in the MSX RED BOOK and IIRC in the MSX TECHNICAL DATABOOK that it is ignored. But, as you have said, if it is specified in the chip, then it CANNOT be ignored by the chip itself.

Could there be circuits in MSX1 computers that make it ignore this bit? If so, are there MSX1 computers that do and MSX1 computer that don't ignore it?

Funny how some things can come to light, more than 20 years after a standard has been set

The problem that I encountered was really annoying: I executed the following code:

ld b,150
LOOP:
halt
djnz LOOP

Clear, isn't it? Well, it the B value was 15 or less, it worked perfectly. If it was more than 15, then apparently random data was copied to the colour table in VRAM. I tried everything, and nothing worked, until I noticed this tiny little bit.

A programmer's nightmare!

This code does not do anything, please fill in the code.

That's it, Nyyrikki. I was only "pausing" the program for some time, in order to let the user read some texts displayed on screen. If I waited for more that 15 frames, then the colour table in VRAM got corrupted. And I did not install any interruption! Weird, weird, weird!

Quote:

And I did not install any interruption! Weird, weird, weird!

So interruptions are disabled or not? in that case I remember some konamiman words in "easymbler". "The perfect murder: DI+HALT "

Of course, I executed first EI. What I meant is that no additional interruption procedures were installed.

Quote:

That's it, Nyyrikki. I was only "pausing" the program for some time, in order to let the user read some texts displayed on screen. If I waited for more that 15 frames, then the colour table in VRAM got corrupted. And I did not install any interruption! Weird, weird, weird!

Not especially weird. I do not have the technical manual here, but if that vram is the same old kind of ram that needs a regular (external) refresh, and you just altered the way in which the VDP addresses this ram, then it could well be that the TMS9918 can still read some parts of the ram normally, but not others part (depending on the CAS/RAS mechanism of the connected chips) and thus not perform the ram refresh...

In the old days you could find some 555 timer based schema's that would trigger the 'z80 pause' line that is available on the cartridge port.
by halting the z80 with that line, the ram refresh performed by the z80 was also temporarely halted, and regular RAM would lose it contents also.

You're implying it would be malfunctioning hardware? Seems a little bit odd to me...

Pitpan, have you already tried BlueMSX/openMSX/NLMSX in MSX1 configuration? Does it work for your configuration there?

Quote:

That's it, Nyyrikki. I was only "pausing" the program for some time, in order to let the user read some texts displayed on screen. If I waited for more that 15 frames, then the colour table in VRAM got corrupted. And I did not install any interruption! Weird, weird, weird!

In what way do the colours become corrupted? Do they all become greyish?

If memory serves me well, the bit you are talking about is actually implemented as a black-and-white/colour output switch on MSX1 computers; it lost it's meaning as a 4K/16K switch. This is mentioned by the better MSX documentation.

I used to play with this bit in my MSX1 days, and I can confirm that at least on a Sony Hit Bit 201P screen output on a colour television did indeed become black-and-white when resetting this bit.

This 'feature' disappeared on the V9938. Other than this VDP register bit, there were some other tiny changes made to the MSX standard when MSX2 was defined, causing the MSX2 to be not 100% backward compatible. I guess that 99.99% backward compatibility in real life situations is quite satisfactory though .

Quote:

You're implying it would be malfunctioning hardware? Seems a little bit odd to me... Pitpan, have you already tried BlueMSX/openMSX/NLMSX in MSX1 configuration? Does it work for your configuration there?

I can of course only speak for openMSX, but i am sure that that behavior isn't implemented in openMSX. Neither is the chip select bit on the V9958 honoured. And there are some known VDP (V99x8) weirdnesses that aren't working on any emulator yet.

The program works fine in all emulators, but not in the real MSX1 computers.

After reading some of the TMS9918 docs, I think that turbor is right: it is related to a VRAM memory refresh problem. When this bit is reseted, part of the VRAM is not dynamically refreshed, therefore its contents will be erased or corrupted after some time (after some HALTs, in the provided code). Really curious, because there is a kind of "corruption pattern". I will try to create a tiny demo to show the problem.