I am having a problem with the sprites on MSX 1.
When I display over an x number of sprites, sprites on the upper half of the screen are
displayed agein on the lower half, and the sprites on the lower half appair a second time
as a line on the first displayline.
Does anyone have any idea what could couse this feature?

???
more details please.
Which sprite planes, which screen, how many sprites, where are they, hwere are the "clones"....

I out 32 sprites spread out over the entire screen. Just bouncing from left to right. I count about 43 sprites.
Sprite attribute adress 1b00h, generator 3800h, 16x16 size, screen 2, repeaded first char set.
Sprite clones appear to be 128 pixels lower.
I use an otir in vblank to move a virtual spat to the vram.
Somewhere about halfway the screen seems to be a disturbance for a few (1-3) lines.

Oh, I might just have found the problem... No time to test it now but maby continiued tomorrow!

My guess is that you have some sort of lineint at y= 128 where you
move the registers of the sprite attributa table in a wrong VRAM area

BTW 43 sprites on msx1 is a feature not a bug

Some sort of line int... but then a hardware one without a int being generated.
Well I figured it out, and it is just as I thought yesterday.
I asumed that setting all the graphix sets the same as the first set was also supported on the TMS (msx1).
It must be an unofficial feature and we now know why.
But it is still usefull as long you are not using over about 8 sprites, 'cos using more than that creates the
'clones'.

please be more precise about this discover.

How do you generate the lineint?
In msx1 the only way i know is to poll the sprite collision flag
or the 5th sprite flag having properly set this condition
at Y=what you need.

What do you do at the line int in order to have sprite clones?

No int will be generated. It is useless... at any way I see it.

The effect must be due the repeating gen and col tables that also counts for the sprites... somehow.
Simply set reg4=00000000b and reg3=10011111b to achieve this.
Put some sprites on the upper half off the screen (more than an x number) and you will see they appear
again on the lower half. You might have to keep updating the SPAT to keep the effect going.

Test it on the real thing (msx1), an emulator or msx2 will not show this effect.

Aehm... 43 sprites? An MSX1 won't display more that 32 sprites simultaneously. And each horizontal display line will only display 4 sprites at once.

More info on that, please!. Source code?. Perhaps could be an undocumented feature?

GhostWriterP: did you try an emulator in which you emulate an MSX1?
Did you try both blueMSX and openMSX?

If so, please publish a program that shows the effect, so that emulators can be updated

I do not know if this was the case, but I have coded a little demo that presents 44 sprites on screen without flickering (tested on MSX1 running at 50 Hz). It also works perfect on BlueMSX, but the display is different: you can see more of the sprites in the emulator. In the real MSX, hidden sprite parts are bigger.

I have also managed to present 48 sprites on screen, it works perfectly BlueMSX, but on the real MSX it flickers a lot.

Once again: this is just a fast test of the effect.

You can download the source of it, as well as already assembled files (BIN and ROM) in the following address: http://www.robsy.net/44spr.zip

Comments on this?

It is a kind of screensplit for sprites, using the collision bit from VDP status register.

Of course, it is not optimized: it uses the BIOS routines to access VRAM and they are so slow. And optimized version would probably use a list OUTIs.

Using smaller sprites it would be possible to display even more sprites. But the 5th sprite limit is still on use: just 4 sprites in any horizontal line.

Interesting for games? I doubt it. But maybe it can be worthy for demo coders...

@pitpan

I do not think this is the case with GhostwriterP's program. He had the effect by
setting reg4=00000000b and reg3=10011111b !! This means that he faced some
sort of HW problem or feature in the MSX1 VDP

Your solution is "almost" standard, in the sense that it is documented (look on tni).

On a real MSX, the status bits (both collision and 5th sprite) are not updated on the same line as the collision occur. It is a bit random but typically it is collision line +/- 2 lines or something. On emulators, the status bits are always updated on the same line and behave a lot like HBLANK but that's not the case on a real MSX.
I've used simaulated line ints on MSX1 quite a lot. Unfortunately its not as deterministic as VBLANK or HBLANK but still quite useful. The behavior of the status bits are the same on MSX2. Anyone knows why.