Jump to content
Old Timey Retro Gamer

Monkey Moon program in Oscar's book

Recommended Posts

Hello everyone,

  I recently bought Oscar's book. I am having a problem that I hope I can solve with some help. On the game "Monkey Moon", I had written the program as it was listed in the book, but after I compile it and run it, all I get is a blank screen.  I tried to copy & paste the book as well, and I still get a blank screen.  Just to make sure that my program was not screwed up, I wrote the code (before the actual game) to Clear the screen, put a title on it, and to use the controller to move on.  It displayed my title, but when I pressed the disc, it went blank again. 

I am just curious, if someone may have an idea what I can look for to solve the issue.  I am wondering since the Intybasic program was updated since the book, if it had any affect, or perhaps something was incorrect on the book.  Would anyone know, or does the code work for you guys?

Share this post


Link to post
Share on other sites

I just compiled and ran the code from the book when I did the exercise, and it ran just fine.

 

I have IntyBasic compiler v1.4.2  Jun/01/2020

 

I'll assume you didn't get any compiler errors?  Also, do your other exercises work fine?

 

did you do all 3 steps like this, I'll assume you did but might as well check?

 

1) COMPILE 
intybasic filename.bas filename.asm
2) ASSEMBLE
as1600 -o filename filename.asm
3) RUN
jzintv -z3 filename 
 

Edited by Mik's Arcade

Share this post


Link to post
Share on other sites

Also are you inserting code at the locations the book tells you to, so you don't concatenate the new code after the previously input one?

Share this post


Link to post
Share on other sites
44 minutes ago, carlsson said:

Also are you inserting code at the locations the book tells you to, so you don't concatenate the new code after the previously input one?

Yes.  I believe everything is in place.  The only part that I thought was not very well explained was where it stated to put the DATA screen in. But I believe it is in the right spot (after the Constant assignment).

Share this post


Link to post
Share on other sites
1 hour ago, Mik's Arcade said:

I just compiled and ran the code from the book when I did the exercise, and it ran just fine.

 

I have IntyBasic compiler v1.4.2  Jun/01/2020

 

I'll assume you didn't get any compiler errors?  Also, do your other exercises work fine?

 

did you do all 3 steps like this, I'll assume you did but might as well check?

 

1) COMPILE 
intybasic filename.bas filename.asm
2) ASSEMBLE
as1600 -o filename filename.asm
3) RUN
jzintv -z3 filename 
 

Yes. There were no errors.  Just curious, would you be able to download your text document, and I would like to see if my program will run it?

Share this post


Link to post
Share on other sites

So you have this order?

 

CONST MOB_LEFT = ...

...

CONST PD = ...

 

level1_cards:

  DATA ...

 

  CLS

  MODE 0,0,0,0,0

  ...

 

On page 45 it says that level1_cards should be at the end of the source code at that point. On page 49 you also have controller_direction right before level1_cards, which could suggest you have flipped around quite a bit of code and data when you typed it in.

Share this post


Link to post
Share on other sites
4 minutes ago, carlsson said:

So you have this order?

 

CONST MOB_LEFT = ...

...

CONST PD = ...

 

level1_cards:

  DATA ...

 

  CLS

  MODE 0,0,0,0,0

  ...

 

On page 45 it says that level1_cards should be at the end of the source code at that point. On page 49 you also have controller_direction right before level1_cards, which could suggest you have flipped around quite a bit of code and data when you typed it in.

Yes.  This is the order that I have it in. The page 45 code is the one where I was not sure if it was correct (the way is says should be at the end of the source code) but that's where I have it.  

Share this post


Link to post
Share on other sites
10 hours ago, Old Timey Retro Gamer said:

Yes.  This is the order that I have it in. The page 45 code is the one where I was not sure if it was correct (the way is says should be at the end of the source code) but that's where I have it.  

OK, I think I see it.  At the end of page 45 if says "And now we use these constants for defining the screen adding this at the end of the source code:"  (emphasis added)

 

