Basic Speedup Tip

[hackz0id]

>Ok, I probably was wrong, but I have a strong feeling FOR-NEXT can do
>stupid things with the stack, in particular in combination with GOSUB.

You're absolutely right about that. The FOR keyword uses the stack to point out the start of the loop for the NEXT keyword. GOSUB uses the stack for return point.

FOR/NEXT actually puts a lot of shit on the stack coz it not only needs to know which line to "NEXT" to but also which token in the line. (the FOR keyword can be anywhere in a basic-line).

Many years ago i often managed to crash my programs and loose them because of my lacking knowledge in this matter.


//MH

[hackz0id]

>So the link pointer is a two byte LSB MSB... So definately line length will
>not affect goto or gosub speed.

True. The only thing that matters is how many lines there are between the first line in the basic program and the line for your "GOTO" target.

I remember from my CBM Basic days when I first started to learn structured programming and using lots of gosubs that ordering the Gosubs so that the ones used often (in loops etc) where placed before the more seldom used ones made a very big difference for the speed of the program.

>I seem to remember some basic list protection where the author would
>mess with these links to hide code in a program.

I even think it's possible to construct very long basic lines if you do it manually (poke them in from a mointor etc.) It's not possible from the basic editor tough because it has a internal limit of 80(?) chars.

[Schlowski]

You can make basic lines as long as 255 bytes. Either manually or with appropriate tools. I've once made sort of 'cross basic editor' for the PC which can generate such long lines.

[carlsson]

I have a small machine code routine for the C64 which allows you to enter such long statements from the Basic editor, IIRC. It should be possible to adapt to VIC-20 without much effort, I hope. Anyone interested?

[CurtisP]

One other thing to remember with GOTO and GOSUB is that the interpretor starts searching with the next line if the target line number is higher than the current line, but with the first line if the target line number is lower than the next line number.

So

Code: Select all

100 FOR X=1 TO 10
110 GOSUB 200
120 NEXT X
190 END
200 PRINT X
210 RETURN

Only needs to skip two lines. Which would only be slightly slower than

Code: Select all

10 GOTO 100
20 PRINT X
30 RETURN
100 FOR X=1 TO 10
110 GOSUB 20
120 NEXT X
190 END

which needs to skip one line.

[Rob Murphy]

Computes Gazette published a program called 'Crunch' for the Vic 20 and C64. It would (on the vic) crunch all basic lines to 255 bytes within the limits of the program you were crunching. The C64 version was a little bit more controlable. It was very useful for sqeezing a few more bytes out of a basic program.

[Boray]

The Programmer's Aid command DUMP lists all the variables in the order they were defined! In other words, in their speed order. So that should be a great tool to use while optimizing. Run your program. Break it in the heavy routine. DUMP. Make adjustments to your program so that the variables mostly used end up at the top of the list.

/Anders

[Jeff-20]

The Programmer's Aid command DUMP lists all the variables in the order they were defined! In other words, in their speed order. So that should be a great tool to use while optimizing. Run your program. Break it in the heavy routine. DUMP. Make adjustments to your program so that the variables mostly used end up at the top of the list.

/Anders

Word! It seems so obvious, but I never do that. I finally get to use that Programmer's Aid cart. I need a list of commands for it.

[Shaun.Bebbington]

I was always under the impression that writing BASIC with line numbers in steps of one was faster than steps of 10 - just means that you need to think about your program first, and not to use too many GOSUB/RETRURN loops. Is this the case?

There's also a way to half the screen outputs (switching on the VICs interlacing mode) - is it POKE 36867,128 or something like that, which seems to free up the processor a little more to interpret the BASIC.

I'm a bit rusty, so I'll have to poke my nose into a reference guide as a refresher

Regards,

Shaun.

[carlsson]

As far as I know, line numbers themselves always are encoded with the same number of bytes, but in e.g. a GOTO, the line number is literal and will be evaluated at runtime. Thus, GOSUB 2 takes less space than GOSUB 2000. Basic also looks from the beginning of the program for the line number, so both the number may evaluate quicker and the actual call is quicker.

To enable interlace, POKE 36864,PEEK(36864)OR128. Interlace is only possible on NTSC VIC-20, and I don't know if it affects processing speed. You can change the number of interrupts per second with POKE 37159 (among others - the VIA chip is mirrored a number of times in memory). If you don't need input or output for a while, e.g. complex calculations in an algorithm, it may be useful to change that value. Default is 72.

[Boray]

I was always under the impression that writing BASIC with line numbers in steps of one was faster than steps of 10 - just means that you need to think about your program first, and not to use too many GOSUB/RETRURN loops. Is this the case?

You don't need to think about keeping the line numbers low while programming, instead you can use Programmer's Aid or similar to renumber the program when it's ready.

[Shaun.Bebbington]

As far as I know, line numbers themselves always are encoded with the same number of bytes, but in e.g. a GOTO, the line number is literal and will be evaluated at runtime. Thus, GOSUB 2 takes less space than GOSUB 2000. Basic also looks from the beginning of the program for the line number, so both the number may evaluate quicker and the actual call is quicker.

To enable interlace, POKE 36864,PEEK(36864)OR128. Interlace is only possible on NTSC VIC-20, and I don't know if it affects processing speed. You can change the number of interrupts per second with POKE 37159 (among others - the VIA chip is mirrored a number of times in memory). If you don't need input or output for a while, e.g. complex calculations in an algorithm, it may be useful to change that value. Default is 72.

Can't remember the exact nature of it, but I did some sort of test way back - I switched interlacing on using a PAL machine and noticed that the test ran very slightly faster with interlacing on rather than off. I also noticed that games written in BASIC that weren't too responsive were slightly more barable to play... like I say, I'm a bit rusty. Will deffo have to get clued up again...!

Regards,

Shaun.

[Boray]

Hmm... I have to test that!

[carlsson]

Well, I just ran a very simple test on my PAL VIC-20:

Code: Select all

1 A=PEEK(36864):POKE36864,(AAND127)OR128-(AAND128):C=0
2 S=TI:FORI=1TO1000:C=C+1:NEXT:T=TI
3 PRINT"36864:";PEEK(36864);"TIME:";T-S

No matter the value of 36864, it runs on about 409 ticks. It may be true that an NTSC VIC in interlace mode runs slightly faster, but I don't know why or how much. As far as I understood, that toggle bit on the PAL model does nothing.

[Boray]

No difference at all when I measured with TI...