It is interesting to see that some tests are really fast on r800 mode and some suffer from the 8 us penalty. I wonder what the difference is. Perhaps we could device a trick by looking at these numbers to invent a workaround towards the wait problem.
About the R800 there is no question, the question marks are about MSX2+ being some percent slower.
R800 gets throtteled to an OUT rate of MSX1 level, but can do loads instructions in between two OUTs.
In plain copy to vram it is slower, while with cpu AND OR masking ado involved it is faster (or rather, ordinary z80 stalls much in that case).
I think wouter put lot of it into emu when hacking the doom demo.
The emu code mars quoted seems to be only about R800, no MSX2+ hint.
The emu code mars quoted seems to be only about R800, no MSX2+ hint.
No, I have included the differences between R800 mode and Z8O mode what concerns the additionnal delays for VDP with T9769 and S1990.
delayVdpIO(r800, port) concerns also the z80, as BOARD_MSX_T9769B is for Panasonic/Sanyo MSX2+.
Actually, r800 is used in the blueMSX code most of the time for z80 (the 2 first excerpts come from R800.c in Z80 section of the source, there is no any Z80.c file).
Didn't knew that one. So basicly the cpu clock in the T9679x is fed externally?
Yes, the clock on an MSX machine is always generated externally to the MSX-engine.
On a non-turbo MSX, the CPU clock always generated by the clock circuitry generator built-in the VDP, as this was meant to save the cost of a second crystal.
On a turbo MSX, the turbo clock is generated by the turbo circuitry, usually containing a specific crystal. On some home-brew kits, the non-turbo clock will be generated there as well.
ok, here a new benchmark.
benchmark doing a clear thing, disable interrupt and otir and rasterline display.
Tell the letter that the beam reaches.
On bluemsx MSX2 hits the E, while MSX2+ hits the F.
10 clear 200,&hd000 : p% = &hd000 'loading asm there
20 defusr0 = p%+2
30 restore 10000 : gosub 5000 'load asm code
60 key off : screen 0
64 for i = 0 to 23 : ? : ?chr$(65+i); : next
70 x=usr(0)
4999 STOP 'when above code forgot END
5000 read a$ : if a$ = "END" then return
5010 poke p%,val("&h"+a$) : p%=p%+1 : goto 5000
10000 DATA 30,00,F3,DB,99,07,30,FB
10010 DATA 3E,B6,D3,99,3E,87,D3,99
10020 DATA 0E,98,1E,06,21,03,00,3E
10030 DATA 00,D3,99,3E,43,D3,99,06
10040 DATA 00,ED,B3,1D,20,EE,3E,F4
10050 DATA D3,99,3E,87,D3,99,18,D3
10060 DATA END
F means worse than E, cpu took some longer till changing color register to blue.
at the bottom border is vblank interrupt, there program makes color register red and starts working.
at very bottom the TV beam jumps over to the upper side of the frame and then the red paint continues on the upper side.
a usual rasterdisplay. getting fine grained feedback. especialy for game coding.
a rasterline is like 228 cycles wide.
horizontal wobble means that is how the program came imprecise out of a vdp status test for vblank bit.
can't sync cycle exact.
on NTSC machine the beam pops up earlier on the top border, the poor NTSC machines have less blank time.
then in the end this benchmark ends up in lower letter on NTSC.
must be stressed again that same performance makes different display similar to "BASIC TIME" that is incremented each vblank.
It can be visualy seen how the NTSC machine will earlier hit the lower border again and then loose frames.
A simple rasterline thing, I thought is more clear than the big unknown benchmark code.