That is followed by the "level1_cards" data.

 

However, from what you show above, you have your "level1_cards" data sandwiched between the constants definitions (CONST) and the program code (CLS, MODE ...)

 

Just to be clear of what this means:  IntyBASIC (like other procedural programming languages) executes your code from top to bottom.  As it runs through the program line by line, it attempts to execute it.

 

In a typical program, where you have all your code at the top and your data at the bottom, the program will be executed one line at a time, and presumably end with a loop or some other branch before entering the data itself.

 

For example:

' Blah blah blah code
'
'
MyProgram:
	CLS
	MODE 0,0,0,0

' Blah blah blah more code ...

GOTO MyProgram

' Data goes here but the execution never reaches this part.
DATA 0
DATA 1
DATA 2
DATA 3

 

Think if you were following the code from the top, by the time you reach "GOTO MyProgram" (or whatever other statement loops or branches at this point), you never fall through to the DATA part.  It is just there for your program to reference using READ or PEEK or whatever, but never reached as part of the execution flow.  It is essentially outside the flow of the program itself.

 

If instead you put the data part in the middle, some place where it is actually within the execution flow of the program, guess what's going to happen?  That's right:  It's going to be treated as "code" and the CPU will attempt to execute it.  Since it was not intended to be code at all, whatever interpretation the CPU makes for each piece of data will be wrong, and your program will behave in unpredictable ways.  It will most likely crash.

 

I believe that's what is happening in your code if indeed your data is before the program itself and not at the very end of the program, tuck neatly out of the way.

 

If you'd like to post your code here, we could review it.

 

      -dZ.

Share this post


Link to post
Share on other sites
1 hour ago, DZ-Jay said:

OK, I think I see it.  At the end of page 45 if says "And now we use these constants for defining the screen adding this at the end of the source code:"  (emphasis added)

 

That is followed by the "level1_cards" data.

 

However, from what you show above, you have your "level1_cards" data sandwiched between the constants definitions (CONST) and the program code (CLS, MODE ...)

 

Just to be clear of what this means:  IntyBASIC (like other procedural programming languages) executes your code from top to bottom.  As it runs through the program line by line, it attempts to execute it.

 

In a typical program, where you have all your code at the top and your data at the bottom, the program will be executed one line at a time, and presumably end with a loop or some other branch before entering the data itself.

 

For example:

' Blah blah blah code
'
'
MyProgram:
	CLS
	MODE 0,0,0,0

' Blah blah blah more code ...

GOTO MyProgram

' Data goes here but the execution never reaches this part.
DATA 0
DATA 1
DATA 2
DATA 3

 

Think if you were following the code from the top, by the time you reach "GOTO MyProgram" (or whatever other statement loops or branches at this point), you never fall through to the DATA part.  It is just there for your program to reference using READ or PEEK or whatever, but never reached as part of the execution flow.  It is essentially outside the flow of the program itself.

 

If instead you put the data part in the middle, some place where it is actually within the execution flow of the program, guess what's going to happen?  That's right:  It's going to be treated as "code" and the CPU will attempt to execute it.  Since it was not intended to be code at all, whatever interpretation the CPU makes for each piece of data will be wrong, and your program will behave in unpredictable ways.  It will most likely crash.

 

I believe that's what is happening in your code if indeed your data is before the program itself and not at the very end of the program, tuck neatly out of the way.

 

If you'd like to post your code here, we could review it.

 

      -dZ.

Thanks DZ. I left it it on my thumb drive where I  work, but will try to get it before this afternoon. 

I want to say I was thinking the same and tried moving it around,  but still had the same result. 

I will post it if some one can see if it runs. If it does, that would let me know it is something with my program.

Share this post


Link to post
Share on other sites
2 minutes ago, Old Timey Retro Gamer said:

Thanks DZ. I left it it on my thumb drive where I  work, but will try to get it before this afternoon. 

