Z80 Good Programming Practices - Revision history

Galandros: improved

2010-11-17T19:53:31Z

improved

Tribal at 23:40, 10 November 2010

2010-11-10T23:40:42Z

Galandros: moved Good programming practices to Z80 Good Programming Practices: to not mistake with general programming

2010-04-20T20:25:52Z

moved Good programming practices to Z80 Good Programming Practices: to not mistake with general programming

Galandros at 16:30, 25 October 2009

2009-10-25T16:30:11Z

Jim e: Ix thing was painfully wrong, lut code wasn't the best still isn't.

2006-12-27T08:26:05Z

Ix thing was painfully wrong, lut code wasn't the best still isn't.

Burntfuse: added alternative to LUTs for if few options and sequential values of a

2006-09-24T18:41:29Z

added alternative to LUTs for if few options and sequential values of a

Jim e: This entire article is questionable.

2006-09-20T19:11:24Z

This entire article is questionable.

Mbruno at 19:11, 16 July 2006

2006-07-16T19:11:04Z

Guillaumeh: formatting

2006-02-19T14:43:30Z

formatting

Guillaumeh: stub

2006-02-10T11:34:47Z

stub

New page

== Using IX ==

If you have objects represented by adjacent chunks of data in memory, you can use IX to easily manage them.

<nowiki>
ld b,10
ld hl,SpritesData
DisplaySpritesLoop
ld b,(hl) ; coordx
inc hl
ld c,(hl) ; coordy
inc hl
ld d,(hl) ; first part of address
inc hl
ld e,(hl) ; end of address
inc hl
call DisplaySprite
djnz DisplaySpritesLoop
</nowiki>

<nowiki>
COORDX equ. 0
COORDY equ. 1
ADDR1 equ. 2
ADDR2 equ. 3

ld b,10
ld ix,SpritesData
DisplaySpritesLoop
ld b,(ix+COORDX)
ld c,(ix+COORDY)
ld d,(ix+ADDR1)
ld e,(ix+ADDR2)
call DisplaySprite
ld hl,4
add ix,hl
djnz DisplaySpritesLoop
</nowiki>

Defining constants for the offsets of each field of your "objects" makes the code more understandable.

== Lookup table ==

If you have a place in your code where a value is tested to choose between a lot of things, like subroutines or data, it can be a good idea to use lookup tables instead of a series of tests. It makes the code more readable, concise and extensible.

<nowiki>
ld a,(SpriteNumber)
cp 1
jp z,ChooseSprite1
cp 2
jp z,ChooseSprite2
cp 3
jp z,ChooseSprite3
cp 4
jp z,ChooseSprite4
...
ChooseSprite1
ld hl,Sprite1
jp DisplaySprite
ChooseSprite2
ld hl,Sprite2
jp DisplaySprite
ChooseSprite3
ld hl,Sprite3
jp DisplaySprite
ChooseSprite4
ld hl,Sprite4
jp DisplaySprite
...
DisplaySprite
ld bc,(coordinates)
call SpriteRoutine
</nowiki>
Can be rewritten in :
<nowiki>
ld a,(SpriteNumber)
add a,a ; a*2
ld h,O
ld l,a
ld de,SpriteAddressLUT
add hl,de
ld bc,(coordinates)
call SpriteRoutine
...
SpriteAddressLUT
.dw Sprite1
.dw Sprite2
.dw Sprite3
.dw Sprite4
</nowiki>

And this one :

<nowiki>
ld a,(MenuChoice)
cp 1
jp z,Choice1
cp 2
jp z,Choice2
cp 3
jp z,Choice3
cp 4
jp z,Choice4
...
</nowiki>
Can be rewritten in :
<nowiki>
ld a,(MenuChoice)
add a,a ; a*2
ld h,O
ld l,a
ld de,CodeBranchLUT
add hl,de
jp (hl)
...
CodeBranchLUT
.dw Choice1
.dw Choice2
.dw Choice3
.dw Choice4
</nowiki>

{{stub}}

@@ Line 1: / Line 1: @@
 == Lookup table ==
@@ Line 146: / Line 149: @@
 </table>
