Hi, just new here!

Just a question 'cause it still is completely unclear to me: What exactly happens when you write too fast? Do you just see some carbage on screen or isn't the vram filled at all? And is it possible to write fast if the vdp's output bit is disabled?

I'm kind of interested in taking my fake msx (SV328, whaha) from the attic and create some kind of screen 2 animation demo using a in mem framebuffer... Do you guys know some good crossassemblers or so?

reg,

Danny

It will usually result in garbage (on screen if it's visible vram). If the display is off, it should be the same as during vblank. So full speed is possible.

...and there're plenty of cross assemblers out there. You can try with sjASM, asMSX, TNIasm or Pasmo, being all of them very capable to work with MSX/SVI328 oriented code.

Ok thanks for the answer guys!

Here is what I like to do:

* Create a method that fills a horizontal line in the mem buffer from x1 to x2. Should be quite easy to determine the bytes starting and ending the line and it is easy to fill the bytes in between using some precalculated stuff.
* Create a method that is able to create filled polygons. This should be quite easy if I precalculate the direction coefficents of each vertice.
* Create a method that dumps the patterns to the VDP, ideally in 1/50th of a second with VDP turned off.
* Create a few polygon based animations... Hopefully it will do about 10fps but I doubt it...

Sure other people already did it, sure the 3.58Mhz won't perform at all, but hey, it's fun to try for once!

Anyway, this is a usefull page: bifi.msxnet.org/msxnet/tech/tmsposting.txt. The guy states it should be possible to write the vdp every 2 micro seconds during any blanking period. Obviously that Z80 won't manage this transfer speed right? So would a burst of "outi" looped with jr z work to reach maximum transfer speed?

reg,

Danny

Quote:

Ok thanks for the answer guys! Here is what I like to do: * Create a method that fills a horizontal line in the mem buffer from x1 to x2. Should be quite easy to determine the bytes starting and ending the line and it is easy to fill the bytes in between using some precalculated stuff. * Create a method that is able to create filled polygons. This should be quite easy if I precalculate the direction coefficents of each vertice. * Create a method that dumps the patterns to the VDP, ideally in 1/50th of a second with VDP turned off. * Create a few polygon based animations... Hopefully it will do about 10fps but I doubt it... Sure other people already did it, sure the 3.58Mhz won't perform at all, but hey, it's fun to try for once! Anyway, this is a usefull page: bifi.msxnet.org/msxnet/tech/tmsposting.txt. The guy states it should be possible to write the vdp every 2 micro seconds during any blanking period. Obviously that Z80 won't manage this transfer speed right? So would a burst of "outi" looped with jr z work to reach maximum transfer speed? reg, Danny

jr istructions are slower than jp especially if conditioned.

Hi,

Well, I just have this: www.smspower.org/dev/docs/wiki/?n=Z80.InstructionSet... I think the books we had are still at my folks house, just as the 328 is.. Anyway, I recon you are right about the JP speed! With bursts of 16 OUTIs a time it would save 0.2 ms a frame if I'm not mistaken.

I'm not sure about the SVI328 timing; but be aware that the Z80 running on the MSX machines has a penalty of one refresh cycle for every normal instruction and two refresh cycles for instructions which begins with CB, ED, DD, FD, DDCB, or FDCB. So, talking about JP, it tooks 11 T-states to execute, not 10 T-states like on a standard Z80.

Quote:

Since I don't have a real MSX anymore I've to develop and test with emulators (I mainly use BlueMSX). Does somebody here have a real MSX and live around Hasselt or Leuven, Belgium ? So I can try my game before I submit it to the MSXDev. Thx

I live in Leuven. You can contact me via be019888@tiscali.be

Kind regards,
Alex Wulms

Bored.... Just want to show off what I learned ;-)

Quote:

Even during the non-blank you can copy at the same speed without delays. I've been able to copy 3,5 KB (lower part of the screen) per frame at 50 Hz without introducing any delays, just a pure 3,5x1024 OUTI program block Quote: Let me guess, you disabled the screen?

Ok, read this eyeopening story from Marat Fayzullin first: bifi.msxnet.org/msxnet/tech/tmsposting.txt and get your calculator.

Marat describes the NTSC version. PAL and NTSC tv signals both utilize about the same bandwidth. So basically, NTSC transmits as much single scanlines as PAL does in a given period of time. However, since PAL has 50 fps instead of 60fps like NTSC has, a PAL frame consists of more scanlines (312 versus 262 I believe). Now, since both the PAL and NTSC versions of the TMS chip generate 192 vertical lines and PAL has more vertical lines PAL has a bigger vertical blanking area (top and bottom screen borders).

A scanline takes 64us to draw if I'm not mistaken. So drawing 192 lines takes 12.29ms. A PAL frame is 1/50th second. So the PAL blanking time is 20-12.29=7.71ms.

Now say that we would unroll an OUTI loop, this would mean we write every 18 Z80 cycles. A cycle is 0.28us so, so it would take 5.04us to out a byte to VDP. So in theory it should be possible to write about 7.71ms/5.04us=1529bytes during vertical blanking(!).

Now there still is the display period left: 192 scanlines of video. Lets see what Marat says: the VDP utilizes every 16th memory cycle to the Z80 (or whatever CPU). So.... The NTSC version of the TMS has 372ns ram chips. Since PAL uses a higher color burst frequency rate the speed requirements might be even 300ns. But I'm not sure whether that's the case (the TMS docs only describe the 9918). Lets just stick to the slower NTSC timing. Every 16th memory cycle would be every 5.95 us.

Marat explains the available memory bandwidth per line is 171 bytes. So if it is allowed to write every 16th cycle it should be possible to write about 192lines*172bytes/16 = 2052 bytes(!). Drawing 192 scanlines takes about 12.29ms so the write interval is about 5.99 ms. So a long burst of OUTIs would be too fast for this. Adding a NOP to each OUTI would add 5 cycles so it would take 6.44us to out a byte.

So in the end, being completely save, it should be possible to write about 12.29ms/6.44us = 1908 bytes during display period. Plus the 1529 bytes one can write during vblanking gets you to a total of 3437 bytes...

BTW to tweak the throughput during display period to the full 2052bytes I guess one could do 2 OUTIs in a row followed by a NOP. The VDPs buffer should be able to average the timing. Might still be too fast though... Never tried it anyway... (the latter is kind of funny... when I was like 14 years old I hacked some parts in code since it was faster than basic... however optimizing the code didn't occur to me those days haha).

(Note, the numbers aren't completely accurate because of rounding error... If every 16th cycle is 5.95us it is possible to transfer 12.29ms/5.95us=2065 or so, and since computers always think in bytes it will most probably by 2048 bytes)

Hope somebody finds this usefull

Danny

Most discussion here is about wait states required when bytes are written to VRAM. But 2 other questions are:
1. Do we need wait states between the 2 writes to the command port (99h)?
2. Do we need wait states between the second write to the command port and the first write to the data port?