I want to say I was thinking the same and tried moving it around,  but still had the same result. 

I will post it if some one can see if it runs. If it does, that would let me know it is something with my program.

No worries.

 

By the way, the book says you can get the full source for all example programs from the web site at:

You may want to download it and compare it to yours.

 

 

Share this post


Link to post
Share on other sites
15 hours ago, carlsson said:

Also are you inserting code at the locations the book tells you to, so you don't concatenate the new code after the previously input one?

Yes.  I believe everything is in place.  The only part that I thought was not very well explained was where it stated to put the DATA screen in. But I believe it is in the right spot (after the Constant assignment).

monkey.bas monkeyball.bas

Share this post


Link to post
Share on other sites

Those are the 2 files I have. One of them I typed myself (with all caps).  Thinking that I had typed something wrong, I copied and pasted directly from the book but still had the same result (blank screen). I did just try to put the DATA screen at the end of everything, but still is blank.  I ran the game of ball on the program, and it is working. So that is why I am a little confused at what is wrong.

Share this post


Link to post
Share on other sites

It is different.  It looks like there was more added to it on Oscar's program, so I may not have gotten that far, but the book had said when I got to that point that I should have been able to compile it, then run it at that point. And it was blank. It is in a little different order than I have it though.  Thanks again for the help!

Share this post


Link to post
Share on other sites
5 hours ago, Old Timey Retro Gamer said:

Yes.  I believe everything is in place.  The only part that I thought was not very well explained was where it stated to put the DATA screen in.


In my copy of the book it says,

 

"And now we use these constants for defining the screen adding this at the end of the source code."

 

I think it's pretty clear that you put it after everything thing else.

 

5 hours ago, Old Timey Retro Gamer said:

But I believe it is in the right spot (after the Constant assignment).

monkey.bas 7.91 kB · 2 downloads monkeyball.bas 4.67 kB · 2 downloads

No, no.  The DATA a goes at the VERY END.

 

Check out my explanation above for more information.  The book also tells you, "put it at the end."  All other pieces it tells you to put them in the middle somewhere, between or above other lines.

Edited by DZ-Jay
  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Old Timey Retro Gamer said:

It is different.  It looks like there was more added to it on Oscar's program, so I may not have gotten that far, but the book had said when I got to that point that I should have been able to compile it, then run it at that point. And it was blank. It is in a little different order than I have it though.  Thanks again for the help!

Hmm ... did you follow all pages?  The program goes from page 40, all the way to page 64.  It has many parts.

 

There are places where it tells you you can compile and run to check it out, but you must make sure to place the correct code in the right places.

Edited by DZ-Jay

Share this post


Link to post
Share on other sites
4 hours ago, DZ-Jay said:

Hmm ... did you follow all pages?  The program goes from page 40, all the way to page 64.  It has many parts.

 

There are places where it tells you you can compile and run to check it out, but you must make sure to place the correct code in the right places.

I was not finished with entire program,  but when I got to the spot where it said you can compile and look at the playfield. It didn't.  But it said to put it at the end of the source code. I wasn't quite sure if it was the very end. I did move it to the very end, but same result. 

Share this post


Link to post
Share on other sites
36 minutes ago, Old Timey Retro Gamer said:

I was not finished with entire program,  but when I got to the spot where it said you can compile and look at the playfield. It didn't.  But it said to put it at the end of the source code. I wasn't quite sure if it was the very end. I did move it to the very end, but same result. 

I understand.  By "the source code," it means the entire contents of the file.  I'll take a look at your posted code and see what I can find.

  • Like 1

Share this post


Link to post
Share on other sites

@Old Timey Retro Gamer,

 

I'm looking at the source code of "monkey.bas" you provided above, and I can see that the various sections of code introduced in the book are placed incorrectly.  That is indeed the problem.

 

As I tried to explain in a previous post, the CPU executes code from top to bottom, so if it encounters anything that is not really part of the program flow, it will happily attempt to execute it right then and there, irrespective of whether it is actual code, a data table, a procedure, or graphics.

 

