I guess, you should be careful though: http://www.msx.org/forumtopic6522.html

Quote:

SONY MSX1 models do not support this "hybrid" mode: confirmed (personally) on SONY HB-10, HB-20, HB-101, HB-75.

Quote:

I've looked at it a bit, and the details are not as he described. This effect only happens when reg 3 bit 6 and reg 4 bit 1 are 0 (other bits: don't care), in Screen 2. The internal sprite comparator seems to mess up. It will compare spriteline Y positions with the current line, and additionally with the current line OR 128, causing sprites in the 0-127 area to be cloned 128 pixels down (or on line 0 if Y=127) [[*edit* of course, clonesprites with a result Y of 191-254 are not handled]]. Any normal sprite below this area will not be cloned. A normal sprite with Y=80 will not be interpreted as the end of the table (80+128=208). Other sprite functions remain normal: collision and overflow can happen between cloned and normal sprites. One thing to note is that the first 8 sprites are unaffected: they will not be cloned, the maximum number of sprites that can be shown with this is 56.

My CX5M does not do the mirroring this way. I get mirroring similar to this but the sprites in 0-63 gets cloned to 64-127 and 128-191. I haven't tested what bits in R3 and R4 are don't cares but I guess it may be the same.

Furthermore the flicker seems to be a bit different. I did one demo effect with mirroring bits set and placed sprites in the full range 0-191 and I got mirrored sprites but the part flickered all the time. Then my new demo effect also using mirrored sprites doesn't flicker as much. I'll run it longer to see if it is time related.

Quote:

XL2S's The Cure sets this bit to 0, then to 1, causing the title screen and sprites to be messed up on MSX

Darn you right I missed one. (BTW no messed up gfx on my msx1)

Quote:

I've looked at it a bit, and the details are not as he described. 8 sprites are unaffected: they will not be cloned, the maximum number of sprites that can be shown with this is 56.

That 8 sprite thing was something I did notice. But if I recall well, I really counted 96 sprites (8x8 sprites with all y coordinates between 0-56). Just run the test program I wrote.

Quote:

That 8 sprite thing was something I did notice. But if I recall well, I really counted 96 sprites (8x8 sprites with all y coordinates between 0-56). Just run the test program I wrote.

I get 32+24+24 sprites in my demo, but I haven't tried to put them all between 0-56 (I did 0-64). I did however try to revert the order (placing sprites 0 at line 0 and sprite 1 in line 1... as well as starting with sprite 0 at line 63). And the result is the same, so I think you are right GhostWriterP, All 32 sprites are most likely mirrored but not ones placed on line 56-63. I don't think there is a no mirror effect on sprites 0-7.

I tried inversing the sprite numbers in my test, and the result was reversed, meaning that sprites 0-7 still didn't get cloned.
In your cases, the 64 pixel shift might imply that reg 3 bit 5 and reg 4 bit 0 affect the sprite comparator instead.

Screenshots of GhostwriterP's demo:
* loaded 1 minute ago, I count 23 sprites, maybe one already disappeared http://home.planet.nl/~haps/crap/msx_clone1.jpg
* 3 minutes in: http://home.planet.nl/~haps/crap/msx_clone2.jpg
* 6 minutes in: http://home.planet.nl/~haps/crap/msx_clone3.jpg
* 15 minutes in, effect completely gone: http://home.planet.nl/~haps/crap/msx_clone4.jpg

My MSX1 VDP chip version:
TMS9929ANL
DDU Δ 44926

I don't need userfriendly programs. Just programs that do something that can be verified. *anything* is better than nothing.

Where is that demoprogram made by GhostWriterP? Is there a ROM version I can put in my MegaFlashROM? Then I can easily test it on MSX1 machines.

follow the link www.msx.org/forumtopic5579p15.html
second page can't miss the source listing.

GhostwriterP, did you do any investigation of potential don't care bits in R3 and R4?

Elaborate the part "don't care bits in R3 and R4"?.

In other words, exactly which bits of reg 3 and reg 4 influence the cloning effect? In my case reg 3 bit 6 and reg 4 bit 1 must be 0, the values of other bits in these registers don't matter.

dvik:

Quote:

Another interesting thing is that sprite collisions and/or 5th early clocked sprites (left of display area) are not handled the same on MSX1 and MSX2. On one, the collision is detected and on the other its not (can't remember which one does what).

Are you sure? I tried it, and EC + collision has the same behaviour as on my MSX2. Sprite collision is only detected when the sprite pattern is on-screen. This makes it safe to assume collision detection is done during pixel generation, instead of like overflow detection during sprite evaluation.

manuel, and others that want to verify but don't have the capability to write tests: I've made a few simple verification programs that can be loaded from Basic: http://home.planet.nl/~haps/crap/vtests.zip
(copy .BAS to disk, or convert .CAS to .WAV with Castools and upload, or just type them in and check your typing for errors )
You do need some experience to understand the parameters.

* VADDR
Checks if least significant byte of the VDP address is updated right after writing to it the first time. Prints "HELLO" if it worked, and "OLLEH" if it didn't.

* VSPR5
Returns last handled sprite number, 5 with default parameters. To test completely, change parameters in the listing. (other observations in the 1st post of this topic are too hard to verify with a simple test, and/or need more testing)

* VCOL
Checks sprite collision and overflow anywhere on screen, you'll have to change parameters in the listing to completely verify. By default, EC is on, X=0, and Y=0, resulting in overflow, but no collision.

* no file
To check whether or not VDP reg 1 bit 7 affects VRAM addresslines swapping or not, just type VDP(1)=VDP(1)XOR128 in Basic. If the screen becomes garbled, and you can't see what you type afterwards, it worked.


Here's GhostwriterP's sprite cloning demo, ROM version: http://home.planet.nl/~haps/crap/clones.zip
(use Waver if you want to convert that to .WAV)

Quote:

Are you sure? I tried it, and EC + collision has the same behaviour as on my MSX2. Sprite collision is only detected when the sprite pattern is on-screen. This makes it safe to assume collision detection is done during pixel generation, instead of like overflow detection during sprite evaluation.

I'm quite sure but can't remember what MSXes I tested, probably Philips VG-8020 MSX1 and Panasonic WSX MSX2+. The difference is on off screen collisions though. I think I had x coordinate in the sat set to 0 and the ec bit set.
I used as a screen split indicator in a demo and it worked on one MSX and didn't work on the other.

All these small differences with undocumented VDP quirks between MSXes makes it kind of worthless to use in development. (add to that, a pain in the arse to emulate accurately )

Besides the things discussed so far, you also have the timing differences. I've done quite a lot of timing tests and found some interesting things:
1. Most MSXes has 228 cpu cycles per scan line (1368 VDP cycles), but some MSX1 machines, VG-8020 is one, has 227 or 229 cycles per scanline.
2. Most MSXes has an even number of scnalines per frame, but some MSXes has some extra cycles each frame which makes the total number of cycles per frame not a multiple of 228.
3. MSX2+ and TR machines have one extra cpu cycle on outs to the VDP
4. If you synchronize to VINT, and writes to the vdp n scanlines later (e.g. change bg color), the write takes effect about 7/8 scanlines later on an MSX1 than on MSX2. This is not emulated (I did in bluemsx 2.4 or 2.5 but reverted the change).

Quote:

1. Most MSXes has 228 cpu cycles per scan line (1368 VDP cycles), but some MSX1 machines, VG-8020 is one, has 227 or 229 cycles per scanline.

Separate clocks maybe? (instead of 1 central crystal + clock dividers)

Quote:

2. Most MSXes has an even number of scnalines per frame, but some MSXes has some extra cycles each frame which makes the total number of cycles per frame not a multiple of 228.

I've seen such behaviour with the NTSC NES/Famicom, where each odd frame takes 1 cycle less to cause a shift in the colour subcarrier.

I've tested sprite collision/overflow detection by changing the background colour. It sometimes "misses" the read, and if (in the case of collision) a big sprite was used, it will usually succeed the next line. This is most likely due to reading it at the time it's set, causing it to be reset, and read as 0. The TMS9918 databook mentions it too: "The status register may be read at any time to test the F, C, and 5S status bits. Reading the status register will clear the interrupt flag, F. [doesn't tell that it clears C and 5 even though it does] However, asynchronous reads will cause the frame flag (F) bit to be reset and therefore missed. Consequently, the status register should be read only when the VDP interrupt is pending."
The collision bit gets set at the time the pixel gets rendered, only X and Y influenced the timing. The overflow bit gets set at the end of sprite evaluation, changing X or the sprite number didn't influence the timing.

You could solve that by placing 2 pairs of dot-sized sprites on one scanline, with a certain distance between them, so in the case the program misses the 1st collision, it will not miss the 2nd one.