Forums

We were discussing https://www.smspower.org/forums/14599-HowManyBytesCanIWriteToVRAMPerFrame in the chat and having some confusion. It seems like the VDP is able to service VRAM accesses at variable rates during different parts of the display because it needs some of that access for itself. There’s a disparity between the pixel output rate (342 per line including horizontal blanking/borders) and CPU clock rate (228 cycles per line), which adds confusion.

I guess the idea is that there is a VRAM “access slot” every 4 pixels at all times; during the “passive” display time these are all available for the CPU but as that’s every 2.62 CPU cycles we cannot take advantage of it. During the rendered part of the display there are apparently “free slots” every 32 pixels (21.33 CPU cycles) but during the other parts there are fewer/none; this manages to add to 10 slots per line but where are they? Are there 9 aligned exactly to the 256 rendered pixels, plus one in the “hblank”, or are there 8 + 2? Either way, they are not uniformly spaced - and how does this then map to the 26 CPU cycles we use to space writes (39 pixels)? Does this 26 cycles spacing just manage to cover the worst-case “slot” spacing, at the cost of not actually managing to hit all 10 slots per line? Could you go faster if you synchronised to the horizontal interrupt?

I guess this is a lot of questions. More simply, where do the “free slots” fit timing-wise with the VDP line timing?

For what it's worth, the Mega Drive scene has looked into Mode 4 access timings behavior on the Mega Drive VDP pretty thoroughly.

Tiido also seems to confirm the behavior is the same on a Master System, at least with the VDP his SMSII had.