The standard way of organizing a program is like this:

  • DECLARATION:  You place all your variable declarations, constants, macros, and other IntyBASIC directives that initialize the program at the very top.  These are things that are not really code statements, but give information to the compiler about the program.  In the case of "monkey.bas," this includes all those "CONST" lines.
     
  • INITIALIZATION:  After the constant and variable declarations comes the program initialization.  At this point, the game has not started, but it is typically a place where you set up the environment, initialize all the variables of the game world, like reset the score to zero, load the graphics into RAM, etc.  This part is usually executed once per game.
     
  • MAIN GAME LOOP:  Then you place your main game code.  This is typically a loop of some sort.  Remember:  an IntyBASIC program will run from top to bottom executing everything it encounters until it runs out of stuff to execute, at which point the CPU halts.  So, in a program like a game, which runs forever while the machine is on, you need somehow to make sure the CPU always has something to run.  It is typical to make a loop that runs forever, processing the game; and when the game finishes, it goes back to the beginning.

    It is important to note that this loop contains your main game program itself:  it calls out to functions and subroutines to do the actual work, but it is the one that controls the flow of your game.  We typically call it the "game engine."

    In the case of the "monkey.bas" the book evolves this part as it progresses through the example.  It starts with an empty loop ("WHILE 1: WEND"), and replaces it iteratively with additional code to add more features.

    This ... EXACTLY THIS PART ... is what runs and maintains the flow of your game.  After initialization, it runs continuously to maintain the game active; and when the game is over, it makes its way back to the initialization to start all over again.  As the CPU starts executing code from the top, passes through the initialization, and makes its way to the MAIN GAME LOOP, it stays there.  Once it enters the game loop, it never leaves.

    Thus, everything outside this block (which can be rather large) will not be seen by the CPU directly -- unless the MAIN GAME LOOP calls out to it using GOSUB or READ or something similar.  This is important:  We can consider the code up to this point to be THE PROGRAM, and everything else to be SUBROUTINES or DATA.
     
  • SUBROUTINES:  After your main game loop, comes any subroutines.  As mentioned above, because they are out of the way of the main program, the CPU will never see them or stumble upon them by accident.  But they are there, ready to be used, so that you can call the subroutines by name using GOSUB.  Each subroutine ends with a "RETURN" statement (or "END," which does the same thing), which causes it to return to the point where it was called.  Thus, a GOSUB is like a "bookmark":  it keeps track of the current place in the main code, jumps to the subroutine and executes it, then returns to that spot and continues.

    This is the way we break up large pieces of code into smaller chunks for easier maintenance.  It also allows for reuse, because a single subroutine can be called any number of times, at any place in your program.  You can consider subroutines as the "helper functions" of your program.
     
  • DATA:  At the bottom of your source code -- at the very end of all things -- comes DATA.  This includes value tables for velocities, animation, background scenes, etc.  It also includes the graphics cards for sprites and backgrounds.  Why do they go at the very end?  Well, first, like subroutines, they need to be out of the way of the main code, so that the CPU does not stumble upon them accidentally and attempts to execute them as if they were program code.  Second, because they are typically just a bunch of numbers and not very human-readable, we tend to put them completely out of the way.
     

Now, the above is just a general outline, nothing requires you to follow this order, and in fact, some people have their own way of doing things.  However, following the order above in principle, ensures that your program will flow correctly.  Remember, if the CPU encounters a PROCEDURE or DATA block in the middle of its execution flow, even if it wasn't invoked with GOSUB or READ, it will treat it as part of the program and run through it.  That's the critical thing to avoid, and that's what the above outline helps you achieve.

 

If you do not put such things out of the way (and there may be valid reasons why you may not), you will need to jump around them using GOTOs and such.

 

