CALL CLEAR - subprogram not found in XB

[ti99iuc]

Hello guys,

i am cataloging always software from Floppy or cassette and now found a new problem for me.

 

this programs in XB (but also some others i found) have the problem that not recognize CALL CLEAR instruction when running it in XB.
How is it possible ? someone have a solution ?

 

SistLineFC.dsk

 

i've tried Classic99 and js99er emulators and have this error on both.

 

I noted that this problem is present with some programs that need lot of memory for execute.
I also tried using the Call Files (0) in classic99 but the problem remaining...

 

 

 

any help ?

Edited February 20, 2018 by ti99iuc

[Sinphaltimus]

I don't know why that happens but I edited the program. I did the following and the program runs..

10 CALL CLEAR

15 GOTO 90

[unhuman]

If that works - you could try just deleting and recreating line 80. Some other munge on the line?

[ti99iuc]

I tried to delete the line and recreated it again but without success

 

I also found a game that do the same problem, i can delete the CALL CLEAR lines at all but it is not normal and the game not execute perfect without it.
Tried also using the RXB Exteded Basic but it is the same.
It is strange because this program should work on real hardware, it is from 1984 about.

[Opry99er]

Maybe Systex has its filthy hands in that line of code?

[Sinphaltimus]

Also, just to point out, there is an error in line 40. I found out by deleting line 10. Looks like a var is missing as there is a :: :: in there.

I still don't know what's wrong. I did a LIST "CLIP" from c99 and pasted to MS notepad then NEW in c99 and copied pasted from notepad, same issue.

[+Lee Stewart]

The first CALL to every subprogram must be included in the pre-scan. You can move the “!@P-” line after the “CALL CLEAR” line.

 

You also need to surround the “CALL SOUND” and “CALL KEY” lines with “!@P+” and “!@P-”.

 

...lee

[Tursi]

The problem is line 60, the "!@P-". This is a magic token that turns off the prescan in order to start up an XB program more quickly. The caveat to using it is that all variables and all CALLs must be defined before it. This is the reason for lines 40 and 50 (also I don't know if OPTION BASE 1 is allowed to be skipped like it is...)

 

Because 'CALL CLEAR' was never seen before prescan was turned off, it didn't recognize it when it was encountered in line 80.

 

It can be fixed, of course, but the faster solution is to delete lines 10 and 60, and replace 40 and 50. It will start up more slowly but it will take less memory.

 

10 REM
40 DIM A(20,20),B(20),X(20)
50 DIM VARIABILE$(20)
60 REM

Replacing 10 with a REM is important, as the program restarts itself with a "RUN 10"... if the line is missing you get a bizarre "LINE NOT FOUND IN 29678" (or similarly high and non-existent line number).

 

I don't know what numbers need to be typed, mind you, to avoid getting "L` EQUAZIONE NON E' CORRETTA", but that should get you a little further.

[+Lee Stewart]

...

OPTION BASE 1 is allowed to be skipped like it is...)

 

It only needs to appear in the pre-scan and before the first DIM.

 

...lee

[ti99iuc]

Very nice infos, thanks guys, i learned some more.

[Retrospect]

Speaking of speeding things up , and I never got the hang of using the !@P thing ... I've been wanting to speed up XB for my Trading type games for ages .... there is a call load that turns off the sprites and they say it speeds up XB, but really , does it speed it up significantly? So if i combined the !@P and the turning off sprites it would make a good difference? Sorry to hijack thread with my question but I could do to know .....

[RXB]

I tried to delete the line and recreated it again but without success

 

I also found a game that do the same problem, i can delete the CALL CLEAR lines at all but it is not normal and the game not execute perfect without it.

Tried also using the RXB Exteded Basic but it is the same.

It is strange because this program should work on real hardware, it is from 1984 about.

Try this instead of CALL CLEAR

 

CALL HCHAR(1,1,32,768)

[RXB]

Speaking of speeding things up , and I never got the hang of using the !@P thing ... I've been wanting to speed up XB for my Trading type games for ages .... there is a call load that turns off the sprites and they say it speeds up XB, but really , does it speed it up significantly? So if i combined the !@P and the turning off sprites it would make a good difference? Sorry to hijack thread with my question but I could do to know .....

PRESCAN is what XB does before any XB program is run.

 

It looks for all Subprogram names including USER DEFINED SUBPROGRAMS. (This is why your program crashed)

It looks for all variables making a list in VDP for String variables names and locations.

It looks for all DEF statements and sets up buffers for it.

It also looks for errors in syntax, line numbers, and FOR/NEXT loops. (Nesting error)

[+Lee Stewart]

Try this instead of CALL CLEAR

 

CALL HCHAR(1,1,32,768)

 

All first-time CALLs must be in the pre-scan. If the first occurrences cannot be easily blocked together, each first time occurrence needs to be surrounded with “!@P+” and “!@P-”.

 

...lee

[Casey]

Speaking of speeding things up , and I never got the hang of using the !@P thing ... I've been wanting to speed up XB for my Trading type games for ages .... there is a call load that turns off the sprites and they say it speeds up XB, but really , does it speed it up significantly? So if i combined the !@P and the turning off sprites it would make a good difference? Sorry to hijack thread with my question but I could do to know .....

I think the best way to make use of the prescan control commands is to do something like the following, after you have your program running successfully of course

 

Let's say your program starts at line 100. Every subprogram call, variable reference, OPTION BASE, and the first DATA statement have to be in the prescan. Note down your variable names and subprograms you use. Then start your program with a new line 10:

