VDP speed curiousity

Page 7/12
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12

By sd_snatcher

Prophet (3505)

sd_snatcher's picture

18-02-2014, 04:43

It's important to clarify: MSXpro's test was executed on a real machine.

(the LCD monitor could suggest that it was run on an emulator, but it's a real MSX)

@MSXpro: Did the red bars really turned blue on the second photo?

By Daemos

Paragon (1964)

Daemos's picture

18-02-2014, 14:04

Quote:

Regarding MSX turbo R:

The R800 is driven by the 28 MHz crystal which is indeed divided internally to 7.16 MHz. Though, you can take that with a grain of salt because in actual fact, an instruction that takes 1 clock cycle on R800 took 1 M cycle on Z80, which is 4 t-cycles (4 clock cycles) on the Z80. So to make the timing tables simpler (so that they don't have to differentiate between M and T-cycles), they have only mentioned the M-cycles and then said that the CPU runs on7.16 MHz and not on 28 MHz.

The VDP in MSX turbo R has it's own clock crystal at approx. 21 MHz, just like in the MSX2 and MSX2+ models. Though, in MSX2 and MSX2+ models, this 21 MHz is divided by 6 to get the 3.57 MHz clock which feeds the Z80 CPU. So on MSX2 and MSX2+, the CPU and the VDP run perfectly in sync as far as the clock is concerned. On the MSX turbo R however, they run slightly out of sync, because the Z80 and the R800 are both fed from the 28 MHz crystal and the VDP is fed by the 21 MHz crystal.

One consequence is that benchmark programs that measure the CPU speed by counting how many times a certain loop can be done during 1 VDP interrupt cycle, give a slightly different result on MSX turbo R then on other MSX models.

I do not know how much of this is actually true. Just interesting to know. This might explain the differences we see.

By msd

Paragon (1472)

msd's picture

18-02-2014, 17:36

The "7.16"MHz kits also use there own clock. With these kits the clocks are also not synchronized

By sd_snatcher

Prophet (3505)

sd_snatcher's picture

18-02-2014, 23:41

Curiously enough, the NEOS MA-20 also use its own clock, which means that the CPU will not be synchronized with it.

By hit9918

Prophet (2923)

hit9918's picture

19-02-2014, 02:33

I always thought that if the cpu is not on same crystal as video it could make a 1 cycle difference in maximum port IO.
But, a dotclock cycle is 0.66 cpu cycles! So there never is a 1:1 relationship.

By hit9918

Prophet (2923)

hit9918's picture

19-02-2014, 03:18

About the CIEL.
Picture ratio looks like 60Hz. 3.5Mhz hits the K like 60Hz MSX2.
It is nessesary to sort out that first because PAL vs NTSC has different scale.

And then the 7Mhz pic reaches a speed record Smile Better than TurboR.
If my calculations got no bug, transfer is factor 1.6 faster.
It is not 2x, so looks like the WAIT pin is doing its thing and without it would have trashed.

That would be on my MSX3 wishlist Wink

By hit9918

Prophet (2923)

hit9918's picture

19-02-2014, 03:21

It would be interesting to see screen 1. It has sprites, DMA is like screen 2, likely like screen 5.

By Piter Punk

Master (224)

Piter Punk's picture

20-02-2014, 02:41

Tested in a Expert 2+ (Gradiente Expert with ACVS 2+FM upgrade kit); red background from A to K. L is blue.

By MSXPro

Resident (48)

MSXPro's picture

20-02-2014, 08:44

Quote:

@MSXpro: Did the red bars really turned blue on the second photo?

Is a light red bars, because high speed flickering. But camera is not fast to capture a real color. Wink

By hit9918

Prophet (2923)

hit9918's picture

20-02-2014, 18:01

Oh it was flickering. When looking at it, I payed no attention, that is not red.

It looks like every second frame the cpu doesnt get the vblank bit from status register. Then color keeps all blue that frame.
In one frame is the record speed transfer, but then a whole frame is lost, technicaly speaking it's the slowest machine Tongue

I heard on 9918 one can loose events, but thought it was fixed on 9938.

cpu reads status register, which clears the event bit, and when at same time VDP wanted to update, the event is lost.
I dont know what is going on. Was 9938 fixed only on the newer event bits like line interrupt, I dont know.

In a game using interrupt server that problem doesnt appear.
I did disable interrupt and just check status bit.
But I still wonder whether that is the issue or something else is going on.

The trash chars on the screen is the code copying itself to vram at location 768.
Actually only some dozen bytes are the code, rest is what happens to be in RAM behind it.
Both pictures look same, the vram transfer did happen properly.

Page 7/12
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12