The reason I am going through the trouble of explaining all of the above is that I do not think it is enough to just go back and follow the book step by step.  You could easily just start from scratch again, and carefully follow the instructions and end up with the correct code.  However, armed with the above insight, you should be able to look at your code -- now and in the future -- and understand why it went wrong, and perhaps even correct it yourself.

 

Nonetheless, below is the answer to solving your problem.

 

So, why is the program failing to run?

  • "get_offset" procedure, "controller_direction" data table, and "LEVEL1_CARDS" data table, all appear right after the CONST section.  The part that should be there instead, is the one that starts with "CLS" and "MODE," which is the original code from the first page.

    Why is this wrong?
    Because they are in the normal program flow, and the CPU will treat them as if they were part of the main program and attempt to execute them.  As mentioned above SUBROUTINES (procedures) and DATA must be out of the way, and only invoked by the main program as needed with GOSUB, READ, etc.
     
  • As stated in page 45 "level1_cards" data table should have gone to the bottom.  Then on page 49, you are instructed to add "get_offset" and "controller_direction" right before "level1_cards".  That would have put the procedures right after the "Player" code, and the data tables at the very end.

    Why is this wrong?
    Just like the above, it is a data table that appears in the middle of the program flow.  The CPU will then try to execute it as code.  Like all other DATA, it must be out of the way of the CPU.

 

So, how to fix it?

  • First, move "get_offset," "controller_direction," and "level1_data," to the very bottom of the file -- right after the last BITMAP.

 

That should get you right back to the way the book has it.

 

However, the code still didn't compile due to some typos:

  • There's a stray fancy apostrophe instead of an ASCII character for a comment remark where it says "Side button pressed."
  • There are two "IF" statements where the "THEN" appears in the following line.
  • Those same two "IF" statements, have the statement which follows the "THEN" in the same line.

 

Among all that, the entire code seems to be squished to the left with no indentation.  I suggest you try to follow the conventional IntyBASIC indentation patterns, as shown in the book.  This makes it easier to follow the code and understand which "END IF" belongs to which "IF". :)

 

Attached find a fixed version of your code.  I built and ran it in the IntyBASIC SDK with no problems.  I get the astronaut, the monkey, and the girder scene, and I am able to go up and down the ladders (cute!). :)

 

     -dZ.

 

monkey.bas

Edited by DZ-Jay
  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, DZ-Jay said:

@Old Timey Retro Gamer,

 

I'm looking at the source code of "monkey.bas" you provided above, and I can see that the various sections of code introduced in the book are placed incorrectly.  That is indeed the problem.

 

As I tried to explain in a previous post, the CPU executes code from top to bottom, so if it encounters anything that is not really part of the program flow, it will happily attempt to execute it right then and there, irrespective of whether it is actual code, a data table, a procedure, or graphics.

 

