Monday, August 15, 2011

Tutorial covering CALL, POKE, and PEEK statements...

Hello all,

Well, yesterday I was doing some testing with CALLs, POKES, and PEEKs and realized I had a less than desired understanding of these concepts and how they are used within assembly and Basic programs.  I know there is a lot of information floating around out there that covers these topics but I haven’t seen anything that gives a direct sample and explanation to how these work in an adventure game.  So I thought I would give some examples of how they work and how they are being used within my Ultima 1 revisited program!

Here we go:

A CALL statement by definition is as follows:  A CALL statement executes a machine language subroutine from a BASIC program.  Control transfers to the subroutine.  When is finishes, execution goes to the statement following the CALL.

Ok, great but what does that mean?!  Here is how I will try to explain what this means and show you how I’m using it in my program.  Within the game I have a subroutine in my assembly program that checks when the player character moves on the map and if there is a collision with different types of map tiles such as mountains, oceans, or normal movement tiles.  In the beginning part of the game I use a BASIC program to check the key strokes while on the world map of the game.  So, while I’m using the  I, J, K, and M key to move around the map, if I hit an “I” to move up I use a CALL statement within an IF-THEN statement to execute the subroutine in the assembly program.   

In essence, it passes control from the BASIC program to the assembly program and then back again.
We all remember that GET A$ in BASIC is used to track when a single keystroke is pressed and that key can be checked within an If – Then statement.

Example:  10 IF A$=”I” THEN CALL 26534

“You have to convert HEX to DECIMAL for the call statement in Basic”

The way the CALL statement works is as follows; everything in assembly is written to a specific memory location. So, I have a subroutine in assembly called MOVEUP and it starts at memory location $67A6. 

You will discover this memory address after you compile the assembly program and it gives you a listing of all the subroutine headers and there HEX location!” 

Remember that memory locations $6000 to $BFFF are free for program statements.  

Now, the CALL statement is executed when you hit the “I” key and it executes the MOVEUP subroutine at memory location “in decimal” 26534, which equals in HEX $67A6”!  Within the MOVEUP subroutine I do different things like check against tiles I shouldn’t be able to move through and against tiles I can move through.  If the tile is a collision tile such as a mountain I have a statement that writes “YOU CAN’T MOVE THROUGH MOUNTAINS!” and then it returns back to the line immediately after the original CALL statement in the BASIC program. 

If the tile is a plains or tree tile, the character is free to move and the screen must be updated with new tiles.  Since the movement is clear I use a JSR command in assembly, which is a “Jump to a Subroutine” command and update the tile and shape information for the next 200 tiles that will show on the screen.  These new tiles are drawn to the screen and once complete the subroutine returns back to the line immediately after the original CALL statement awaiting the next keystroke press.

This is how the CALL statement works with assembly from BASIC; it goes to the memory location and executes the subroutine then when it completes its task in the subroutine, it returns back to the BASIC program.   This is the link between assembly and BASIC so both programs can communicate with each other. 

The assembly program does not necessarily have to have a name header like I’m using such as the MOVEUP header but without some kind of name reference it is much harder to find the exact location of the memory address where the start of that routine is located.

I hope this tutorial was informative and gave a little better insight into how the CALL statement is used within a BASIC program to communication with your assembly program.

Joe

No comments:

Post a Comment