V9938 VRAM access reverse engineered

All credits go to Wouter for spending the time doing the analysis. All I did was provide the hardware and software to do the measurements on the fair.

Joost

Can you give more details on this 'turbo VRAM throughput' mechanism? I've never heard of it. I don't see how it's technically possible to send data via the CPU to VRAM at a higher (turbo) speed. Is it instead a mechanism that makes sure the data is not send too fast?

Note that (when using a normal Z80 at 3.5MHz) this too fast VRAM access via port #98 issue _rarely_ triggers. An OTIR instruction or a sequence of OUTI or OUT (C),r instructions is all perfectly fine. The only potential problem is a sequence of OUT (#98),A instructions. And only when both display and sprites are enabled.

I do not know what you are meaning, but i've done, in the past, some tests on a pure nms8245. the test ran continuously a highspeed memory move / logical memory move while the z80 was performing a bunch of outi on port 98 and with 32 unmagnified sprites onscreen arranged in 4 rows of 8 sprites each.
The test ran without corruptions or slowdowns at 60hz or 50hz mode on vdp, with a normal z80 @3.57Mhz.

It also appear that the vdp command engine is poorly developed. Some optimizations could have been taken to make short some periods between the "calculate internally" , and "vram access" phases of the state machine

wouter,

Don't be fooled by the neologism.
Maybe I didn't chose a good term: It seems that the two following terms would better express the idea:
- CPU-VRAM throughput control (I/O port 98h)
- CPU-VDP_register throughput control (all other I/O ports)

When using a turbo CPU (IOW, anything faster than the standard 3.57MHz Z80), some kind of throughput control must be used to assure that the I/O speed is done inside the speed limits supported for the V9938/58.