The standard way of organizing a program is like this:

  • DECLARATION:  You place all your variable declarations, constants, macros, and other IntyBASIC directives that initialize the program at the very top.  These are things that are not really code statements, but give information to the compiler about the program.  In the case of "monkey.bas," this includes all those "CONST" lines.
     
  • INITIALIZATION:  After the constant and variable declarations comes the program initialization.  At this point, the game has not started, but it is typically a place where you set up the environment, initialize all the variables of the game world, like reset the score to zero, load the graphics into RAM, etc.  This part is usually executed once per game.
     
  • MAIN GAME LOOP:  Then you place your main game code.  This is typically a loop of some sort.  Remember:  an IntyBASIC program will run from top to bottom executing everything it encounters until it runs out of stuff to execute, at which point the CPU halts.  So, in a program like a game, which runs forever while the machine is on, you need somehow to make sure the CPU always has something to run.  It is typical to make a loop that runs forever, processing the game; and when the game finishes, it goes back to the beginning.

    It is important to note that this loop contains your main game program itself:  it calls out to functions and subroutines to do the actual work, but it is the one that controls the flow of your game.  We typically call it the "game engine."

    In the case of the "monkey.bas" the book evolves this part as it progresses through the example.  It starts with an empty loop ("WHILE 1: WEND"), and replaces it iteratively with additional code to add more features.

    This ... EXACTLY THIS PART ... is what runs and maintains the flow of your game.  After initialization, it runs continuously to maintain the game active; and when the game is over, it makes its way back to the initialization to start all over again.  As the CPU starts executing code from the top, passes through the initialization, and makes its way to the MAIN GAME LOOP, it stays there.  Once it enters the game loop, it never leaves.

    Thus, everything outside this block (which can be rather large) will not be seen by the CPU directly -- unless the MAIN GAME LOOP calls out to it using GOSUB or READ or something similar.  This is important:  We can consider the code up to this point to be THE PROGRAM, and everything else to be SUBROUTINES or DATA.
     
  • SUBROUTINES:  After your main game loop, comes any subroutines.  As mentioned above, because they are out of the way of the main program, the CPU will never see them or stumble upon them by accident.  But they are there, ready to be used, so that you can call the subroutines by name using GOSUB.  Each subroutine ends with a "RETURN" statement (or "END," which does the same thing), which causes it to return to the point where it was called.  Thus, a GOSUB is like a "bookmark":  it keeps track of the current place in the main code, jumps to the subroutine and executes it, then returns to that spot and continues.

    This is the way we break up large pieces of code into smaller chunks for easier maintenance.  It also allows for reuse, because a single subroutine can be called any number of times, at any place in your program.  You can consider subroutines are the "helper functions" of your program.
     
  • DATA:  At the bottom of your source code -- at the very end of all things -- comes DATA.  This includes value tables for velocities, animation, background scenes, etc.  It also includes the graphics cards for sprites and backgrounds.  Why do the go at the very end?  Well, first, like subroutines, they need to be out of the way of the main code, so that the CPU does not stumble upon them accidentally and attempts to execute them as if they were code.  Second, because they are typically just a bunch of numbers and not very human-readable, we tend to put them completely out of the way.
     

Now, the above is just a general outline, nothing requires you to follow this order, and in fact, some people have their own way of doing things.  However, following the order above in principle, ensures that your program will flow correctly.  Remember, if the CPU encounters a PROCEDURE or DATA block in the middle of its execution flow, even if it wasn't invoked with GOSUB or READ, it will treat it as part of the program and run through it.  That's the critical thing to avoid, and that's what the above outline helps you achieve.

 

The reason I am going through the trouble of explaining all of the above is that I do not think it is enough to just go back and follow the book step by step.  You could easily just start from scratch again, and carefully follow the instructions and end up with the correct code.  However, armed with the above insight, you should be able to look at your code -- now and in the future -- and understand why it went wrong, and perhaps even correct it yourself.

 

Nonetheless, below is the answer to solving your problem.

 

So, why is the program failing to run?

  • "get_offset" procedure, "controller_direction" data table, and "LEVEL1_CARDS" data table, all appear right after the CONST section.  The part that should be there instead, is the one that starts with "CLS" and "MODE," which is the original code from the first page.

    Why is this wrong?
    Because they are in the normal program flow, and the CPU will treat them as if they were part of the main program and attempt to execute them.  As mentioned above SUBROUTINES (procedures) and DATA must be out of the way, and only invoked by the main program as needed with GOSUB, READ, etc.
     
  • As stated in page 45 "level1_cards" data table should have gone to the bottom.  Then on page 49, you are instructed to add "get_offset" and "controller_direction" right before "level1_cards".  That would have put the procedures right after the "Player" code, and the data tables at the very end.

    Why is this wrong?
    Just like the above, it is a data table that appears in the middle of the program flow.  The CPU will then try to execute it as code.  Like all other DATA, it must be out of the way of the CPU.

 

So, how to fix it?

  • First, move "get_offset," "controller_direction," and "level1_data," to the very bottom of the file -- right after the last BITMAP.

 

That should get you right back to the way the book has it.

 