-== Related topics ==
+= Source Code =
-* [http://www.unitedti.org/forum/index.php?showtopic=8461 Common Mistakes and Good techniques]
+Some advices to take into consideration:
-{{stub}}
+= Related topics =

@@ Line 147: / Line 147: @@
 == Related topics ==
-* [http://www.unitedti.org/index.php?showtopic=8461 Common Mistakes and Good techniques]
+* [http://www.unitedti.org/forum/index.php?showtopic=8461 Common Mistakes and Good techniques]
 {{stub}}

@@ Line 145: / Line 145: @@
 </tr>
 </table>
 {{stub}}

@@ Line 46: / Line 46: @@
 </table>
-Defining constants for the offsets of each field of your "objects" makes the code more understandable. However this particular example is not the best, being that the original code is faster and smaller.  Typically in sequential access using the HL register would perform better, however if random access of different objects and different elements in an object is required through out a particular iteration, than ix would be the better choice.
+Defining constants for the offsets of each field of your "objects" makes the code more understandable. However this particular example is not the best, being that the original code is faster and smaller.  Typically in sequential access using the HL register gives better performance, but if random access of different objects and different elements in an object is required throughout a particular iteration, then ix would be the better choice.
@@ Line 56: / Line 56: @@
 In terms optimisation though it should be used when the data is not sequentially ordered or when the objects being pointed to are not the same size.  For example, using LUTs (Look Up Tables) to find a tile in a block of memory that is only tiles would both slower and cost more memory.  Using LUTs to find a particular string would be quicker but would waste more memory than a linear search.  Using LUTs as a jump table to different code blocks located through out a program would be faster and smaller compared to the alternative.
 <table border="1" cellpadding="2">
 <tr><th>Without</th><th>With</th></tr>

← Older revision	Revision as of 20:25, 20 April 2010
(No difference)

@@ Line 1: / Line 1: @@
 == Lookup table ==
@@ Line 78: / Line 27: @@
   <nowiki>
   ld a,(SpriteNumber)
   cp 1
   jp z,ChooseSprite1
@@ Line 86: / Line 37: @@
   cp 4
   jp z,ChooseSprite4
 ...
 ChooseSprite1
   ld hl,Sprite1
@@ Line 98: / Line 54: @@
 ChooseSprite4
   ld hl,Sprite4
   jp DisplaySprite
 ...
@@ Line 108: / Line 67: @@
   <nowiki>
   ld a,(SpriteNumber)
-  add a,a ; a*2
+  add a,a   ; a*2 (limits SpriteNumber to 128)
   ld h,0
   ld l,a
@@ Line 118: / Line 77: @@
   ld l,a
   ld bc,(coordinates)
-  call SpriteRoutine
+  jp SpriteRoutine
 ...
 SpriteAddressLUT
   .dw Sprite1
   .dw Sprite2
   .dw Sprite3
   .dw Sprite4
   </nowiki>
 </td>
@@ Line 137: / Line 98: @@
   <nowiki>
   ld a,(MenuChoice)
   cp 1
   jp z,Choice1
@@ Line 145: / Line 108: @@
   cp 4
   jp z,Choice4
 ...
   </nowiki>
@@ Line 163: / Line 132: @@
   jp (hl)
 ...
-CodeBranchLUT
+CodeBranchLUT:
   .dw Choice1
   .dw Choice2
   .dw Choice3
   .dw Choice4
   </nowiki>
 </td>

@@ Line 25: / Line 25: @@
 <td>
   <nowiki>
-COORDX equ. 0
+COORDX .equ 0
-COORDY equ. 1
+COORDY .equ 1
-ADDR1 equ. 2
+ADDR1 .equ 2
-ADDR2 equ. 3
+ADDR2 .equ 3
   ld b,10
@@ Line 46: / Line 46: @@
 </table>
-Defining constants for the offsets of each field of your "objects" makes the code more understandable.
+Defining constants for the offsets of each field of your "objects" makes the code more understandable. However this particular example is not the best, being that the original code is faster and smaller.  Typically in sequential access using the HL register would perform better, however if random access of different objects and different elements in an object is required through out a particular iteration, than ix would be the better choice.
 == Lookup table ==
 If you have a place in your code where a value is tested to choose between a lot of things, like subroutines or data, it can be a good idea to use lookup tables instead of a series of tests. It makes the code more readable, concise and extensible.
 <table border="1" cellpadding="2">
@@ Line 89: / Line 94: @@
   ld a,(SpriteNumber)
   add a,a ; a*2
-  ld h,O
+  ld h,0
   ld l,a
   ld de,SpriteAddressLUT
   add hl,de
   ld bc,(coordinates)
   call SpriteRoutine
@@ Line 129: / Line 138: @@
   ld a,(MenuChoice)
   add a,a ; a*2
-  ld h,O
+  ld h,0
   ld l,a
   ld de,CodeBranchLUT
   add hl,de
-  bcall(_LdHLInd)
+  ld a,(hl)
   jp (hl)
 ...