On the V9938 there's no such built-in feature. This VDP wasn't designed with faster CPUs in mind. So all turbo machines containing this VDP will have to implement some kind of throughput control externally.
OTOH, the V9958 was clearly designed to support turbo CPU speeds. A 7.14MHz Z80 can access it's register without trouble, and for VRAM access it has the built-in waitstate generator. This CPU-VRAM waitstate generator controls the throughput so it's always done at the correct speed. But it has to be enabled on one of the V9958 registers (sorry, I don't have the datasheet with me right now).

On the 1st post I listed the throughput mechanism of each native turbo MSX machine. Trying to explain them better:
- The most widely known is the MSX Turbo-R's, done externally by the S1990. It's the heavily criticized "S1990 VDP I/O slowdown". This one reduces the throughput by issuing waitstates to the R800 CPU only. It controls the throughput both for registers and VRAM.
- For the Panasonic MSX2+ machines, there seems to be the "6140140 VDP I/O slowdown". This one *seems* to reduce the throughput by reducing the CPU clock to 3.57MHz much like some homebrew kits. I don't know if controls the throughput only for the VRAM or also for the registers.
- The CIEL ExpertTurbo uses the V9958 built-in waitstate generator. Please have a look at the V9958 datasheet for more details. But it would be very important to sample the V9958 pin-26 behavior to emulate it properly, because this pin will be perfectly synced with the VRAM free access slots you described. If the CPU tries to write data at a moment that it would be lost, a WAIT signal is issued by the V9958. The Victor HC-95T is said to have this feature too, but only an owner of such machine could confirm this by checking the VDP pin-26 connection.
- Last, but not least, is the Victor HC-95V. This one seems to use a combination of the HD64B180 CPU built-in waitstate generator for all I/O, plus a specific BIOS+SubROM for this CPU. The turbo switch on the front panel also switches the BIOS+SubROM set that the machine will use to boot. A very interesting and unusual design. Only a full dump of its dual-BIOS ROM could reveal its mysteries.

By contrast, look at the time slot allocation between video/cpu on the Amiga Original Chip Set. Even in this hw there is some take -over between the blitter and cpu. However, the logic is far more simple (no different ram access modes, fixed timeslot allocation between cpu and blitter with only the option for the blitter to get priority over cpu accesses). Far simpler, far fast. The key difference: a 16 bit data/address bus. Try to think to your timings with a 16 bit bus...

I didn't do any measurements in combination with superimpose, so the following is mostly guessing:

I think a very important aspect of superimpose (and digitize) is that both video signals DO get synchronized. Maybe this is why in these modes the length of a display line is only 1365 clocks instead of 1368, so that there is some slack to be able to actively re-synchronize on each line?? (e.g. re-insert some idle cycles so that the line length matches the external line length)

Anyway, in superimpose mode the VDP still has to fetch bitmap/sprite data and schedule CPU/command accesses. This only works if there are no collisions between all these VRAM accesses. (I don't see a reason why these VRAM accesses will be scheduled differently compared to non-superimpose mode). But this implies that both 'raster' and 'blitter' must be driven by the same clock.

So I *guess* that either:
a) (less likely?) The DLCLK is used for everything in superimpose mode
b) (more likely?) The VDP clock is used, but occasionally there are idle cycles inserted/deleted from the schedule to keep both video signals in sync. If you look at that big timing diagram in my document you see that there are some locations where this could be done (e.g. at t=1328 or t=1336). And indeed these inserted/deleted cycles will have a (small) influence on the speed of command execution (of course depending on what you're comparing with).

... and for emulation none of this matters ... we can 'construct' the emulated crystals so that they don't drift compared to each other ;)

@PingPong: You are right, this is strange. While analyzing the measured data, I found this suspicious myself. So I did double and triple check, and it really does match the measurements (lots of different measurements). I'd be very happy to send you the raw data so you can verify yourself. Also when this schema is implemented in openMSX it produces results that very closely match tests on the real hardware, so I'm fairly confident it is correct.

Wow great stuff!

Glancing quickly thru the document, the port 98 influence is shocking.
The test was with pure OUT and HMMV? I hope that with outi is less slowdown and that HMMM gets less slowdown.

The set adjust is not explored yet, but it is already clear that at least some of the acess will be shifted?
That gap in "left erase signal" is very suspicious.
I would like the diagram to say at which point the vsync goes active.

The test with HMMV and a long sequence of OUT (#98),A instructions slowed down the command approx 2x (in display on, sprites on mode). In all other situations the slowdown will be less. The Z80 instruction OUT(n),A takes 12 cycles, so a long sequence of this instruction sends a request to the VDP every 72 VDP cycles. On the other hand an OTIR instruction takes 23 Z80 cycles (per iteration) or 138 VDP cycles between CPU-VRAM requests. A sequence of OUTI leaves 108 VDP cycles between CPU requests. So this leaves more room for VDP command execution.

Indeed, my *guess* would also be that this large gap is related to set adjust.

I'd like to know this as well. But sorry, our measurements didn't include vsync.

Please make the same speculations on amiga 320x200 screen mode. ;-). there is a huge potential for the blitter, better synched with fixed "access slots".
Anyway, the VDP's blitter could have been designed more cleverly, allowing for a better use of access slots.

@PingPong: What do you want to know _exactly_? The time between the moment the CPU performs the OUT instruction and the moment that data actually gets written to VRAM? Or the minimum amount of time there should be between OUT instructions coming from the CPU? Both are closely related but not 100% the same. I'll assume you mean the latter.

The largest gap between access slots (appears in the mode screen on, sprites on) is 70 VDP cycles. A CPU (or command) request has to be pending for 16 cycles before the VDP starts handling it. So combined there have to be 70+16=86 VDP cycles (or 14.33 Z80 cycles or about 4.0us) between CPU-VRAM requests.

A OUT (n),A instruction takes 12 Z80 cycles and I did verify that a long sequence of this instruction does cause missed VRAM requests. A OUT(C),r instruction takes 14 cycles, that's still (barely) too fast, so I'd expect that a sequence of this instruction also occasionally goes wrong, but I didn't actually test this. I believe that all other ways to send data to the VDP via port #98 should be fine (_any_ instruction in between the above OUT instructions or an OUTI or OTIR).

Does this answer your question?

Yes, completely. thx!

So pratically the v9938 is about twice as fast (in active area) than the old tms.
For others methods of sending data to vram that are not otir, or outi sequence, i think they are rarely used. i can't think a common use of out(c),r or out (0x98),a. the more common otir or outi are instead safe.

Theory: change the adjust register by max 8 pixels every scanline, then no blitter wreck.
(in a scroller it often jumps by 15 pixels)

In the timing diagram, left erase signal, sprites on, the gap between cycle 130 - 162: (162 - 130) = 32 vdp cycles = 8 pixels.

Question is at which point is the adjust register read to delay counter.
And at which point does cpu get irq + jitter and then write the register.

Maybe these questions can be ignored when changing by max 4 pixels per scanline.
Plus above mentioned uncertainties, the cpu will end up changing max 8 pixels per scanline = ok.

Setting the adjust register in 4 steps in 4 rasterlines.
set adjust, wait hblank, set adjust, wait hblank, set adjust, wait hblank, set adjust.

The bitness topic is still bugging me The 9938 gets screen 8 bandwidth by "multi bank", I.e. by acessing two separate memories. CAS0 vs CAS1 in the diagram.

Easy doubling of bandwidth. Except that it smells like needing more wires. Maybe the "board wire cost" is similar to 16bit.

I would say the 9938 practically is 16bit. When it comes to display DMA.

But things look different on the blitter side
it does not do multi-bank, makes it 8bit,
to add insult to injury the LMMM is 4bit,
to further add insult to injury slow logic misses available memory slots.

the byte /pix registers are already sized to the maximum n. of bytes that a pixel color use ( 8 bit).So in this i agree with you.
but:

my guess is that when the vdp, for a copy operation does:
NX-- (decrement the width of the rectangle)
if (NX < 0)
{
NX=oldNX
NY--;
etc.
}
else
{
SX++;
DX++;
}
those operations are performed in 8 bit steps internally like the z80 does for a inc HL.
i suspect the internal logic of vdp is 8 bit, decrements take more than 1 clock, comparisons and decisions even more...

This is only speculation, but I *guess* that internally the VDP command engine runs at 1/8 of the VDP clock. This guess is based on the observation that all command engine operations take an (integer) multiple of 8 cycles. See also the section 'speculation on the slowness of the command engine' in my document.

Assuming this 1/8 clock speed and the overhead of access slot arbitration (again see document), the timing values fit better if add/sub only takes a single cycle. Afterall these values are only 9 or 10 bits wide. I *think* it's actually cheaper in hardware to use a 10-bit adder than to execute the operation in two 8-bit steps. Alternatives are that the add/sub/compare operations indeed take multiple cycles, but that some of these operations are executed in parallel. But this requires even more hardware, so I think it's less likely.

Anyway, lot's of possibilities. But there are no possible tests that can show exactly how the VDP implements this stuff. And because it has no observable effect it also doesn't matter (for us).

@Salamander2,
advram is direct cpu acess to vram. it doesnt change blitter speed.
It asks butchering the mainboard and special software and then get little speedup.
A 9990 cartridge got very much more performance.

@wouter_

As it was common on most digital circuits of the 80s and early 90s, the crystal frequency is probably divided by two right on the input as part of a cheap way to adjust the signal to TTL levels. This means that the real internal VDP clock is probably DHCLK (pin-2, 10.74MHz). I don't know if any of this would matter on emulating it.

The R800 seems to be designed exactly in this fashion: The 28.63MHz is divided by 2 on the input, then the real CPU internal clock seems to be the VCLK pin-74, 14.31MHz, described as クロック出力, that google translates to me as "Clock output". Then this clock is again divided by two to provide the 7.14MHz BUS clock on the SYSCLK pin-72, described as システムクロック出力, that google translates to me as "system clock output", where "system" is probably the motherboard.

The instruction clock cycles shown on the MSX magazine documents about the R800 certainly used the SYSCLK to make things easier for programmers to understand, in a world that would only see commonplace 2x CPU clocks much later, on the 486DX2 CPU.

Oh, yes: And I completely agree that the crystal drifting on the previous posts wouldn't matter for emulation.

@Salamander2

As hit9918 said, implementing ADVRAM on existing machines would be very hard. Speculating, another hypothetic way to speed up the VDP could be to overclock it. But that would require:

1) Provide the CPU clock externally (like a turbo kit)
2) Supply a 5.37MHz TTL clock to the VDP pin-3, taking care that this pin can also be an output.
3) Remove the VDP 21MHz clock and connect it to a software controllable clock multiplier, like the ICS570A. Connect the CLK/2 output of the ICS570A to the VDP clock input. Configure the ICS570A to output x1 by default on CLK/2 output.
4) Change the VRAMs for ones two times faster (-6 minimum)
5) Use the CPU to configure between turbo (x2) or normal (x1) speeds and of course to set the pin-2 as input on boot.