However, the code still didn't compile due to some typos:

  • There's a stray fancy apostrophe instead of an ASCII character for a comment remark where it says "Side button pressed."
  • There are two "IF" statements where the "THEN" appears in the following line.
  • Those same two "IF" statements, have the statement which follows the "THEN" in the same line.

 

Among all that, the entire code seems to be squished to the left with no indentation.  I suggest you try to follow the conventional IntyBASIC indentation patterns, as shown in the book.  This makes it easier to follow the code and understand which "END IF" belongs to which "IF". :)

 

Attached find a fixed version of your code.  I built and ran it in the IntyBASIC SDK with no problems.  I get the astronaut, the monkey, and the girder scene, and I am able to go up and down the ladders (cute!). :)

 

     -dZ.

Thank you so much for the explanation! I totally agree that the book seems to move too fast. (I broke down as much as I could on game of ball).  I managed to make borders around it, and to get the paddles to move towards the net. But still not understanding the string numbers of how the Sprites are placed on the screen.  When I saw the DATA info, then CLS, I had a feeling that was the case, although the SCREEN level1_card was placed after that.  So I'm still trying to grasp exactly how everything is working.   I used to be very proficient in High School with basic language, and then PASCAL (which was using basic language to compile). But it always used numbers to work the flow of the program.  Thank you again for the way you broke that down!

monkey.bas 9.89 kB · 1 download

 

  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, Old Timey Retro Gamer said:

Thank you so much for the explanation! I totally agree that the book seems to move too fast. (I broke down as much as I could on game of ball).  I managed to make borders around it, and to get the paddles to move towards the net. But still not understanding the string numbers of how the Sprites are placed on the screen.  When I saw the DATA info, then CLS, I had a feeling that was the case, although the SCREEN level1_card was placed after that.  So I'm still trying to grasp exactly how everything is working.   I used to be very proficient in High School with basic language, and then PASCAL (which was using basic language to compile).

 

In your code, the "SCREEN level1_card" is not really a problem.  It's the block with the label "LEVEL1_CARDS:" followed by a bunch of DATA statements.

 

I haven't looked at the other file you provided (monkeyball.bas), but if you have any specific questions about any part, just ask.

 

I aim to explain in detail the SPRITE statement in another post.  I'll probably write it later today.  In the meantime, feel free to point out any particular confusing string.

 

5 minutes ago, Old Timey Retro Gamer said:

But it always used numbers to work the flow of the program.

I understand.  IntyBASIC follows a more flexible approach.  Still, the order of the lines from top to bottom marks the program flow, and branches such as GOSUB and GOTO are done symbolically, with named labels rather than line numbers.

 

So, something like this:

10 IF (<SOME CONDITION>) THEN GOTO 100
20 ' Program continues ...
30 ' ...
90 END

100 PRINT "You made it!"
110 ' ...
120 GOTO 10

 

Is now done in IntyBASIC like this:

MainProgram:
	IF (<SOME CONDITION>) THEN GOTO YouMadeIt

	' Program continues ...

	GOTO MainProgram

YouMadeIt:
	PRINT "You made it!"
	' ...
	GOTO MainProgram

 

It should be easier to manage, more legible, and much more flexible since you do not need to constraint yourself to the numbers in between statements.

 

5 minutes ago, Old Timey Retro Gamer said:

Thank you again for the way you broke that down!

 

My pleasure. :)

 

  -dZ.

Edited by DZ-Jay

Share this post


Link to post
Share on other sites

One difference between classic BASIC and IntyBASIC is that in the older interpreters, DATA was a keyword which was parsed just like everyone else meaning you could easily interleave it with rest of the code. Here it is compiled into a set of data values that are addressed from the program and you would need to GOTO your way around an inlined DATA block in order to avoid running into it as if it was code. In that respect, IntyBASIC is more alike C or (I presume) Pascal that you keep code and data fairly separate, or at least the main part of your program that isn't part of procedures/subroutines.

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...