Video 17 MBytes
As can be seen in video, the image is divided into 6 equal parts (I think in the 32-tiles mode they will be 5). First 5 (Section 1 - Section 5) are used for rendering plans A and B. Last one, 6 section is used for rendering sprites. You can see that the sections shifted to left (relative to the active raster), which is logical - picture needs a little advance preparation, to compensate for the delay in the schemes. In each section takes place 4 times read from VRAM to SO. Meanwhile, the rest of the time likely to be used by the processor. If you calculate that 40-tiles mode (320 pixels), it will mean that at one section accounts for 40 / 5 = 8 tiles (or 64 pixels), and one subsection 8 / 4 = 2 tiles (16 pixels). Section 6 seems totally preoccupied sprites reading, and shows that sprites coordinate Y is match, and the coordinates of X formed during basic raster drawing. But VRAM speed is limited. And size of sprite buffer inside VDP is unknown. So, maybe this is why we've got that limitation of srites per line?
Next, I switched green color on the serial exit SO4.
Video 14 Mbytes
It has become clear that all information service appeals to VRAM gone and emerged clean image data. However, they are highly compressed horizontally, just do not forget - is only 1 bit of the 8, and the pixel is 4 bits.
On the field VBlank under raster we see processor accessing to memory during treatment interruptions - the same mysterious dots, which sometimes appear there.
So what everyone thinks about this?
PS Sorry for my terrible english.
)