All that is completely a draft and nobody even knows if the VDP can really support such clock. But in theory it could double the blitter speed.

Maybe that would only be feasible for new motherboard designs. But then, if performance is the goal, it would be much better to use the FPGA V9958 code from the OCM. It supports a turbo blitter mode that is AFAICR, 500% faster than the original V9958.

@hit9918

I also agree that the V9990 would have a much better performance than ADVRAM, and both would not benefit any of the existing software. The only way to make the existing blitter intensive games run better is to speed up the V99x8 blitter. And that is only possible by overclocking it or by using a faster implementation in FPGA like the OCM. The OCM runs those games like a dream with CPU & blitter turbos enabled.

@wouter: when you say "the vdp command engine is stalled when a vram request is pending" what are you meaning from the below possibilities ?
[assuming a byte copy operation]
Case 1:
a) Read src VRAM byte
b) write dst VRAM byte
c) internal vdp command register update (increments, decrements, move to next line etc)
d) while (b) is still executing [stall]
e) goto (a)

Case 2:
a) Read src VRAM byte
b) write dst VRAM byte
c) while (b) is still executing [stall]
c) internal vdp command register update (increments, decrements, move to next line etc)
e) goto (a)

Se Case (2) is worst, because does sacrifice a bit of parallelism. The register update, teoretically does not need, to be completed, that vram is available.

