It is quite weird indeed. I mean that the odd rows present the full sprites whereas the even rows present some display problems. Very interesting!

About the different value for VDP registers, I would not use them. Non-standard modes are not compatible in all TMS99XX and clones used in MSX computers. That happens too with mixed screen mode.

Some other interesting differences between the TMS and the V9938/58:

1. If a sprite collision occurs on sprites left of the left border (when using EC), the sprite collision is detected on the TMS but not on the V9958, i.e. The collision bit in SR is updated on the TMS but not on the V9958.

2. The time between VBLANK and when VRAM is read the next frame differes by about 1.2 lines (don't have the exact timing in my head).

Curious details, but it is good to know.

@dvik
I remember your great demo using screen split based on sprite collision.
Any idea about the strange feature obtained overlapping sprite areas?
I cannot see the effect as I have only emulators (yesterday I have found
my old turboR in my parent's basement, but it is broken).

I need to test your code on a real MSX1 (I'm getting one in the mail any day now) and play around with it a bit. Me and joyrex are working on a new MSX1 demo (a teaser was shown in the openMSX booth at Bussum). I did most of my development on emus and tested it on my WSX and later found that most of the tricks needed modifications to run on a MSX1. I still have one curious bug where the TMS seems to loose sync (!) which doesn't happen on MSX2 machines. After the demo is finished I'd like to do more test programs to figure out more of the differences between the TMS and V99x8. I ran into quite a few minor differences both timing and behavioral. The one you encounter looks new to me but certanly very interesting and I'd love to play around with it a bit more.

Does anyone have any more detailed TMS specs than what is available on the MSX resource sites on the internet? Btw, to make testing a bit easier I'd really could use a 60Hz MSX1 if someone has one for sale.

Well here is a small test program. Assamble with SjASM.
Featuring a lot of sprites (over 32), not flickering and without screensplit fifthsprite tracing
techniques. Other than that I do not find it usefull.

; More sprites on MSX 1

  macro setwrite adres
  ld a,low adres
  out (99h),a
  ld a,64+high adres
  out (99h),a
  endm

  byte 254
  word start.start
  word endofcode
  word start.start

  org 9000h
  map 09100h

/*  
  size 2000h          ;To make a rom file use these instead of the above header
  map 0c000h
  org 4000h

  byte "AB"
  word start.start
  byte 0,0,0,0,0,0
*/

  module start

start
  call 72h
  call 69h
  call 41h

  ld b,32     ;init sprite pos,pat,col
  ld hl,spat
.sprl
  ld a,b
  add a,a
  sub 3
  ld (hl),a
  inc hl
  ld a,r
  add a,a
  xor l
  sbc a,b
  ld (hl),a
  inc hl
  and 3
  add a,5
  ld (hl),0*4
  inc hl
  ld (hl),a
  inc hl
  djnz .sprl

  di
  setwrite 3800h	;sprite pattern
  ld hl,data.sprite
  ld bc,32*256+98h
  otir

  xor a			;same sets (where it is all about)
  out (99h),a
  ld a,4+128
  out (99h),a
  ld a,10011111b
  out (99h),a
  ld a,3+128
  out (99h),a

  ei
  halt
  call 44h

.main
  halt

  setwrite 1b00h	;sprite spat
  ld hl,spat
  ld bc,128*256+98h
  otir

  ld b,32		;movesprites
  ld hl,spat+1
  ld de,4
.move
  inc (hl)
  add hl,de
  djnz .move

  jr .main

  endmodule

  module data

sprite

  byte 00111100b
  byte 01111110b
  byte 11011011b
  byte 11111111b
  byte 11111111b
  byte 11011011b
  byte 01100110b
  byte 00111100b

  block 8*3,0

  endmodule

@spat # 128


@endofcode

  end

Make a rom or a bin file and see the difference between a emulator and the real thing!

wow, I count 643 sprites

I guess your routine does not last screen redrawing. I mean, if it is done in one INT and you are doing "DI" before...
Anyway, think about how screen drawing works: If you put any sprite, lets say, X=100, Y=0 (on the higher half), wait for Y=128, change VDP registers and then pattern tables, maybe you are displaying the same patterns on the 2 halfs. Try to change patterns first and then registers...

@mohai
Read all the posts !!
We are facing an HW problem of the TMS (that is not present on msx2 and successive).
There is no INT routine, the TMS has a strange and buggy behaviour when you
overlap r#3 and r#4 Vram areas

Quote:

Does anyone have any more detailed TMS specs than what is available on the MSX resource sites on the internet? Btw, to make testing a bit easier I'd really could use a 60Hz MSX1 if someone has one for sale.

The Technical hanbooks for all the MSX VDP's are avaliable from the MSXhans website

I tested the program again... seems more like the sprites tripled . Wich is in some way logical behaviour.
At least a behaviour that can be reasoned back to the what is causing this effect.
The test program displays all 32 sprites in the upper part of the screen between the lines 0-64. So they're
all in the first set. By resetting the required bits in r#3 and r#4 (or one of them?) the second and the third
set will become the same as the first (just the VDP's internal source pointers I quess) set.
Now for some reason, when the VDP enters the second set, the sprite coordinates are misinterpeted by
the VDP and line 0 has become line 64 (or is it the otherway around?)). This means the sprite displayed on
line 0 is shown again on line 64... and again on line 128. So in the end the MSX 1 has 96 sprites...
Usefull for a nice star scroll (yes, I found of a use) .

It's time to ask the final question:

GhostwriterP what is your msx model?
do you know which VDP chip it has ?

Sounds quite logical to me too. The program is mirroring the tables and well, its interesting that it has an effect on the sprites as well.
What happens if you only mirror the Color table or the Tiles (i.e. only modify R3 or R4, not both)?