(I actually need to thank a friend for finding this information, I'm just linking what they found.)

Quoting for posterity:

Quote

I've been recently working on adding Mode 4 support to BlastEm, so I decided to analyze VRAM traffic so I can get the timing right. This post is to share what I've found. First some general info:
The VDP clocks 4 bytes out of VRAM for each slot, but only the first 2 are actually used. This means it takes 2 slots to read a single tile row.
There are no refresh cycles during active display (seems to rely on the fact that background table reads will cover all pages)
The SAT cache does not appear to be used, so the sprite table scan actually reads the sprite Y coordinates from VRAM
Address mapping is different as Charles MacDonald observed previously (row address represents A8-A1 rather than A9-A2, column address bit 0 remains A0, but bit 1 is now A9 rather than A1. Column bits 5-2 remain A13-A10)
Background rendering starts 12 slots later than in Mode 5. This makes sense because it does not render 2 extra columns to support scrolling like Mode 5 does (an 8 slot savings) and there is only one background (4 slots).
Since Mode 4 is simpler than Mode 5, the access patterns are also simpler. I'm lazy, so I'm not going to draw a nice diagram like Nemesis did for Mode 5. Hopefully, the simplicity of the pattern will make a textual description sufficient. I'll start off with a description of a few types of "blocks", by which I mean a sequence of several slots that is repeated multiple times in a line. Note: "active" sprites refers to sprites that will be drawn on the current line

Sprite Render Block (rendering for 2 "active" sprites):
Sprite N X/Name Read
Sprite N+1 X/Name Read
Sprite N Tile read (1st word)
Sprite N Tile read (2nd word)
Sprite N+1 Tile Read (1st word)
Sprite N+1 Tile Read (2nd word)

Background Render Block (rendering for 4 columns):
Column N Name Table Read
External Slot
Column N Tile Read (1st word)
Column N Tile Read (2nd word)
Column N+1 Name Table Read
Sprite (16+N*1.5) Y Read (Reads Y of 2 sprites)
Column N+1 Tile Read (1st word)
Column N+1 Tile Read (2nd word)
Column N+2 Name Table Read
Sprite (16+N*1.5+2) Y Read (Reads Y of 2 sprites)
Column N+2 Tile Read (1st word)
Column N+2 Tile Read (2nd word)
Column N+3 Name Table Read
Sprite (16+N*1.5+4) Y Read (Reads Y of 2 sprites)
Column N+3 Tile Read (1st word)
Column N+3 Tile Read (2nd word)

Okay, with those building blocks defined, the sequence for a single line is as follows:

2X Sprite Render Block ("active" sprites 0-3)
External Slot
External Slot
HSYNC low
External Slot
External Slot
External Slot
2X Sprite Render block ("active" sprites 4-7)
HSYNC goes high before the tile reads for "active" sprite 7
External Slot
External Slot
Sprite 0 & 1 Y Read
Sprite 2 & 3 Y Read
Sprite 4 & 5 Y Read
Sprite 6 & 7 Y Read
Sprite 8 & 9 Y Read
Sprite 10 & 11 Y Read
Sprite 12 & 13 Y Read
Sprite 14 & 15 Y Read
8X Background Render Block
External Slot
External Slot
External Slot
External Slot

I'd like to thank Charles MacDonald for his previous work on the behavior of Mode 4 on the Genesis as it has been quite helpful.

If I understand correctly then that gives 11 “external slots” per line, but as many are grouped, they are hard to use from the Z80, but may be theoretically useable in a “bus mastering” scenario.

I think it's saying that we have 11 "External Slot" per line plus the 8 that are into the Background Render Block, one each.

The question remain - is during vblank doing more than simply "External Slot"s?

edit: also, I suspect those two "HSYNC..." lines are just annotations, so not using a real slot, as the sum would be 346 'operations' instead of 342.

edit2: also, these lines confirm that the VDP is indeed accessing VRAM with 16-bits reads (and also explains why SAT is organized the way we know):

Quote

Column N Tile Read (1st word)
Column N Tile Read (2nd word)
...
Sprite (16+N*1.5) Y Read (Reads Y of 2 sprites)

Author	Message
Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Timing of VRAM access "slots" during active/passive display Posted: Tue Sep 29, 2020 5:01 pm
	We were discussing https://www.smspower.org/forums/14599-HowManyBytesCanIWriteToVRAMPerFrame in the chat and having some confusion. It seems like the VDP is able to service VRAM accesses at variable rates during different parts of the display because it needs some of that access for itself. There’s a disparity between the pixel output rate (342 per line including horizontal blanking/borders) and CPU clock rate (228 cycles per line), which adds confusion. I guess the idea is that there is a VRAM “access slot” every 4 pixels at all times; during the “passive” display time these are all available for the CPU but as that’s every 2.62 CPU cycles we cannot take advantage of it. During the rendered part of the display there are apparently “free slots” every 32 pixels (21.33 CPU cycles) but during the other parts there are fewer/none; this manages to add to 10 slots per line but where are they? Are there 9 aligned exactly to the 256 rendered pixels, plus one in the “hblank”, or are there 8 + 2? Either way, they are not uniformly spaced - and how does this then map to the 26 CPU cycles we use to space writes (39 pixels)? Does this 26 cycles spacing just manage to cover the worst-case “slot” spacing, at the cost of not actually managing to hit all 10 slots per line? Could you go faster if you synchronised to the horizontal interrupt? I guess this is a lot of questions. More simply, where do the “free slots” fit timing-wise with the VDP line timing?

Flygon Joined: 30 Jun 2016 Posts: 196 Location: Melbourne, Australia	Posted: Wed Sep 30, 2020 2:42 am
	For what it's worth, the Mega Drive scene has looked into Mode 4 access timings behavior on the Mega Drive VDP pretty thoroughly. Tiido also seems to confirm the behavior is the same on a Master System, at least with the VDP his SMSII had. (I actually need to thank a friend for finding this information, I'm just linking what they found.)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Wed Sep 30, 2020 7:30 am
	Quoting for posterity: Quote I've been recently working on adding Mode 4 support to BlastEm, so I decided to analyze VRAM traffic so I can get the timing right. This post is to share what I've found. First some general info: The VDP clocks 4 bytes out of VRAM for each slot, but only the first 2 are actually used. This means it takes 2 slots to read a single tile row. There are no refresh cycles during active display (seems to rely on the fact that background table reads will cover all pages) The SAT cache does not appear to be used, so the sprite table scan actually reads the sprite Y coordinates from VRAM Address mapping is different as Charles MacDonald observed previously (row address represents A8-A1 rather than A9-A2, column address bit 0 remains A0, but bit 1 is now A9 rather than A1. Column bits 5-2 remain A13-A10) Background rendering starts 12 slots later than in Mode 5. This makes sense because it does not render 2 extra columns to support scrolling like Mode 5 does (an 8 slot savings) and there is only one background (4 slots). Since Mode 4 is simpler than Mode 5, the access patterns are also simpler. I'm lazy, so I'm not going to draw a nice diagram like Nemesis did for Mode 5. Hopefully, the simplicity of the pattern will make a textual description sufficient. I'll start off with a description of a few types of "blocks", by which I mean a sequence of several slots that is repeated multiple times in a line. Note: "active" sprites refers to sprites that will be drawn on the current line Sprite Render Block (rendering for 2 "active" sprites): Sprite N X/Name Read Sprite N+1 X/Name Read Sprite N Tile read (1st word) Sprite N Tile read (2nd word) Sprite N+1 Tile Read (1st word) Sprite N+1 Tile Read (2nd word) Background Render Block (rendering for 4 columns): Column N Name Table Read External Slot Column N Tile Read (1st word) Column N Tile Read (2nd word) Column N+1 Name Table Read Sprite (16+N1.5) Y Read (Reads Y of 2 sprites) Column N+1 Tile Read (1st word) Column N+1 Tile Read (2nd word) Column N+2 Name Table Read Sprite (16+N1.5+2) Y Read (Reads Y of 2 sprites) Column N+2 Tile Read (1st word) Column N+2 Tile Read (2nd word) Column N+3 Name Table Read Sprite (16+N*1.5+4) Y Read (Reads Y of 2 sprites) Column N+3 Tile Read (1st word) Column N+3 Tile Read (2nd word) Okay, with those building blocks defined, the sequence for a single line is as follows: 2X Sprite Render Block ("active" sprites 0-3) External Slot External Slot HSYNC low External Slot External Slot External Slot 2X Sprite Render block ("active" sprites 4-7) HSYNC goes high before the tile reads for "active" sprite 7 External Slot External Slot Sprite 0 & 1 Y Read Sprite 2 & 3 Y Read Sprite 4 & 5 Y Read Sprite 6 & 7 Y Read Sprite 8 & 9 Y Read Sprite 10 & 11 Y Read Sprite 12 & 13 Y Read Sprite 14 & 15 Y Read 8X Background Render Block External Slot External Slot External Slot External Slot I'd like to thank Charles MacDonald for his previous work on the behavior of Mode 4 on the Genesis as it has been quite helpful. If I understand correctly then that gives 11 “external slots” per line, but as many are grouped, they are hard to use from the Z80, but may be theoretically useable in a “bus mastering” scenario.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Sep 30, 2020 9:29 am
	I think it's saying that we have 11 "External Slot" per line plus the 8 that are into the Background Render Block, one each. The question remain - is during vblank doing more than simply "External Slot"s? edit: also, I suspect those two "HSYNC..." lines are just annotations, so not using a real slot, as the sum would be 346 'operations' instead of 342. edit2: also, these lines confirm that the VDP is indeed accessing VRAM with 16-bits reads (and also explains why SAT is organized the way we know): Quote Column N Tile Read (1st word) Column N Tile Read (2nd word) ... Sprite (16+N*1.5) Y Read (Reads Y of 2 sprites)

Forums

View topic - Timing of VRAM access "slots" during active/passive display