Need some XB help

[Sinphaltimus]

I know it's pretty early in the morning and my brain hasn't finished spinning up but I don't see whatis wrong.

It should be right here and in plain site but I can't see it.

 

The issue I'm having is pretty straight forward. Here's my code

 

5940 IF YP<>129 THEN 6010

5950 IF LO0T(1,9)<>96 THEN 5970

5960 ZED1=1 :: CALL POSITION(#18,YZ1,XZ1):: CALL POSITION(#1,YP,XP):: DET2=LO0T(2,14)::DET1=LO0T(2,9)::IF XP>=XZ1 THEN ZED1=0:: GOTO 5980

5970 ZED1=0

5980 IF LO0T(1,10)<>96 THEN 6000

5990 ZED2=1 :: CALL POSITION(#19,YZ2,XZ2):: CALL POSITION(#1,YP,XP):: DET2=LO0T(2,14)::DET2=LO0T(2,10)::IF XP>=XZ2 THEN ZED2=0:: GOTO 6670

6000 ZED2=0 :: GOTO 6670

When I run TRACE, everything matches up with what I am observing in game except when it doesn't at the end.

Here is my trace:

<5940><5950><5970><5980><5990><6000>

Everything checks out fine except this: <5990><6000>.

How is it possible that the program is advancing to line 6000 from line 5990 when the last statement in 5990 is a GOTO statement to a bunch of other functions?

OK, I see an unrelated issue. I'm not sure how DET2 gets assigned 2 different times in one line. That is very strange. I wonder if classic99 or my PC is scrambling things up on me.

Edited August 31, 2016 by Sinphaltimus

[Sinphaltimus]

OK something bizzare happened. It looks like a find replace function took place without me beign aware of it. Stilldoesn't explain my issue but there are a bunch of det array statements in my code that wasn't there a few minutes ago. Geeze luiiiiiz

 

Ok so that unrelated weirdness was a mistake I made HOWEVER, the issue persists.

It's happening everywhere in this subroutine.

my code:

6010 IF YP<>153 THEN 6080

6020 IF LO0T(1,11)<>96 THEN 6040

6030 ZED1=1 :: CALL POSITION(#20,YZ1,XZ1):: CALL POSITION(#1,YP,XP):: DET1=LO0T(2,11)::IF XP>=XZ1 THEN ZED1=0:: GOTO 6050

6040 ZED1=0

6050 IF LO0T(1,12)<>96 THEN 6070

6060 ZED2=1 :: CALL POSITION(#21,YZ2,XZ2):: CALL POSITION(#1,YP,XP):: DET2=LO0T(2,12)::IF XP>=XZ2 THEN ZED2=0:: GOTO 6670

6070 ZED2=0 :: GOTO 6670

My TRACE:

<6010><6020><6040><6050><6060><6070>

Edited August 31, 2016 by Sinphaltimus

[sometimes99er]

5990 ZED2=1 :: CALL POSITION(#19,YZ2,XZ2):: CALL POSITION(#1,YP,XP):: DET2=LO0T(2,14)::DET2=LO0T(2,10)::IF XP>=XZ2 THEN ZED2=0:: GOTO 6670

6000 ZED2=0 :: GOTO 6670

 

How is it possible that the program is advancing to line 6000 from line 5990 when the last statement in 5990 is a GOTO statement to a bunch of other functions?

The GOTO is part of the IF. If XP<XZ2 it continues to the next line.

 

You could have this instead to avoid line 6000 ...

 

... ::IF XP>=XZ2 THEN ZED2=0::GOTO 6670 ELSE GOTO 6670

IF – THEN – ELSE

Format

IF relational-expression THEN line-number1 [ELSE line-number2 ]

IF relational-expression THEN statement1 [ELSE statement2 ]

IF numeric-expression THEN line-number1 [ELSE line-number2 ]

IF numeric-expression THEN statement1 [ELSE statement2 ]

Description

The IF-THEN-ELSE statement allows you to transfer control to line-number1 or to perform

statement1 if relational-expression is true or if numeric-expression is not equal to zero.

Otherwise control passes to the next statement, or optionally to line-number2 or statement2.

Statement1 and statement2 may each be several statements long, separated by the

statement separator symbol. They are only executed if the clause immediately before them is

executed. The IF-THEN-ELSE statement cannot contain DATA, DEF, DIM, FOR, NEXT,

OPTION BASE, SUB, or SUBEND.

Edited August 31, 2016 by sometimes99er

[Sinphaltimus]

I thought the :: should end the if statement. Apparently this is a syntax thing. Thanks. I'll drop the goto down and give it a line number to break it away.

[+Lee Stewart]

... Apparently this is a syntax thing. ...

 

No “apparently” about it. It is, indeed, “a syntax thing”. Without an ELSE clause, the IF controls the remainder of the multi-statement line (unless the object of THEN is a line number), which remainder will not get executed when the IF tests false, just as @sometimes99er posted.

 

...lee

Edited September 1, 2016 by Lee Stewart

[Sinphaltimus]

 

No apparently about it. It is, indeed, a syntax thing. Without an ELSE clause, the IF controls the remainder of the multi-statement line, which remainder will not get executed when the IF tests false, just as @sometimes99er posted.

 

...lee

Well it just became apparent to me. Lol

[Sinphaltimus]

Wow, after running through all my code and fixing it. things are magically working better than ever. Learn something new everyday. Thank you guys again.

Just some background. I'm not a programmer by any standards. Never took a class for it, on-line or off besides in JRHS for one semester.
I barely learned basic on the TI as a kid reading the books with no understanding of any of the algebraic math functions.
I learned a little Apple IIe and TRS-80 programming in that class. But I'm a creative at heart. Art, animation, music, video editing, 3D etc..
And the TI made that possible. Then I moved on to the Amiga and that's where all interest in coding went out the door. Because as a kid, I programmed out of necessity, on the Amiga, every program I could ever imagine making was already made and of great quality and well beyond my "programming" experience. I was a closet computer geek well in to my mid 20s and even had a side business in home office PC systems.

Until I joined a company doing network deployments and maintenance. That jump started a real career in IT which still pays the bills.

I was laid off from a company I thought I'd retire with and made a lot of life changing choices, one was to earn a college degree in a subject I loved. Which I did, a 4 year bachelor degree in Game Art and Design. I'm making a fraction of the money I used to because I left the high stakes IT career behind after being laid off and enjoy a lower position with another company, closer to home and pretty convenient. I've worked on several games in the google play store and have made my own. It's not making me money, I have no budget for marketing, but I keep going.

I've learned Game Maker Language which is similar to others like java and C but, as with the TI, my knowledge of that is self learned without discipline or proper understanding of programming best practices. I want to make games, I want to exhibit my art in them and tell my stories. I have a problem getting others to share my vision (programmers) and I can't pay. So here I am, back to programming out of necessity. My skills in GML are far better than my skills in TI Basic or XB but I'm still winging it as best I can.

So yeah, I'm going to run in to simple things that stump me. I hope I don't sound like an idiot. We're all very good at the things we;re all very good at, and the things we're not good at all with, well, we kinda stink at those. All I can do is keep doing what I love.

I came back here because this is where it all started. I want to rel;earn what I've forgotten, I want to learn it better, I want to become a better coder. I want to learn assembly to the extent that I can. and I want the entire experience to make me better in other languages.

I so very much appreciate you all here and thins community. It's all very over whelming really so if i rub you the wrong way or come off like and idiot, maybe it's because I am an idiot at this stuff. So thank you for helping me become less of an idiot. I'm here to contribute any way i can. right now, it's writing XB programs. Soon, it'll be assembly. Maybe someday I won't suck at it.

Edited August 31, 2016 by Sinphaltimus

[+adamantyr]

Speaking for myself, your inexperience is not offensive at all! We're all happy to chip in and help out.

 

I learned TI BASIC and Extended BASIC myself when I was young, age 9 onwards, but I was by no means an expert. I kept trying to learn assembly language but the platform and infrastructure problems confounded me. Given I only had three assembly books, including the reference manual, no computer classes or anything of worth to help out and no internet assistance, this isn't surprising.

 

I got back into programming when I returned to school 15 years ago to complete my B.S. in computer science, and things clicked SO much better. It helps also having such useful and powerful emulation tools like Classic99 that lets you maintain your program as a text file and just copy-and-paste with ease. Assembly also proved much easier to understand... I was incredibly annoyed to find out that the 2nd E/A disk had the source code for Tombstone City, something I could have studied and learned from in my youth. Argh!

 

I only recently discovered how to write assembly language routines that could be utilized from Extended BASIC, when writing "Wizard's Doom". Which is pretty awesome! I have to disagree with the common view that this is the best way to learn assembly language. Unlike other platforms of its era, where you used copious amounts of POKE and PEEK and thus learned a lot about the internals of the system, TI locked all of this off and also complicated things by making all numeric variables floats by default, and offered no integer base type. This requires complex conversions in assembly to pass values back and forth, and actually makes it easier to just start with pure assembly programming.

[Retrospect]

Hey we've all been there, particularly me, with the same thing that got you.

 

The IF statement ..... confusing TI coders since 1979.

[Sinphaltimus]

LOL.

I RTFM as much as I can but I glaze over a lot of it. I was living a completely different reality when I thought this ::

meant a new line of code no matter where it was used. It never occurred to me that it was part of the IF statement. I never related the two at all.
It was only on the same line to conserve space.

When it was explained to me, I just kind of sunk in to my chair. Because I realized I did this EVERY WHERE, even places I never suspected any issues.

 

*sigh*

 

Thank guys. My ineptitude drives me to become better at the things I enjoy. And I am loving all of this. Again.

[+InsaneMultitasker]

, TI locked all of this off and also complicated things by making all numeric variables floats by default, and offered no integer base type. This requires complex conversions in assembly to pass values back and forth, and actually makes it easier to just start with pure assembly programming.

 

Your statements reminded me that TI has XMLLNK routines to convert integers to float and float to integer. It may not be readily apparent from existing documentation that you can use the CFI and CIF functions to aid in parameter passing (edit: from/to XB), especially with so many books and articles focused on pure assembly OR references to the EA BASIC support / MiniMem methods.

CIF    EQU >0020    Convert integer to float
CFI    EQU  >12B8   Convert float to integer
XMLLNK EQU  >2018  XB's XMLLNK routine
NUMREF EQU  >200C  XB's numref  (pass from variable)
NUMASG EQU  >2008  XB's numasg (pass to a variable)
FAC    EQU  >834A
 
       MOV  @VALUE,@>FAC    Put integer value into FAC
       BLWP @XMLLNK           convert to floating point
       DATA CIF               integer to floating point
       CLR  R0
       LI   R1,1              1st variable
       CLR  @>837C            clear status
       BLWP @NUMASG           assign to first variable in the CALL LINK
 
 
       CLR  R0
       LI   R1,1           1st variable in CALL LINK
       BLWP @NUMREF
       BLWP @XMLLNK
       DATA CFI
       MOV  @FAC,@VALUE
 

I started learning assembly within the XB environment. Funnelweb's editor and assembler environment were instrumental in the early days. Most of my initial routines were pretty simple, and I found that writing them as call LINK routines helped me learn what things did, without having to know all the system ins-and-outs. Also, XB + assembly can be quite powerful when their collective strengths are leveraged.

Edited September 1, 2016 by InsaneMultitasker

[+Lee Stewart]

... It never occurred to me that it was part of the IF statement. ...

 

I must confess I had this slightly wrong. It's even more confusing than you thought. After I read Harry's example in Harry Wilhelm's XB 2.0 Compiler, Newb Help Request, I realized that my statement about an IF (without an ELSE) controlling everything following it on the same line was not quite right. The exception is a line number following THEN. Everything else on the same line is treated as an implied ELSE:

 

10 IF X=10 THEN 40 :: A=20 :: B=30

20 ...

30 GOTO 50

40 A=50 :: B=70

50 ...

 

works the same as

 

10 IF X=10 THEN 40 ELSE A=20 :: B=30

20 ...

30 GOTO 50

40 A=50 :: B=70

50 ...

...lee

[Opry99er]

I do not look at it as being necessarily PART of the IF statement (although it is).

 

I view it as a linear section of code with exit clauses.

 

These two short code segments show the behavior. On the surface, they should do the same thing, but they do not. When the IF is performed in line 110, if A is less than or equal to 10, the print command is skipped because the rest of the line is ignored. I am not at a terminal right now, but if I am right, the first chunk of code will print an infinite series of 5s, the second will print:

 

5

6

7

8

9

10

 

 

...and then repeat to infinity.

 

100 CALL CLEAR :: A=5

110 IF A>10 THEN A=5 :: PRINT A

120 A=A+1

130 GOTO 110

 

 

100 CALL CLEAR :: A=5

110 IF A>10 THEN A=5

120 PRINT A

130 A=A+1

140 GOTO 110

[Sinphaltimus]

I probably have to re read it a dozen times.

 

So any if then else statement ending in a line number (essentially a goto will terminate all further processing of that if then statement such as..

 

10 for x=0 to 10

20 If x=5 then 40 :: y=x :: z=6

30 next x

40 end

 

Results in x=5 y=4 z=6

 

 

10 for x=0 to 10

20 If x=5 then y=x :: z=6 :: goto 40

30 next x

40 end

 

Results in x=5 y=5 z=6

 

 

Same would hold true at the end of the else? (Expression vs line number)

[+Lee Stewart]

... So any if then else statement ending in a line number (essentially a goto will terminate all further processing of that if then statement such as..

... Same would hold true at the end of the else? (Expression vs line number)

 

I am not sure I understand your assertion, especially in light of your examples. If we change your examples to print the results each time through the loop and at the end of the program, here is what happens with and without an ELSE clause:

These two examples give identical results:

10 for x=0 to 10

20 If x=5 then 40 :: y=x :: z=6 <---implied ELSE after "then 40"

25 print x;y;z

30 next x

40 print x;y;z

10 for x=0 to 10

20 If x=5 then 40 ELSE y=x :: z=6

25 print x;y;z

30 next x

40 print x;y;z

These two will give different results:

10 for x=0 to 10

20 If x=5 then y=x :: z=6 :: goto 40 :: y=-1 <---no implied ELSE after "goto 40"; "y=-1" never executes

25 print x;y;z

30 next x

40 print x;y;z

10 for x=0 to 10

20 If x=5 then y=x :: z=6 :: goto 40 ELSE y=-1

25 print x;y;z

30 next x

40 print x;y;z

...lee

[Opry99er]

I like to leverage the multi-statement line as a mini-subprogram.

 

100 CALL CLEAR :: X=1
110 PRINT X
120 IF X=5 THEN CALL CLEAR :: CALL SCREEN(9):: DISPLAY AT(10,4):"YAY, X=5... WOO HOO!!!" :: CALL SOUND(200,440,1,880,1):: END
130 X=X+1 :: GOTO 110

[Sinphaltimus]

This whole subprogram thing changes everything. I mean, I use subprograms in other languages and batch files and use script calls before but never did i even think this was something in TIXB. Even as a kid with my first TI, I only had BASIC, not XB.

I'm going to finish my game, but before I do, I'm going to tear it to pieces and rewrite the entire thing. After all, it was just piece meal with no plan - kind of evolved as I went. I think it's time to take the current prototype and start over.

No even with my other experiences woth coding elsewhere, it took me a long time to fully understand the basics of arrays. I know, it's so simple I was brain farted.

But now I'm at the next paradigm shift in my thinking and brain function.

I still cannot understand passing arguments. My programmer friends hate my code. Because no matter how many times they explain it, I just don't get it. I ead the examples in the book and I still don't understand how the passing of arguments to a subprogram (or a script or other function) really works. I need practical examples that I can relate to before the bulb lights up.

[sometimes99er]

This whole subprogram thing changes everything.

It shouldn't. You can live without CALL SUB, but then probably have to use GOSUB - or some challenging spaghetti type GOTO.

 

I'm going to finish my game, but before I do, I'm going to tear it to pieces and rewrite the entire thing. After all, it was just piece meal with no plan - kind of evolved as I went. I think it's time to take the current prototype and start over.

Yep. Code review, restructuring, planning, logic, readability, robustness, comments, re-usability ... There are many reasons and something to learn. At other times, you may feel; if it works, don't touch it.

 

I still cannot understand passing arguments. My programmer friends hate my code. Because no matter how many times they explain it, I just don't get it. I ead the examples in the book and I still don't understand how the passing of arguments to a subprogram (or a script or other function) really works. I need practical examples that I can relate to before the bulb lights up.

CALL SCREEN(11)

 

You just did it. You passed a parameter. The program called SCREEN gets your parameter and does what it has to do.

 

The program SCREEN is already written for you. Excellent. No worries then. - And then sometimes you have to write the program yourself. CALL SHOOT.

 

ROW=5::CALL HCHAR(ROW,1,ASC("*"),256)

 

And it may take more than one parameter. How nice.

 

[Sinphaltimus]

It shouldn't. You can live without CALL SUB, but then probably have to use GOSUB - or some challenging spaghetti type GOTO.

 

 

Yep. Code review, restructuring, planning, logic, readability, robustness, comments, re-usability ... There are many reasons and something to learn. At other times, you may feel; if it works, don't touch it.

 

 

CALL SCREEN(11)

 

You just did it. You passed a parameter. The program called SCREEN gets your parameter and does what it has to do.

 

The program SCREEN is already written for you. Excellent. No worries then. - And then sometimes you have to write the program yourself. CALL SHOOT.

 

ROW=5::CALL HCHAR(ROW,1,ASC("*"),256)

 

And it may take more than one parameter. How nice.

 

 

 

 

OK, I've been spinning my wheels over this for far too long.

 

I get that call screen(11) is me passing an argument. What I don't see is how the clear subprogram utilizes the 11.

 

But in your custom subprogram example, I don't get the part about passing arguments to that. What arguments can you pass and how does the subprogram accept and use them (know what to do with the arguments you enter?)

 

How many arguments can be passed and how does the subprogram have to be structure for them to work properly?

 

This is the area that hasn't clicked for me. I know as soon as it does, I'm going to feel stupid just like i did with arrays and sub but that's OK. I've already accepted that.

 

I just haven't have that AH-HA moment yet with the argument thing.

 

 

[sometimes99er]

I get that call screen(11) is me passing an argument. What I don't see is how the clear subprogram utilizes the 11.

There are only two parameter types, namely numeric and string. A numeric parameter passed can be a number like 11, a numeric variable like VAR5 or a numeric array element like FX(4).

 

CALL CLEAR takes no arguments. Just call it and it does its job.

 

CALL SCREEN takes one argument only, and the type is numeric. That's the definition of CALL SCREEN. Period.

 

Call it and the type of the parameter is checked. CALL SCREEN("A") will say * STRING-NUMBER MISMATCH

 

The parameter is passed and the subprogram may return an error. CALL SCREEN(17) will say * BAD VALUE

 

Your own subprograms has to have a fixed number of parameters. Many of the built-in subprograms are more flexible like CALL COLOR, SOUND and HCHAR. They don't however take any number and types of parameters.

 

But in your custom subprogram example, I don't get the part about passing arguments to that. What arguments can you pass and how does the subprogram accept and use them (know what to do with the arguments you enter?)

The purpose of CALL CARROT is to create one carrot.

 

I define CALL CARROT to take 3 parameters. The first parameter is the sprite no. to create, the second is a column information and the third is row. All three and of the numeric type.

 

I can setup a test program.

 

100 call clear
110 call carrot(1,10,6)
120 call carrot(3,5,18)
130 goto 130

200 sub carrot(i,y,x)
210 print "I got a request to create sprite no.";i;"at column";y;", row";x
220 subend

[Sinphaltimus]

The purpose of CALL CARROT is to create one carrot.

 

I define CALL CARROT to take 3 parameters. The first parameter is the sprite no. to create, the second is a column information and the third is row. All three and of the numeric type.

 

I can setup a test program.

 

100 call clear
110 call carrot(1,10,6)
120 call carrot(3,5,18)
130 goto 130

200 sub carrot(i,y,x)
210 print "I got a request to create sprite no.";i;"at column";y;", row";x
220 subend

 

 

sub carrot(i,y,x)sub carrot(i,y,x)sub carrot(i,y,x)

 

AH HA!!!!!!

[+mizapf]

Another twist to add: If you enclose the variable by parentheses in the call, you can get call-by-value semantics.

 

 

10 I=42
20 PRINT "BEFORE CALL: ";I
30 CALL ROUTINE(I)
40 PRINT "AFTER CALL: ";I
50 PRINT "BEFORE CALL: ";I
60 CALL ROUTINE((I))
70 PRINT "AFTER CALL: ";I
80 END
90 SUB ROUTINE(A)
100 PRINT "SUBROUTINE GOT ";A
110 A=A+1
120 SUBEND

[Sinphaltimus]

That broke me.

OK 10 I=42

OK I=42 so 42 gets printed after the text 20 PRINT "BEFORE CALL: ";I

Alrighty, I'm jumping to line 90 after this for the first time. 30 CALL ROUTINE(I)

 

I=42 gets passed to the subprogram because of line 30 90 SUB ROUTINE(A)

so that A=!=42. We're not really passing 42 to the SUB,

We're really passing I to the SUB and I equal 42 because

we said so in line 10.

Prints 42 after text. 100 PRINT "SUBROUTINE GOT ";A

 

So now A=43 while I still equals 42 in my head. 110 A=A+1

 

Return to where SUB was called from. 120 SUBEND

 

It wants I, well nothing told I to be anything other than 40 PRINT "AFTER CALL: ";I

line 10 so I should = 42. WAIT WAHT!?! It doesn't..

BRAIN BROKE.

 

 

 

How does the value of I change?

To me the relationship is one way starting with 42 and applying it to I then applying I to A.

I can't seem to comprehend how I is getting changed.

 

 

 

[+mizapf]

Quite easy. Just like in C or other languages, the parameters in the SUB list are formal parameters. They take the value of the actual parameter in the call. I has the value 42, and in the (1-element) argument list, A is at the position where the caller put the I. Thus, A is assigned the value of I.

 

The interesting part is that in the first example, not the value but the address of I was passed. That is, when the subprogram changes the value of the format parameter, the value of the actual parameter also changes (call-by-reference).

 

In the second call, only the value is passed (call-by-value). Interestingly, in Extended Basic the caller determines the call semantics, while in other languages, the callee (subroutine) is the one to blame.

[Sinphaltimus]

The wheels are slowly turning. I understood that mostly as I read it the first time very very slowly. I think I get it.

Do I have this correct?

This is call by reference () and this is call by value (())

Call by reference means that what ever is used in the argument (I) becomes a direct reference to that local variable in the subprogram (A) - like entangled particles?

Call by value means just print what I equals without the A relationship? (don't update it to the value of A)

So in order to get to 44 I'd alter this code. Yep, that works like I expected although I'm concerned about how I interpreted your information.

 

 

10 I=42
20 PRINT "BEFORE CALL: ";I
30 CALL ROUTINE(I)
40 PRINT "AFTER CALL: ";I
50 PRINT "BEFORE CALL: ";I
60 CALL ROUTINE((I))
70 PRINT "AFTER CALL: ";I

72 PRINT "BEFORE CALL: ";I

74 CALL ROUTINE(I)

76 PRINT "AFTER CALL: ";I
80 END
90 SUB ROUTINE(A)
100 PRINT "SUBROUTINE GOT ";A
110 A=A+1
120 SUBEND


I'm still a bit foggy but I think I'm starting to get it.