TUTORIAL #24 – LOW side - indirect indexed addressing “Is used to define the LOW side of the byte for mapping directly to the PAGE 1 screen memory”.
This is the final assembly code page that you need to enter. After you enter everything go ahead and save the code as ULTIMA1REV and compile the code. Once you compile the code you will want to enter the basic programming code on the next Tutorial page.
As always, if you have any questions please email me at:
josephpropati@yahoo.com
Joe “kingspud”
TUTORIAL #23 – HIGH side - indirect indexed addressing “Is used to define the HIGH side of the byte for mapping directly to the PAGE 1 screen memory”.
It’s not easy trying to explain the process of how to use indirect indexing to place shapes on the graphic screen so I will use the explanation from the a great assembly book – “Apple Graphics & Arcade Game Design” by Jeffrey Stanton. Below is Jeff’s explanation starting at Chapter 5 on page 111 – Bit Mapped Graphics.
“Drawing a bit-mapped shape table anywhere on the HI-RES screen can be a simple process once the basic concept is understood. The shape table is stored sequentially in memory, either by rows or by columns. The technique, therefore, is to load each of the bytes, one at a time, into the Accumulator, find the position in memory for the screen location where you want to plot the byte, then store it in that memory location.
The difficulty lies in finding a particular memory location, given an X, Y screen coordinate. Speed is the critical factor in doing arcade animation; therefore, a technique known as Table lookup is used to locate the starting address of any single line on the Hi-Res screen. Each of the 192 screen lines has a starting address for the first position (left most) or the 0th offset. The first line of line #0 is located in memory at location $2000. The second line is at $2400, etc… Each address takes two bytes. The first part is the hi-byte, which in the later case is $24. The second byte, $00 is the lo-byte. These can be separated into two tables, one containing the lower order address of each line (call it YVERTL) and the other containing the higher order address of each line, YVERTH. Each table is 192 bytes long (0-191). The effective address of the operand is computed by adding the contents of the Y register to the address in the instruction. That is:
EFFECTIVE ADDRESS = ABSOLUTE ADDRESS + Y REGISTER
If our YVERTH table was stored at $6800 and we wanted to find the starting address on line 1 (remember lines are numbered 0 to 191), we would index into the table one position and load that value into the Accumulator,
6800:20 24 28 2C 30 24 …………. YVERTH TABLE
So LDA YVERTH,Y where Y=$01 will fetch the value $24 from memory location $6800 + $01 = $6801, and place it in the Accumulator.
Similarly, if YVERTL was stored immediately after the first table, then:
68C0:00 00 00 00…………………….YVERTL TABLE
Y register = $01
LDA YVERTL,Y will take the value $00 stored in memory location $68C0 + $01 = $68C1, then place it in the Accumulator. Eventually, we will want to store the first byte from the shape table into memory location $2400. This can be done efficiently if the two byte address is stored sequentially in zero page. Let’s store the lo byte half of the address, HIRESL, at location $26, and the hi byte half, HIRESH, at location $27 in zero page.
LDY #$01 ; Y REGISTER CONTAIN LINE
LDA YVERTH,Y ; LOOKUP HI BYTE OF START
; OF ROW IN MEMORY
STA HIRESH ; STORE ZERO PAGE
LDA YVERTL,Y ; LOOKUP LO BYTE OF ROW IN
; MEMORY
STA HIRESL ; STORE ZERO PAGE
We can change a particular Hi-Res screen memory location using zero page by indirect indexed addressing in the form:
STA (HIRESL),Y Y Reg = $03
If the computer finds a $00 in location $26 (HIRESL) and a $24 in location $27 (HIRESH), then the base address is $2400. The Accumulator stores a value into memory location $2400 + $03, or location $2403.
The final addressing mode that we must consider is Indexed Indirect Addressing. It is of the form:
LDA (SHPL,X)
It is very similar to the indirect Indexed addressing mode except the index is added to the zero page base address before it retrieves the effective address. It is primarily used for indexing a table of effective addresses stored in zero page. But in the form we are going to use it, the X register is set to 0; thus, it simply finds a base address.
The reason we must use this second form of indirect addressing is a shortage of registers in the 6502 microprocessor. We are already using the Y register in the store operation and there isn’t an indirect addressing mode of the for LDA (SHPL),X. Thus, we must go to the alternative addressing mode LDA (SHPL,X).
What this all boils down to is that we want to load a byte from a shape table into the Accumulator and store it on the screen with the following instructions:
LDA (SHPL,X) ; STORE BYTE FROM SHAPE TABLE
STA (HIRESL),Y ; STORE BYTE ON HI-RES SCREEN
We can index into the shape by incrementing the low byte SHPL by one each time, then store that byte into the next screen position on a particular line by incrementing the Y register. This zero page method is faster than doing the equivalent code with absolute index addressing, because two byte addresses can be handled with fewer instructions, less memory space, and with fewer machine cycles.
Obviously, a generalized subroutine must be developed to find the screen memory address (HIRESL & HIRESH), given a line number and a horizontal displacement. We will call this subroutine GETADR, short for Get Address.
Each time a row of shape table bytes is transferred to successive memory locations on the Hi-Res screen, the program will call the subroutine GETADR. The line’s starting memory address is then offset by the horizontal location of the shape on the screen.
Memory address = Line # starting address + horizontal offset
GETADR LDA YVERTL,Y ; LOOK UP LO BYTE OF LINE
CLC
ADC HORIZ ; ADD DISPLACEMENT INTO LINE
STA HIRESL ; STORE ZERO PAGE
LDA YVERTH,Y ; LOOK UP HI BYTE OF LINE
STA HIRESH
RTS
Where the Y register has the vertical screen value (0-191).
So what this means is by using indirect index addressing you can quickly process each screen memory location by looping through the Hi and LOW byte of the screen memory and either place a zero value in the location and clear the byte or enter a HEX value and produce a graphic image on the screen. It would be time consuming as well as a waste of programming space to try and write to each screen memory location from $2000 to $3FFF through line 0 to 191. You can loop through data base that has each HI and LOW byte definition and save a huge amount of programming space.
Here is a breakdown of a line within the HI byte data definitions code:
See small sample image above
On line # 886 we have defined a set of HI byte data regions, which after the DFB define each of the HI side byte screen locations. So for example if you were to store a byte of information within the memory location $2100, you would first have to grab the HI byte $21 then loop through the LOW side byte in the LO database section to obtain the remaining byte to draw your shape on the screen.
Remember, screen memory location $2000 is the starting upper left corner of the screen that would store a byte of information to draw points on the screen. The $20 is the HI byte and $00 is the LOW byte.
As always, if you have any questions please email me at:
Joe “kingspud”
TUTORIAL #22 – MAP TILE DATA “Is used to define all the byte information for each 2 x 2 sized MAP TILES used on the world map”.
The following are the order in which the tiles are referenced:
0 = SHIP
1 = RAFT
2 = PLAINS
3 = TREES
4 = CASTLE
5 = TOWN
6 = SIGNPOST
7 = FIGHTER or main character
8 = TROLL
9 = DUNGEON ENTRANCE
10 = CART
11 = HORSE
12 = SPEEDER
13 = SPACE SHIP
14 = OCEAN
15 = DUNGEON
Since there are 82 horizontal line that make up the Ultima 1 world map, you will see a data string represented by a MAP## going from MAP1 all the way to MAP82.
To break down how each MAP TILE DATA STRING is read by the program I will use MAP70 as an example.
This example will be the same for all the MAP TILE DATA STRINGS!
First, you see the MAP70 with correlates to the 70th line on the World Map that will be shown on the screen.
Second, you see DFB which stands for Defined Byte for a defined data string. So everything after the DFB will represent the MAP TILES for the entire horizontal 70th line of the World Map.
Third, the first HEX value after the DFB will represent the number of HEX values that make up the entire MAP DATA string for MAP70. So $1E in this case is equal to the decimal value of 30, which if you count all the HEX values after the $1E will give you a total of 30 HEX values! The program uses this number to verify how many HEX values it can read in the DATA STRING before it gets to the end, without this HEX verifier it would cause the program to error by continuing to read the data string and not knowing where to end its read function.
Fourth, all the 30 HEX values after the $1E represent the amount and type of each MAP TILE shown on the world map. So for this example, the first $FE represent F = 15 and the E = OCEAN TILES. That is, there are 15 OCEAN TILES at the start of World Map horizontal line 70! The next amount and type of MAP TILE would be $1E or [1] OCEAN TILE. Then you have [3] PLAINS TILES, [1] TREE TILE, [1] PLAINS TILE, [7] OCEAN TILES, [13] PLAINS TILES, [6] OCEAN TILES, [3] TREES TILES, [1] OCEAN TILE, [3] PLAINS TILES, [1] TREES TILE, [3] PLAINS TILES, [9] OCEAN TILES, [1] DUNGEON TILE, [4] PLAINS TILES, [2] DUNGEON TILES, [15] OCEAN TILES, [13] OCEAN TILES, [4] TREES TILES, [1] PLAINS TILE, [14] OCEAN TILES, [4] TREES TILES, [8] OCEAN TILES, [5] DUNGEON TILES, [14] OCEAN TILES, [3] PLAINS TILES, [3] OCEAN TILES, [3] PLAINS TILES, and [11] OCEAN TILES. All of these data reference types make up the entire horizontal line for MAP row 70!
The reason this was created this way was the compression system I was talking about earlier in the blog. By doing each data string in this way I was able to save thousands of memory locations, which in turn allow me to have more programs on the disk.
To try and write this without the data compression would cause me to store each of these bytes in a separate memory location and if you add up all the type of each MAP TILE you would get just for this horizontal line alone, 171 bytes. Now multiply that by 82 horizontal map line and you can see that this is a lot of memory usages wasted! Remember, assembly language stores everything in a cells which are a $## HEX value of bytes, which are only readable up to 256 in numerical value.
This example is read exactly the same for each MAP DATA STRING from 1 to 82 so I’m not going to show each code line like I have been doing in the past because it is just easier to show each image from the lines of code that make up the MAP lines from MAP1 to MAP82.
As always, if you have any questions please email me at:
Joe “kingspud”
TUTORIAL #20 – SHPADR “Is used as a pointer for the SHAPE/TILE GRAPHICS used on the world map”.
All the graphic-tiles/shapes in Ultima 1 are predefined within a database SHPADR. These values consist of the type of shape used such as TREES, PLAINS, MOUNTAINS, OCEAN, etc… They are structured and referenced exactly as the MAPADR data each shape on the map is defined by a value from 0 to 15. This value is what represent a particular shape such as the fighter or the troll.
I will be going through the subroutine SHPADR line-by-line and explaining what each line of code is doing
and how it affects the outcome of the program.
719 **********************************
This is just a comment line to separate each subroutine and
helps to define the start of the subroutine.
720 * LOAD SHAPE ADDRESSES INTO SHPADR, LOW BYTE
FIRST
This comment line tells the user what type of data will be
referenced.
721 SHPADR DFB >SHAPE1
Line 721 is used to “[D]e[F]ine [B]ype” of SHAPE1
data location from the LOW byte side.
Each SHAPE location is defined by a HIGH and LOW byte, which in this case
is the > character representing the LOW byte location for the map addresses
in MAP1. An example of a memory region
address from the HIGH and LOW byte reference could be HEX $8000 or 32768. The HIGH side would be the 80 and the LOW
side would be the 00 of the HEX value $8000.
Also, line 721 has a header titled SHPADR, which allows it to be
called as a separate subroutine from the main subroutine.
722 DFB <SHAPE1
Line 722 is used to “[D]e[F]ine [B]ype” of MAP1
data location from the HIGH byte side.
Each MAP location is defined by a HIGH and LOW byte, which in this case
is the < character representing the HIGH byte location for the map addresses
in SHAPE1. SHAPE1 will call to a
database that will hold all the graphic tile types for a space on the
horizontal line of the world map. By
using a HIGH and LOW byte reference the map address is location in a memory
region based on the byte reference and can be called to reference the necessary
data of that map line.
723 DFB >SHAPE2
THRU
752 DFB <SHAPE16
Line 723 THRU 752 are all reference the same way with “[D]e[F]ine [B]ype” of SHAPE# data location. Each MAP location is defined by a HIGH and
LOW byte will be referenced the exact same way and hold all the world map data
information to help draw out the entire Ultima World map.
These are the following shape/graphic tile reference values and
their equivalent shape.
SHAPE1 = SHIP
SHAPE2 = RAFT
SHAPE3 = PLAINS
SHAPE4 = TREES
SHAPE5 = CASTLE
SHAPE6 = TOWN
SHAPE7 = SIGNPOST
SHAPE8 = CHARACTER
SHAPE9 = TROLL
SHAPE10 = DUNGEON
SHAPE11 = CART
SHAPE12 = HORSE
SHAPE13 = SPEEDER
SHAPE14 = SPACE SHIP
SHAPE15 = OCEAN
SHAPE16 = MOUNTAIN
Please email me any questions you might have,
Joe “kingspud”
TUTORIAL #18 – MVDOWN “Is used to move the main character DOWN on a key press, plus follow all collision detection requirements per character shape used”.
All the movement within Ultima 1 is based on “key press” functions because this game was created way before the mouse! In the original Ultima 1 you have four keys representing the North, South, East, and West movement, which consisted of the following keys: [ENTER],[ /], [ ; ] , [’ ]. Based on the represented shape on the screen ie. Fighter, horse, cart, etc… MVUP will also perform the required collision detections of the specific terrain on the screen based on the type of shape used. Each shape has a different type of collision detection so for example; the horse can travel over plains, trees, but not ocean or mountains. The ship and raft can travel over ocean tiles but not any other tiles. The land speeder can travel over plains but not trees or mountains. Etc… These types of collision detections are performed within the MVDOWN subroutine.
I will be going through the subroutine MVDOWN line-by-line and explaining what each line of code is doing
and how it affects the outcome of the program.
510 ***** MOVE DOWN ******
This is just a comment line to separate each subroutine and
helps to define the start of the MOVE DOWN subroutine.
511 *
This is just a comment line for use as a line spacer.
512
MVDOWN LDA CHAR
Line 512 is used to “[L]oa[D] register [A]” or
register A with the value in the variable CHAR!
So, you are setting the register A to equal the value which was initial
setup in the subroutine INITIAL. As the
transportation mode changes so does the CHAR value. So when a numeric key from 1 thru 6 is
pressed the value of CHAR get updated and modified.
Also, line 512 has a header titled MVDOWN, which allows it to be
called as a separate subroutine from the main BASIC PROGRAM; “ULTIMA”.
513 CMP #$0B ;HORSE
Once the value of CHAR is loaded into register A, Line 513
is used to “[C]o[MP]are”
what is in register A to the HEX value #$0B or decimal value of 11! The value in CHAR is the number representing
the shape/tile graphic for the main character shown on the computer screen. Each character or graphic tile has a numeric
value constant with the shape in the shape database. So as CHAR changes it stores a new value of
the main character shape/graphic tile such as fighter, horse, cart, ship,
etc... The [ ; ] symbol is a remark
symbol that tell the compiler to ignore everything after the ;. The HORSE reference tells anyone reading the
code that #$0B is a value that represents the HORSE shape.
514 BEQ
DUMPY2
Line 514 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$0B and it equals this value, in this case
11, then the program will branch or call jump to subroutine DUMPY2. DUMPY2 is the collision detection part of
the subroutine for the HORSE, which decides if it collides with specific
terrain types and if the collision is legal.
Otherwise the program moves on to the next code line 515.
515 CMP #$00 ;SHIP
Line 515 is used to “[C]o[MP]are” what is in register A to the HEX value $00 or
the decimal value of 0! The value in
CHAR will represent the shape/tile graphic for the SHIP in the middle of the
screen. The [ ; ] symbol is a remark
symbol that tell the compiler to ignore everything after the ;. The SHIP reference tells anyone reading the
code that #$00 is a value that represents the SHIP shape.
516 BEQ
DUMPY
Line 516 is used to “[B]ranch
on Result Zero Z=1”, which means that if the value in register A is compared to
#$00 and it equals this value, in this case 0, then the program will branch or
call jump to subroutine DUMPY. DUMPY is the collision detection part of the
subroutine for the SHIP, which decides if it collides with specific terrain
types and if the collision is legal.
Otherwise the program moves on to the next code line 517.
517 CMP #$01 ;RAFT
Line 517 is used to “[C]o[MP]are” what is in register A to the HEX value $01 or
the decimal value of 1! The value in
CHAR will represent the shape/tile graphic for the RAFT in the middle of the
screen. The [ ; ] symbol is a remark
symbol that tell the compiler to ignore everything after the ;. The RAFT reference tells anyone reading the
code that #$01 is a value that represents the RAFT shape.
518 BEQ
DUMPY
Line 518 is used to “[B]ranch
on Result Zero Z=1”, which means that if the value in register A is compared to
#$01 and it equals this value, in this case 1, then the program will branch or
call jump to subroutine RAFT1. DUMPY is
also the collision detection part of the subroutine for the RAFT, which decides
if it collides with specific terrain types and if the collision is legal. Otherwise the program moves on to the next
code line 519.
519
CMP #$0A ;CART
Line 519 is used to “[C]o[MP]are” what is in register A to the HEX value $0A or
the decimal value of 10! The value in
CHAR will represent the shape/tile graphic for the CART in the middle of the
screen. The [ ; ] symbol is a remark
symbol that tell the compiler to ignore everything after the ;. The CART reference tells anyone reading the
code that #$0A is a value that represents the CART shape.
520 BEQ
DUMPY2
Line 520 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$0A and it equals this value, in this case
10, then the program will branch or call jump to subroutine DUMPY2. DUMPY2 is the collision detection part of
the subroutine for the CART, which decides if it collides with specific terrain
types and if the collision is legal.
Otherwise the program moves on to the next code line 521.
521 CMP #$0C
;SPEEDER
Line 521 is used to “[C]o[MP]are” what is in register A to the HEX value $0C or
the decimal value of 12! The value in
CHAR will represent the shape/tile graphic for the LAND SPEEDER in the middle
of the screen. The [ ; ] symbol is a
remark symbol that tell the compiler to ignore everything after the ;. The LAND SPEEDER reference tells anyone
reading the code that #$0C is a value that represents the SPEEDER shape.
522 BEQ
DUMPY1
Line 522 is used to “[B]ranch
on Result Zero Z=1”, which means that if the value in register A is compared to
#$0C and it equals this value, in this case 12, then the program will branch or
call jump to subroutine LANDSPR. DUMPY1
is the collision detection part of the subroutine for the LANDSPR, which
decides if it collides with specific terrain types and if the collision is
legal. Otherwise the program moves on to
the next code line 523.
523 CMP #$07
;PLAYER
Line 523 is used to “[C]o[MP]are” what is in register A to the HEX value $07 or
the decimal value of 7! The value in
CHAR will represent the shape/tile graphic for the main FIGHTER character in
the middle of the screen. The [ ; ]
symbol is a remark symbol that tell the compiler to ignore everything after the
;. The PLAYER reference tells anyone
reading the code that #$07 is a value that represents the PLAYER shape.
524 BEQ
DUMPY2
Line 524 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$07 and it equals this value, in this case
7, then the program will branch or call jump to subroutine DUMPY2. DUMPY2 is also the collision detection part
of the subroutine for the PLAYER, which decides if it collides with specific
terrain types and if the collision is legal.
Otherwise the program moves on to the next code line 525.
525 RTS
Line 525 is used to “[R]e[T]urn from [S]ubroutine”,
which means that after the SUB-subroutine of each character tile shape
reference is called and updated, it returns back and then subroutine MVDOWN
will be complete and return to the original line statement that called it.
526 DUMPY LDX #$82
Line 526 is used to “[L]oa[D] register [X]” or register
X with the value equal to 130! So, you
are setting the value of X to equal the HEX value of $82, which equals decimal
value of 130. NOTE: $82 is equal to the
value of the square to the bottom of the main character on the screen. So when you see $82 it is talking about one
of four squares surrounding the main character on the screen. Each of the movement subroutines does this
check to the corresponding square next to the character tile on the screen.
Also, line 526 has a header titled DUMPY, which allows it to be
called as a separate SUB-subroutine from the MVDOWN subroutine”. The DUMPY subroutine is used to check the
collision detection parameters for the SHIP and the RAFT, which only allows
OCEAN movement.
527
LDA MAPSTORE,X
Line 527 is used to “[L]oa[D] register [A]” or
register A with the value in the array MAPSTORE,X and stored it in
register A.
528 CMP #$0E
Line 528 is used to “[C]o[MP]are” what is in register A to the HEX value $0E or
the decimal value of 14! This value is
what is equal to the OCEAN graphic tile/shape and if the comparison matches
then it is a valid movement and continues with the redraw of the screen. If the comparison does not match then it is a
collision and the subroutine returns back to the main subroutine.
529 BEQ
DUMPY3
Line 529 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$0E and it equals this value, in this case
14, then the program will branch or call jump to subroutine DUMPY3. DUMPY3 is the actual part of the MVDOWN
subroutine that when called has passed all the collision detection and draws
the new screen display of the new location for the character shape on the world
map. Otherwise the program moves on to
the next code line 530.
530 RTS
Line 530 is used to “[R]e[T]urn from [S]ubroutine”,
which means that the collision detection did not pass for the movement
direction so the subroutine is returned and awaits another movement command.
531 DUMPY1 LDX #$82
Line 531 is used to “[L]oa[D] register [X]” or
register X with the value equal to 130!
So, you are setting the value of X to equal the HEX value of $82, which
equals decimal value of 130.
Also, line 531 has a header titled DUMPY1, which allows it to be
called as a separate SUB-subroutine from the MVDOWN subroutine”. The DUMPY subroutine is used to check the
collision detection parameters for the LAND SPEEDER, which allows for OCEAN and
PLAIN movement but not through the TREES or MOUNTAINS.
532 LDA MAPSTORE,X
Line 532 is used to “[L]oa[D] register [A]” or
register A with the value in the array MAPSTORE,X and stored it in
register A.
533 CMP #$0F
Line 533 is used to “[C]o[MP]are” what is in register A to the HEX value $0F or
the decimal value of 15! The value of 15
is equal to the MOUNTAIN graphic tile and this is a collision check to see if
the move will cause the character to move on top of the MOUNTAIN shape on the
world map.
534 BEQ
DNCNT
Line 534 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$0F and it equals this value, in this case
15, then the program will branch or call jump to subroutine DNCNT. DNCNT is the direct call to the return
statement, which says there was a collision and the subroutine is returning
back to the main subroutine.
535 CMP #$03
Line 535 is used to “[C]o[MP]are” what is in register A to the HEX value $03 or
the decimal value of 3! The value 3 is
equal to the graphic tile/shape of the TREE.
536 BEQ
DNCNT
Line 536 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$03 and it equals this value, in this case
3, then the program will branch or call jump to subroutine DNCNT. DNCNT is the direct call to the return
statement, which says there was a collision and the subroutine is returning
back to the main subroutine.
537 JMP
DUMPY3
Line 537 tells the program to “[J]u[MP]” to the subroutine DUMPY3. DUMPY3
is the actual part of the MVDOWN subroutine that when called has passed all the
collision detection and draws the new screen display of the new location for
the character shape on the world map.
538 DUMPY2 LDX #$82
Line 538 is used to “[L]oa[D] register [X]” or
register X with the value equal to 130!
So, you are setting the value of X to equal the HEX value of $82, which
equals decimal value of 130.
539 LDA MAPSTORE,X
Line 539 is used to “[L]oa[D] register [A]” or
register A with the value in the array MAPSTORE,X and stored it in
register A.
540 CMP #$0E
Line 540 is used to “[C]o[MP]are” what is in register A to the HEX value $0E or
the decimal value of 14! The value 14 is
equal to the graphic tile/shape of the OCEAN.
541
BEQ DNCNT
Line 541 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$14 and it equals this value, in this case
14, then the program will branch or call jump to subroutine DNCNT. DNCNT is the direct call to the return
statement, which says there was a collision and the subroutine is returning
back to the main subroutine.
542 CMP #$0F
Line 542 is used to “[C]o[MP]are” what is in register A to the HEX value $0F or
the decimal value of 15! The value 15 is
equal to the graphic tile/shape of the MOUNTAIN.
543 BEQ
DNCNT
Line 543 is used to “[B]ranch
on Result Zero Z[=]1”, which means that if the
value in register A is compared to #$15 and it equals this value, in this case
15, then the program will branch or call jump to subroutine DNCNT. DNCNT is the direct call to the return
statement, which says there was a collision and the subroutine is returning
back to the main subroutine.
544 DUMPY3 JSR
CLRSET
Line 544 tells the program to “[J]ump
to the [S]ub[R]outine”
with the header CLRSET. The subroutine
CLRSET takes the specific variables used within the DRAW subroutine and clears
them to zero when the screen is redrawn for the character movement.
Line 544 also has a header name DUMPY3 so it can also be referenced and can be called to run within
the MVDOWN subroutine. Sub-subroutine DUMPY3 is used to update the variables
that define the new column value. Since
this is the move DOWN subroutine, we are only worried about the row and not the
column values. The column variable is
for LEFT and RIGHT movement.
545
INC ROW
Line 545 is used to “[INC]rement”
whatever value is in ROW and add 1 to it!
546 LDA ROW
Line 546 is used to “[L]oa[D] register [A]” or register
A with the value obtained from the variable ROW.
547 STA ROWNO
Line 547 is used to “[ST]ore the [A]ccumulator”
which has the value obtained from ROW.
ROWNO will now be used as a temporary ROW variable that can be modified
without disturbing the original ROW value.
548 LDA COLUMN
Line 548 is used to “[L]oa[D] the [A]ccumulator”
or register A with the value from COLUMN.
549 STA COLUMN1
Line 549 is used to “[ST]ore the [A]ccumulator”
which has the value obtained from COLUMN.
COLUMN1 will now be used as a temporary COLUMN variable that can be
modified without disturbing the original COLUMN value.
550 JSR
START8
Line 550 tells the program to “[J]ump
to the [S]ub[R]outine”
with the header START8. The subroutine
START8 is where the process of redrawing the screen takes place after the
movement process has occurred.
551 INC $FC
Line 551 is used to “[INC]rement”
the value held within memory location $FC and add 1 to it!
552
DNCNT RTS
Line 552 is used to “[R]e[T]urn from [S]ubroutine”,
which means that after the SUB-subroutine of each character tile shape
reference is called and updated, it returns back to here and then subroutine
MVDOWN will be complete and return to the original line statement that called
it.
Also, line 552 has a header titled DNCNT, which allows it to be
called as a separate sub-subroutine from the MVDOWN subroutine.
After the MVDOWN subroutine completes you should have accomplished
the following:
Depending on what type of shape/graphic tile you had as your main
character shape, you will have pressed the enter key and wanted to move your
character DOWN one space on the world map.
To be able to do this the subroutine will check what type of character
shape is being used, then check to see if the terrain you are about to move
into is non-collision type terrain. The
subroutine check the value of the terrain shape against the legal movement
values and if it is ok it continue on to the Sub-subroutine DUMPY3 that
modifies the variable and returns out of the subroutine getting ready to draw
the new world map screen display. If
there is a collision detected against a terrain type that is not legal, then
the subroutine just returns out of the main subroutine and waits for a new
movement key press.
As always, please email me any questions you might have.
Joe “kingspud”