What pattern do you think is used ?

I think your assumptions are correct. Unfortunately.

They are good followers (unfortunately) of karl guttag school

@wouther. i suspect that FPGA implementations of vdp are using a less accurate approach. I'm wondering how your findings can be fit on a FPGA implementation of v9938.

@wouter_

What do you think about the possibility that the /DHCLK is probably the real internal clock? Nearly all the clock timings shown are even numbers, except for "15" and "79" on the "Sprites enabled" line. But those two readings seem like a small sampling errors, because both are:

1) Misaligned with respective the reading on the previous lines
2) Break the balance on the size of a sprite read: the first read gets too long, and the consecutive sprite read gets too short.

I did already talk about this with Alex a few times (Alex implemented the command engine in the OCM). He confirms that the current FPGA implementation is very different. E.g. it has multiple adders/comparators in parallel and IIRC it has more available VRAM bandwidth. Alex suspected that the FPGA size of the VDP (in logical elements) could be reduced by implementing it more similar to the real VDP. Though I doubt Alex has concrete plans to work on improving this. (I'm sure he'd appreciate any help).

I *think* this is not the case because if you look at e.g. the timing difference between the RAS and the CAS signals, these differ by only one clock cycle.

About that anomaly for sprites=on at cycle 15 and 79. You can see the same thing at 1251 and 1315. But also at 2, 66, 1238 and 1302. At all these moments there starts a burst read of 3 bytes and it takes 13 instead of the expected 14 cycles (I believe I do mention this in the document). So it's not the case that the first read is taking too long and the second too short. Instead _both_ bursts are too short. I was very suspicious of this result myself, but after double checking I can really confirm this is what the measurements show. Note that without this too short access pattern, the accesses wouldn't fit in the time line.

