Hi,

Can anyone tell me the difference between the TMS9929(ANL) and the TMS9129NL?

The former is e.g. in the Yashica YC-64 (which does not run the VDP Pirates demo correctly) and the latter in the Sony HB-201P (which runs that demo fine). Both are PAL. But what's the diff???

I guess that the problem with "mixed mode" is related to the different VDP implementations. Most MSX1 computers do support the mixed mode (screen 2 with just one bank of tiles), whereas some other MSX1 models do not support such mode. This prevents us from producing fast scrolling games for MSX1, 'cause any screen update has to write to three tile banks.

I'm not sure what's causing the slight desynch between machines. The demo doesn't use VDP tricks or mixed modes so it must work on every machine. I've detected that the same MSX with interfaces connected (a FDC for example) changes its timing trashing the demo; but with bare machines I don't see any reason to fail. Maybe it's something related to some VDP/CPU tight timings differences. Are the M1 wait state present on all the machines?, is it the Z80 clocked the same on every machine?

About the TMS versions, I've been looking for their datasheets with no luck until now...

It depends on how the demo syncs to VBLANK and what bios hooks its using if any. The same or similar trick was used in the multi color screen 0 part in MSX Unleashed, and its basically just a matter of adding delay between a fixed sync point (i.e. VBLANK) and when you want to update the foreground color. FDC and other things may interfere with this well timed code.

Another fun demo part to test VDP timing is the last part in Utopia. Also screen 0 playing with bg and fg colors. It works as intended on most MSX1 and MSX2 machines, but not on my VG-8020 for some reason.

Quote:

I'm not sure what's causing the slight desynch between machines. The demo doesn't use VDP tricks or mixed modes so it must work on every machine. I've detected that the same MSX with interfaces connected (a FDC for example) changes its timing trashing the demo; but with bare machines I don't see any reason to fail. Maybe it's something related to some VDP/CPU tight timings differences. Are the M1 wait state present on all the machines?, is it the Z80 clocked the same on every machine? About the TMS versions, I've been looking for their datasheets with no luck until now...

About the M1 wait state, as far as I know it is present in ALL MSX machines (at least first generation).

For the TMS9918A, TMS9928A and TMS9929A DataSheets you can go to the wikipedia en.wikipedia.org/wiki/Texas_Instruments_TMS9918 and scroll down. At the end there is a link to it.

If you are too lazy, here is the direct link
emu-docs.org/VDP%20TMS9918/Datasheets/TMS9918.pdf

Hope this helps!

Gakubuchi "Marc"

Does any MSX1 machines have a separate clock for the Z80 and the VDP? In some cases it seems like it, e.g. the VG-8020, because one scanline on most MSXes takes 228 CPU cycles, but on my VG it seems to take 227 cycles (thats at least what it looks like in the end part of Utopia). Or can there be other reasons for scanlines to take different amount of time on MSX1 machines.

Quote:

Does any MSX1 machines have a separate clock for the Z80 and the VDP? In some cases it seems like it, e.g. the VG-8020, because one scanline on most MSXes takes 228 CPU cycles, but on my VG it seems to take 227 cycles (thats at least what it looks like in the end part of Utopia). Or can there be other reasons for scanlines to take different amount of time on MSX1 machines.

I have the PHILIPS VG8020 Service Manual and the TMS9929A VDP has an external clock of 10,6875MHz connected to pins X1 and X2.


The VG8000/8010 has a "master clock" of 10.738635MHz linked to the CPU clock of 3.58MHz (i guess it uses a /3 divider because 10.738635/3=3,579545)

The TMS9918 Datasheet also suggests using an external clock of 10.738635MHz and a CPU clock of 3,58MHz

---
Gakubuchi "Marc"

Then thats probably why the Utopia demo part doesn't show as intended. I guess the clocks aren't in sync. Its been a while since I did anything with old clock chips, but I vaguely remember that the accuracy isn't that good and its not uncommon to have a 0.5% difference between crystals.

It would be interesting to know which MSX1 machines has a master clock that drives both VDP and Z80 and what MSX1 machines have two clocks.

dvik, many service manuals are online, I guess it's a matter of checking those out.

About the original topic, manuel and me did some tests yesterday. So far the only observable difference is that the 4K/16K selection bit has no effect on 91xx, and fucks up the VDP address on 99xx. Both models support mixed screenmodes and have the sprite cloning glitch.

Thats really cool. blueMSX implements the 4K VRAM decay when the screen is disabled, but I commented out that feature becase some games seemed to not work correctly. Perhaps for next release we can re-add that feature as well as the sprite mirroring and add configuration options for the different MSX1 VDP's.

This is what I mean, copypaste from meisei:

/* data write */
void __fastcall vdp_write_data_4k(u8 v)
{
	read=ram4[address]=ram16[(address&0x203f)|(address<<1&0x1f80)|(address>>6&0x40)]=v;
	address=(address+1)&0x3fff;
	latch=0;
}
void __fastcall vdp_write_data_16k(u8 v)
{
	read=ram16[address]=ram4[(address&0x203f)|(address>>1&0xfc0)|(address<<6&0x1000)]=v;
	address=(address+1)&0x3fff;
	latch=0;
}

/* address/reg write */
void __fastcall vdp_write_address(u8 v)
{
	(...)
	
	/* 4k/16k mode */
	if ((v&7)==1&&(regs[1]^address)&0x80) {
		if (address&0x80) { ram=ram16; io_setwriteport(0x98,vdp_write_data_16k); }
		else { ram=ram4; io_setwriteport(0x98,vdp_write_data_4k); }
	}
	
	(...)
}

from Charles MacDonald's sc3000h.txt ( http://cgfm2.emuviews.com/ ):

 - Bit 7 of register #1 affects how the VDP generates addresses when
   accessing VRAM. Here's a table illustrating the differences:

   VDP address      VRAM address
   (Column)         4K mode     8/16K mode
   AD0              VA0         VA0
   AD1              VA1         VA1
   AD2              VA2         VA2
   AD3              VA3         VA3
   AD4              VA4         VA4
   AD5              VA5         VA5
   AD6              VA12        VA6
   AD7              Not used    Not used
   (Row)
   AD0              VA6         VA7
   AD1              VA7         VA8
   AD2              VA8         VA9
   AD3              VA9         VA10
   AD4              VA10        VA11
   AD5              VA11        VA12
   AD6              VA13        VA13
   AD7              Not used    Not used

   ADx - TMS9928 8-bit VRAM address/data bus
   VAx - 14-bit VRAM address that the VDP wants to access

   How the address is formed has to do with the physical layout of memory
   cells in a DRAM chip. A 4Kx1 chip has 64x64 cells, a 8Kx1 or 16Kx1 chip
   has 128x64 or 128x128 cells. Because the DRAM address bus is multiplexed,
   this means 6 bits are used for 4K DRAMs and 7 bits are used for 8K or 16K
   DRAMs.

   In 4K mode the 6 bits of the row and column are output first, with
   the remaining high-order bits mapped to AD6. In 8/16K mode the 7 bits
   of the row and column are output normally. This also means that even
   in 4K mode, all 16K of VRAM can be accessed. The only difference is in
   what addresses are used to store data.

Ah ok, thats another 4K/16K 'feature'. The one I implemented was the refresh of VRAM when the VDP is disabled. In that case only the first 4K is refreshed so the content of the rest is slowly degrading.