Quote:

The results are pretty unexciting . With the 9938 all modes show similar pattern to the one in the photo, maybe with a bit more solid filling, following by a white screen that seems to remain till a key is pressed, then the next text stats screen appears and asks for a key being pressed. The 9958 seems to vary a bit the behaviour, all modes are like the one in the photo (taken thanks to the PAUSE button). After showing that, there's no white screen and the text screens appears inmediately: Hope this helps!

Sorry for late aswer, and thx for the tests. althought the test showed that those modes are useless, i can't figure why the patterns are so distorted. Ideally they should be vertical colored bars with width = 16px.

Try on bluemsx, they are so.

remember, during fill screen we are on a regular screen5 mode, so the output should be as described, vertical bars (and is this on bluemsx).


Hey, dvik, can you help to find the difference between bluemsx and real msx2 ?

Out of curiosity, what does it do on openMSX?

Quote:

Out of curiosity, what does it do on openMSX?

Let me try, soon i will inform you...

Maybe it's nice if you can also send me the programs.

check your mail manuel...

basically the screen 5 image is the same of bluemsx. But appears to be different from the real machine....

Thanks, but there was not a program attached... (maybe a virus scanner filtered out COM programs...)

Note that it's useful to try different real machines. The timings are not always identical. (On some real MSX machines, demos like Utopia don't run properly, e.g.) So, if you rely on very much detailed timing, things may go wrong. The system/standard just isn't specified in that much detail...!

If the VDP and Z80 uses the same clock, an MSX2 will have 228 CPU cycles per scanline. This is what bluemsx and openmsx emulates. Some MSXes seems to have a separate clock for the VDP and then its not as easy to do synchronized code.
I suppose the test was performed on an MSX2 machine and not an MSX2+ machine. MSX2+ and TR machines have an extra wait state on outs to the VDP. I'm not aware of any MSX2 with this behavior but I can't say for sure.

But to answer your question, if it looks good in blueMSX and not on the real MSX2 machine, My best bet is that the real MSX2 machine is not a typical one. Most MSX2 machines behaves as the emulators when it comes to CPU vs VDP timing.

If you send me the code that changes color each scanline, I can tell you more. I only need the code that is repeated for each scanline, not the entire program.

In blueMSX, you are using a MSX2 machine right?

to dvik/manuel:
the test program does not rely on anything special, just fill vram by outing to 98h, while in sc5, just before changing to illegal mode.

@manuel: disk image re-sent....

Ok, sounded like it was doing something fancy. So its basically supposed to be a screen 5 image with vertical bars that are 16 pixels high?

Can you send the test program to me too?

Are you sure that in the screenshot the HORIZONTAL SYNC is synching?

Maybe the TV set is out of sync and shows the image on a FREE HOR. FREQ.

Please, check that first.

The picture was taken from a MSX2+ machine (FS-A1WSX/V9958) thanks to the PAUSE button, the V9938 looks nearly identical (using a plain NMS8245); but without PAUSE I'm not able to take the photo...
The TV set is a TFT one, easy to spot due the lack of vertical synch defects, the image is pretty stable to take photos easily (one of the few advantages of this kind of devices )

Quote:

Maybe the TV set is out of sync and shows the image on a FREE HOR. FREQ.

WYSIWYG. This is the straight result after executing the code PingPong submitted to me. I've never needed to play with the TV synch (you mean Hsynch & VSynch knobs, isn't it?) to see my MSXs.... My bet is that the VDP gets fooled and losts the real dimensions of the screen to be displayed and that's the reason why all seems displaced by an offset; maybe PingPong could post a picture of how it looks using an emulator.

Looks, if the result is that the VDP is taking wrong OFFSETS when starts to display a LINE, like doing by example:

The normal offset IS:

PIXEL COLOR = VPEEK (Y*256+X)

The wrong offset IS:

PIXEL COLOR = VPEEK (Y*260+X)

Or something near to do that picture!.

Take note that in each Next line, it is rendering starting just a few pixels right than the upper line...

IF is possible to control the (n) factor of (Y*n+X), then IT IS USEFULL!!!!!!!! REALY USEFULL!

Because you will be able to do effects on DEMAND! FASTLY, rally cool for DEMOs and GAMES (like the end of a stage and the start of the next stage).... I remember a effect like THE GOSTBUSTER (real arcade machine doing something similar, but in that case is doing that in the hard way) so, FORGOT that UGGLY BLACK IMAGE when the games redraws the next stage very usefull on BASIC's GAMES overall!!!.

But first, check if it is not an HOR FREQ problem....

Somebody has a OSCILOSCOPE near of his MSX to test in the RGB out the H sync FREQ?

Another way, is to use a tv that normally without H SYNC it shows a BLUE SCREEN. So if the bLUE SCREEN appears, it is out of sync.

flyguille, you can test it by yourself, within an emu, the result is 16 pixel wide pixels.
Byte speaking i write a bunch of 8 bytes all equal in value to vram, another bunch of 8 bytes all equal, and so on until i fill the entire vram.....
Anyway i've sent the test program to manuel, and now to dvik.