BTW thanks for looking at these results in so much detail. I do appreciate you verifying my findings.

Reading the first sentence of my previous posting again...
I for sure didn't complain about detailed talk of the timing, that is just great stuff
What I meant is one always ends up in details, then one also gets into mentioning the quirks,
so I wanted to improve the mood by adding the happy sides of the VDP.

@PingPong:
Your 'story' in your previous post is not completely correct. I think there are two main mistakes:

1) You're assuming that all access slots are equal. This would be the case if they are equally spread over time, but they are not. For example in the mode sprites on, there is an access slot at t=170. This is only 8 cycles after the previous slot, but most other slots in this mode are spaced wider apart. I've often seen scenarios where both the CPU and command engine were starved for VRAM bandwidth, but still this slot at t=170 was not always used. So even though there are 31 slots per line, usually not all can actually be used. (Actually even if the slots are all equally spaced apart, there might still be scenarios were not all slots can be used, though it will likely occur less frequently than what is currently the case for the slot at t=170).

2) You assume that a HMMV command at _full_speed_ needs 26 access slots per line. That's not completely true, this is the amount of slots it manages to use in sprites on mode (from the calculations in your post, but see below for more accurate values). But in this mode the command is already limited by available slots. Because e.g. in mode screen off the command runs faster (it manages to use more slots). And even in mode screen off, the HMMV command occasionally has to wait.

Let's look at it from another angle: ideally the HMMV command want to access VRAM every 48 cycles. There are 1368 cycles in a line, so that's 28.5 accesses per line. On average in mode screen off, the HMMV command actually manages to use about 27.9 slots per line. For sprites-off it's about 22.1 slots. And for sprites-on it's about 21.0 slots. All without concurrent CPU access. (That value '50%' I already gave a few times was only a rough estimate .. based on these numbers it seems that 60% is closer to reality.)

@PingPong:
Yes and no. You're correct that in this specific case (HMMV) the total amount of available VRAM-bandwidth reserved to the command engine is _on_average_ large enough to keep up with the command engine. Though this is useless if the command engine cannot effectively use this available bandwidth.

Let's take another example, the YMMM command. The timing for this command is '40 R 24 W'. So in the ideal case, this command wants to access VRAM 42.75 times per line. So clearly for YMMM in mode sprites on, VRAM-bandwidth _is_ a bottleneck. The speed difference for YMMM in screen-off mode vs sprites-on is roughly a factor 1.9x.

I only thought about this just now: Of all the commands HMMV has the highest pixel-rate, but YMMM is the most VRAM-bandwidth demanding. So my prediction that the HMMV is the most affected by concurrent CPU access is probably wrong, YMMM is likely slowed down more.

So really the command engine is slowed down both by the speed of the command engine itself and by the distribution of available access slots. It depends on the situation which of these two factors is dominant, but in all situations both factors need to be taken into account to explain the actual execution speed.

@PingPong,
it is hard to figure what makes blitter speed, lots misc stuff involved.

For example, the 16 cycles for vram slot allocation.
HMMM 64 R 24 W
HMMM (6×8+16) R (1×8+16) W
88 cycles

without the 16 cycles phases, it would be
HMMM 48 R 8 W, it would be 56 cycles, 1.6x faster.

BUT! looking at the typical 32 cycles distance of available slots in display area, rounding things up to multiples of 32,
the result in BOTH cases is
HMMM 64 R 32 W

So now it looks like "the 16 cycles for slot allocation didnt hurt", surprise. The character is "misc".
But in blank area things could be different.

