SC5/SC8 speed with xbasic

Resident (45)

21-04-2007, 10:23

Hi,

I am currently coming back to MSX basic and yesterday, I was testing the speed of the COPY function with xbasic (I love it ) on BlueMSX.
The test program is that one :

5 POKE &HFBB0,1
10 SCREEN 8 : DEFINT A-Z
20 SET PAGE 1,1
30 _TURBO ON
40 FOR I=0 TO 255
50 LINE (I,0)-(I,211),INT(RND(1)*15)
60 NEXT I
70 SET PAGE 0,0
71 FOR X = 1 TO 200
80 COPY (0,0)-(128,130),1 TO (INT(RND(1)*255),INT(RND(1)*211)),0
90 NEXT X
110 STOP

(ugly but it's not the matter )
What I don't understand is that the test runs faster with screen 8 than with screen 5.
Any idea somebody ?

By GhostwriterP

Paladin (683)

21-04-2007, 10:29

xbasic uses HMMM copies in screen 8 and LMMM in screen 5. Try tpset in the copy syntax
or copy per 2 pixels in screen5.

By Sonic_aka_T

Enlighted (4130)

21-04-2007, 10:30

arf, I hate it when that happens!

By Sonic_aka_T

Enlighted (4130)

21-04-2007, 10:30

Not really sure how xbasic works internally, but probably the copies you're doing in SCREEN5 are handled are logical copies instead of byte copies, most likely due to the x-coordinates being odd (as in not even). Byte copies are roughly 3x as fast as logical copies, so even screen8 (which always does a byte copy when not using a logical operation) with twice as much data will be faster than screen 5 doing a logical copy. Note that MSX-BASIC always uses logical copies, so this phenomenon does not occur. Try changing the coordinates on screen 5 to multiples of 2, most likely XBASIC will then do a byte-copy on screen 5 as well.

By dumfrog

Resident (45)

21-04-2007, 10:45

I have just modified
80 COPY (0,0)-(128,130),1 TO (INT(RND(1)*255),INT(RND(1)*211)),0
to
80 COPY (0,0)-(127,129),1 TO (INT(RND(1)*255),INT(RND(1)*211)),0
and it works (it takes the same time now) ! Thanks a lot (I still have much to learn).

But shouldn't it be faster anyway in screen 5 (less bytes to copy) ?

By AuroraMSX

Paragon (1902)

21-04-2007, 11:31

But shouldn't it be faster anyway in screen 5 (less bytes to copy) ?Maybe the COPY itself isn't the issue. All those RND()'s and INT()'s may take up more time than the COPY...

By NYYRIKKI

Enlighted (6067)

21-04-2007, 12:43

X-basic is faster in SCREEN 5 when source, width and destination X-coordinates make full bytes, so test it like this:
80 COPY (0,0)-(127,130),1 TO (INT(RND(1)*127)*2,INT(RND(1)*211)),0

By ARTRAG

Enlighted (6935)

09-01-2008, 14:57

To be sure :

Does xbasic really use byte copy in screen 5 if x coords and width size are even ?

Does xbasic test the values in the coordinates before sending the command or it is possible to switch to byte copy using some magic compilation flag?

Does anyone have an exhaustive manual (in English) describing xbasic compilation flag?

By Manuel

Ascended (19462)

09-01-2008, 22:49

There are only very few flags, which can be inserted as comments in the basic program. ARTRAG: do you know that this is an on-the-fly compiler?

By ARTRAG

Enlighted (6935)

09-01-2008, 23:10

well, even as on fly compiler, it should have a manual

By [D-Tail]

Ascended (8263)

10-01-2008, 00:15

ARTRAG: it *has* a manual. It's just not as widespread as the tool itself . For the compiler flags:

'#I ;Inline ASM!, just put the opcodes here. E.g.:

100 GOSUB 120
110 END
120 '#I &HC9 ; ret

'#C ;Set clipping ON (only for graphics modes). E.g.:

100 COLOR 15,0,0: SCREEN 5
110 '#C-
120 LINE (0,0) - (255,255), 15 ' Y clipped, they use some weird negative logic :P
130 '#C+
140 LINE (0,255) - (255,0), 8 ' Y not clipped
150 GOTO 150

'#N ;Checks if NEXT overflows [took this straight from the manual]. E.g.:

100 FOR I% = 0 TO &H7FFF
110 NEXT I%

This will overflow in BASIC. In XBASIC (when run with _RUN), it will loop endlessly. When '#N+ is specified, it will terminate normally, at the expense of extra overhead and loss of efficiency. '#N- clears this setting.

About speculative copying: yes, XBASIC *does* determine whether to use HMMM or LMMM. I don't know for sure if it uses YMMM as well. Direction flags should be [oddly enough] specified inside your co-ordinate tuples. One of the VDP copy registers has a direction vector, indicating in which direction the to-be-copied-part should go. XBASIC looks at how you define your copy. E.g.:

100 SCREEN 5: BLOAD "SOME_GFX.GX5",S: COLOR=RESTORE
110 COPY (128,0) - (143, 15) TO (112,0) ' Is treated different from
120 COPY (143,15) - (128,0) TO (112,0) ' This one
130 GOTO 130

I accidentally found out about this when I tried to make a text-scroller which scrolled from left to right instead of normally right to left. Using 2px movement per int I found out that the VDP-feature of magically copying strikes when you try to copy in the intuitive way (using Xlow, Ylow - Xhigh, Yhigh TO Xdest, Ydest).