10 GOTO 100::CALL CLEAR::CALL HCHAR::CALL KEY::CALL SOUND::CALL SCREEN::CALL INIT::CALL LOAD::CALL SPRITE::CALL DELSPRITE:: !etc
20 A::B::C:::E::F::G
30 OPTION BASE 1::DIM A$(20,20)
40 DATA 1
50 !@P-
100 REM FIRST LINE OF PROGRAM

This way you only have to put the !@P- once in your program. Your CALL statements don't have to be syntactically correct either - the prescan just needs to see the name of the subprogram. Same thing with variables. The prescan just needs to see the variable name - you don't have to assign it a value at this time (but you can!)

Edited February 21, 2018 by Casey

[+InsaneMultitasker]

And if your program is too large to deal with manually, the program Pre-ScanIt! was written just for this purpose. It can also shorten variables and use some of the special symbols like "@" for your most common numeric variables.

 

As pointed out by Tursi, Prescan only impacts how quickly the program starts (not how quickly it runs). The impact can be considerable as your number of variables and CALLs increases. My 85+ sector BBS program starts up within a second or two, versus 25-30 seconds (or more) with prescan left on.

[+Torrax]

There was a program called PreScan It! that would do this. I think you had to save your XB program in merge format.

[Tursi]

Speaking of speeding things up , and I never got the hang of using the !@P thing ... I've been wanting to speed up XB for my Trading type games for ages .... there is a call load that turns off the sprites and they say it speeds up XB, but really , does it speed it up significantly? So if i combined the !@P and the turning off sprites it would make a good difference? Sorry to hijack thread with my question but I could do to know .....

 

Actually, if you never use a CALL SPRITE, most versions of XB have sprite motion turned off anyway. The speed difference is perceivable.

 

Try this in XB. It will just count as fast as it can. When you press a key, it will start moving a sprite - you will see the difference. All sprite motion is turned on at that point. I don't think you can clear it again inside a running program (without CALL LOAD) but it will reset on exit.

 

 

10 CALL CLEAR
20 A=A+1
30 DISPLAY AT(1,1):A
40 CALL KEY(0,K,S)
50 IF S=0 THEN 70
60 CALL SPRITE(#28,65,2,100,100,1,1)
70 GOTO 20

[+OLD CS1]

 

 

Actually, if you never use a CALL SPRITE, most versions of XB have sprite motion turned off anyway. The speed difference is perceivable.

 

Try this in XB. It will just count as fast as it can. When you press a key, it will start moving a sprite - you will see the difference. All sprite motion is turned on at that point. I don't think you can clear it again inside a running program (without CALL LOAD) but it will reset on exit.

10 CALL CLEAR
20 A=A+1
30 DISPLAY AT(1,1):A
40 CALL KEY(0,K,S)
50 IF S=0 THEN 70
60 CALL SPRITE(#28,65,2,100,100,1,1)
70 GOTO 20

 

Woah, sick. A side effect of this is a slow detection of BREAK.

[Retrospect]

Yeah that is a big difference in terms of counting speed. Hey there was something written somewhere in the depths of the interweb, I cannot remember where precisely, but someone said that the original 99/4 had a bug in it's XB version 100 that assumed call motion running on all sprites even when not defined? Have I got this right ... so that would be inheritantly slow, right?

[senior_falcon]

 

 

Actually, if you never use a CALL SPRITE, most versions of XB have sprite motion turned off anyway. The speed difference is perceivable.

 

Try this in XB. It will just count as fast as it can. When you press a key, it will start moving a sprite - you will see the difference. All sprite motion is turned on at that point. I don't think you can clear it again inside a running program (without CALL LOAD) but it will reset on exit.

65 CALL DELSPRITE(#28) erases the sprite and the speed goes back to fast again. (At least by XB standards)

 

This is a good point though. You should always use the lowest number possible for sprites. i.e. you don't want to start at sprite 28 and work down from there!

Edited February 22, 2018 by senior_falcon

[Tursi]

Yeah that is a big difference in terms of counting speed. Hey there was something written somewhere in the depths of the interweb, I cannot remember where precisely, but someone said that the original 99/4 had a bug in it's XB version 100 that assumed call motion running on all sprites even when not defined? Have I got this right ... so that would be inheritantly slow, right?

That is correct.. I don't know if it was a bug so much as a feature they hadn't thought of yet. And like Senior Falcon suggests, the number of sprites moving makes a difference (I didn't know it counted down, too, so that's good!) I did 28 to show the maximum impact.

[RXB]

 

 

Actually, if you never use a CALL SPRITE, most versions of XB have sprite motion turned off anyway. The speed difference is perceivable.

 

Try this in XB. It will just count as fast as it can. When you press a key, it will start moving a sprite - you will see the difference. All sprite motion is turned on at that point. I don't think you can clear it again inside a running program (without CALL LOAD) but it will reset on exit.

10 CALL CLEAR
20 A=A+1
30 DISPLAY AT(1,1):A
40 CALL KEY(0,K,S)
50 IF S=0 THEN 70
60 CALL SPRITE(#28,65,2,100,100,1,1)
70 GOTO 20

Ok just for the fun of it used RXB in Classic99 to show the difference:

10 CALL CLEAR
20 A=A+1
30 CALL HPUT(1,3,A)
40 CALL ONKEY(" ",0,K,S)GOTO 60
50 GOTO 20
60 CALL SPRITE(#28,65,2,100,100,1,1)
70 GOTO 20