With "no 16 cycles for slot allocation plus fast dream logic", it would be HMMM 32 R 32 W.
Factor 1.5x faster, a bit low for "lots dream logic". Same speed logic with 16bit registers and doublebanked memory use would give 2x speedup.

Speculation about what blitter takes cycles for.

YMMM 40 R 24 W
HMMM 64 R 24 W

looks like SX coordinate business needs 24 cycles.

LMMV 72 R 24 W
LMMM 64 R 32 R 24 W

The LMMV needing 8 more cycles for the first R than LMMM:
Like maybe 8 cycles for LD akku,register (8 cycles is one cycle in the 1/8 blitter clock)

LMMM does read the second byte and complete the OP in 32 cycles:
OP akku,(from memory) in 32 cycles.

Then the first 72 cycles of LMMV is:
24 cycles for SX coordinate business
8 cycles for something unknown
8 cycles LD akku,register
32 cycles OP akku,(from memory)
---
72 cycles, "72 R"

LMMM:
24 cycles for SX coordinate business
8 cycles for something unknown
32 cycles LD akku,(from memory)
---
64 cycles, "64 R",
and then
OP akku,(from memory) in "32 R".

YMMM:
8 cycles for something unknown
32 cycles LD akku,(from memory)
--
"40 R"

LD (memory),akku is allways "24 W".

mhm, does blitter have undocumented opcodes?

So, the speculation written in blitter cycles:

YMMM:
1 opcode decode
4 ld akku,(memory)
;-- "40 R"
3 ld (memory),akku
;-- "24 W"

LMMV:
1 opcode decode
3 SX coordinate
1 ld akku,register
4 OP akku,(memory)
;-- "72 R"
3 ld (memory),akku
;-- "24 W"

LMMM:
1 opcode decode
3 SX coordinate
4 ld akku,(memory)
;-- "64 R"
4 OP akku,(memory)
;-- "32 R"
3 ld (memory),akku
;-- "24 W"

HMMM:
1 opcode decode
3 SX coordinate
4 ld akku,(memory)
;-- "64 R"
3 ld (memory),akku
;-- "24 W"

"SX coordinate" needs much. while in the memory writes there seem to be no such efforts.
more guessing: "SX coordinate" includes routing the nibble in question to low or high nibble of akku.
while when writing, it is more plain "write akku to address DX/2".

now, because of lack of microcode space, HMMM as well as LMMM on screen 8 involves waiting for the same nibble gear, without actualy needing the results
just speculation

I didn't check the VDP datasheet, but isn't that superimpose mode? Where the VDP simultaneously displays the external video source and the normal MSX video.

@PingPong,
9918:
32 + 4*5 sprite
3*32 bytes screen 2
~9 cpu (guess)
--
157 bytes

9938:
32 + 8*5 sprite
128 bytes screen 5 without multibanking
~16 cpu (guess)
--
216 bytes

All these go without multibank. Still 9938 reads much more than 9918.
The document seems to say that screen 5 goes bursting, i.e. without multibank still some bandwidth optimization.
With multibank in screen 8, it is another +128 bytes.

I just counted kind of the bytes I get in the end, 9938 got quite some more.

I found a quote:
"When we did the DRAM interface, we were really pushing the DRAM cycle performance. In fact at the time (1977) running the 9918 at 5.4MHz was considered very fast (most other chips were 3MHz or slower) and doing a DRAM cycle every two clocks was really pushing it."

The 5.4Mhz dotclock is around 342 cycles per scanline, "a DRAM cycle every two clocks", looks like 9918 got 171 slots.
171 potential slots, while on 9938 I observe around 216 real used bytes,
not to speak of the 16bit screen 8 which is a whole different league,
so what is bugging you?

I think the lowest hanging fruit to extend 9938 is 16bit sprite DMA (doublebanking like screen 8).
double sprite DMA would give 64 sprites, 8 per scanline, 16 color sprites, wow!

32*2 = 64 bytes Y DMA.
8*5*2 = 8*10 bytes other DMA. 10 bytes per sprite for X,P,pixels. 8 pixel bytes, 16 pixels in 4 planes -> 16 colors.

This gives more than having double of a slow blitter.
Aside that 16bit blitter would not be double speed, because LMMM still would go in 4bit business.

The sprites for 16bit DMA would need Y bytes in a separate array (I think the sega master got this, too).

I've read somewhere in karl guttag docs that there were only 128 accesses, but also what you found is from karl, so probably you are right, there are 171 accesses.

consider this, please. the actual blitter is not a speedy beast, but i think it is *almost* enough. What make the blitter not enough then?. The missing horizontal scroll register. So you need to scroll by brute force.

Assume for example you have 8 16x16 sw sprites that you manage via vdp cmd. the frame rate is not sooo horrible.
there are few msx2 games that uses sw sprites or sw sprites + vert scroll registers. the results are not sooooo worst in terms of fps. You can even mix those sprites with hw ones used for fast moving objects or bullets.
Obviuously if one use all the limited horse power by using cmd engine to do bruce force scroll, there is no vdp cmd engine power left . Think about the V9958, the things are not so dramatic.

I also suspect that the v9938 had got internally the h. scroll, but was dropped due to time to market reasons, then re-introduced with the v9958.

Note that I never said that ALL V9938 VRAM accesses take 8 cycles. Only the accesses originating from the command engine subsystem are spaced at least 8 cycles apart.

Other VRAM accesses only take 6 cycles for single a single access, 4 cycles for every additional access in a burst and even only 2 cycles if you take multi-bank mode into account. Please reread the "VRAM accesses" section from my document for details.

Also note that you're over-generalizing stuff. You cannot simply count the number of accesses and deduce any meaningful cycle count from this without taking the access pattern into account. Let's take sprite rendering as an example. This indeed takes 32 + 8x6 VRAM reads. And with the _current_ V9938 access pattern all these reads combined take 424 cycles to execute (again see my document). But with another access pattern you can get very different result, e.g. naively assuming each access takes 6 cycles would result in a count of 480 cycles. If the sprite data was fetched in an 'optimal' way (maximally using burst mode, and not re-fetching the y-coord) then the required cycle count could be as low as 322 cycles (if I counted correctly).

I just wanted to show these theoretical numbers (322 vs 424 vs 480) to indicate that the calculations in your last few posts don't make much sense. At least on V9938 you really need to take the access pattern into account.

I already know. i also know that my calculations are approximate. I was applying the same model of TMS VDP (that is more linear) to V9938. on this chip you have a master clock freq., then a n. of clocks for each access slot. So the total access slots is easy to calculate. Plus there are no holes, gaps, or tricky access patterns. A very complex logic without any reasonable advantage.

Even TMS vdp is better/clearly designed, if one take into account the slowest ram & clock speed.

I cannot figure why all memory slot cannot be used. Karl told us there are 8 slot for cpu free...
A scanline is 228 z80 clock ticks. You should write every 27 (this works almost on my sony hb 75p) clock ticks.
228/27=8.4
i'm getting more and more confused...

p.s.
can't argue with amount of slots, can have all slots close and one wide gap.
that is the one for which you got to make the delay code.
the resulting rate can be an odd amount of slots per scanline like 8.4 .

@PingPong,
maybe they just couldn't clock it higher as complex as it is.

Initialy, the 9938 felt like "shortcuts, lack of transistors".
Now I feel it is a luxury chip with all design goals met.
Well, the goal "all transistors for office, no transistors for games".

office commercial:
The TMS philosophy of separate vram allows 16 color hires GUI without cpu slowdown unlike Amiga.
STILL, with LMMC the cpu RAM can easily be used as image RAM.
The blitter design needs little bios code.

The first performance problem in symbos is not GUI, but diskette driver disabling interrupt for a long time, things wobble while disk loading.

A superfluous note I hope: this behaviour has been implemented and released in openMSX 0.10.0.