| View previous topic :: View next topic | 
	
	
		| Author | Message | 
	
		| ccovell Regular
 
  
 
 Joined: 19 Dec 2005
 Posts: 100
 Location: Japan
 
 | 
			
				|  Posted: Fri Dec 08, 2006 3:14 pm    Post subject: Bug in MagicKit's branch handling |   |  
				| 
 |  
				| Hi, as long as I'm on the subject of bugs (see the BRAM topic), I thought I might as well point out a bug that I came across a long time ago while working on my game. Here is a short listing from a section where I discovered MagicKit assembling my code incorrectly:
 
  	  | Code: |  	  | 351  01:DA72            .pmsprite_loop1 352  01:DA72                    spr_set sprite_no,satb
 353  01:DA8B                    spr_x sx
 354  01:DA98                    spr_y sy
 355  01:DAA4                    spr_pattern spr_vram_point
 356  01:DAB1                    spr_ctrl  #SIZE_MASK|FLIP_MASK,#SIZE_32x64|NO_FLIP
 357  01:DABD                    spr_pri   #1
 358  01:DACB                    spr_pal   #1
 359
 360  01:DAD5  EE CD 26          inc     sprite_no
 361  01:DAD8                    addw    #$20,sx
 362  01:DAE9  EA                nop
 363  01:DAEA  EA                nop
 364  01:DAEB  EA                nop
 365  01:DAEC                    addw    #$0010,spr_vram_point
 366
 367  01:DAFD  AD CD 26          lda     sprite_no
 368  01:DB00  C9 3C             cmp     #$3C
 369  01:DB02  D0 22             bne     .nomovePauseSpr
 370  01:DB04                    subw   #$80,sx  ; that will center it on the screen
 371  01:DB15                    addw   #$40,sy
 372  01:DB26            .nomovePauseSpr
 373  01:DB26  AD CD 26          lda     sprite_no
 374  01:DB29  C9 40             cmp     #$40                    ;Make sure this matches!!!!
 375  01:DB2B  D0 45             bne     .pmsprite_loop1
 376  01:DB2D  60                rts
 | 
 You can see that despite my .pmsprite_loop1 label being at a lower address in ROM, the branch that is generated branches forward to an invalid address.  I can post other examples if anyone wants to see.
 
 Before I found this bug, my game was crashing every time I made some loops longer (usually during sprite-drawing routines), and I couldn't figure out why.  (Branches that are too long usually halt assembly and produce an error.)  I guess this bug is caused by MagicKit not counting the bytes produced by macro routines (or functions) properly.  David, any comments?
 _________________
 http://www.chrismcovell.com
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| dmichel Admin
 
  
 
 Joined: 04 Apr 2002
 Posts: 1166
 Location: France
 
 | 
			
				|  Posted: Sat Dec 09, 2006 12:28 am    Post subject: |   |  
				| 
 |  
				| I remember such a bug but this was a long long time ago. I tried to reproduce it with the current version of pceas but the assembler generated an 'out of range' error in all cases. What version are you using? The latest is 3.21. If you have the source code of pceas check the class2 function in code.c file. _________________
 David Michel
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| ccovell Regular
 
  
 
 Joined: 19 Dec 2005
 Posts: 100
 Location: Japan
 
 | 
			
				|  Posted: Sat Dec 09, 2006 5:50 pm    Post subject: |   |  
				| 
 |  
				| I have the latest version that I got from here: http://www.magicengine.com/mkit/ 
  	  | Quote: |  	  | 09/09/2000 : 
 New MagicKit and HuC released!
 
 Assembler 2.5.0 -> 2.5.1
 | 
 
 If you've been hoarding a much newer version, please release it!
  _________________
 http://www.chrismcovell.com
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| Tomaitheous Elder
 
  
 
 Joined: 27 Sep 2005
 Posts: 306
 Location: Tucson
 
 | 
			
				|  Posted: Sat Dec 09, 2006 11:36 pm    Post subject: |   |  
				| 
 |  
				| Pceas 3.2.1 or whatever it is, comes with HuC. But it has two bugs that I found so far - all equates must not have any space between the const name and the beginning of the line: 
 junk .equ $4321 ; right
 junk .equ $4321 ;wrong
 
 And all instructions need to have atleast one space between them and the beginning of the line (reversed of the above).
 
 Btw, doesn't Pceas expand all macros on the first pass?
 
 -Rich
 _________________
 www.pcedev.net
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| dmichel Admin
 
  
 
 Joined: 04 Apr 2002
 Posts: 1166
 Location: France
 
 | 
			
				|  Posted: Sun Dec 10, 2006 1:41 am    Post subject: |   |  
				| 
 |  
				| Yup, 3.21 is part of HuC. It's not really a new version thought, it just has a few extra stuff that was needed by HuC, I think 2.51 already had the 'out of range' buf fix, it's strange, may be you will have the same problem with 3.21 too, let me know if this is the case. _________________
 David Michel
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| dmichel Admin
 
  
 
 Joined: 04 Apr 2002
 Posts: 1166
 Location: France
 
 | 
			
				|  Posted: Sun Dec 10, 2006 1:50 am    Post subject: |   |  
				| 
 |  
				|  	  | Tomaitheous wrote: |  	  | Pceas 3.2.1 or whatever it is, comes with HuC. But it has two bugs that I found so far [...] | 
 
 Those are not bugs, they are features.
   
 You can go around the first one by adding a colon to the label :
 
 junk: .equ $4321
 
 For the second one there's no solution thought, anything that start at the beginning of the line is considered a label.
 
 
  	  | Quote: |  	  | Btw, doesn't Pceas expand all macros on the first pass? | 
 
 Yup, it does.
 _________________
 David Michel
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| Tomaitheous Elder
 
  
 
 Joined: 27 Sep 2005
 Posts: 306
 Location: Tucson
 
 | 
			
				|  Posted: Mon Dec 11, 2006 5:58 am    Post subject: |   |  
				| 
 |  
				|  	  | Quote: |  	  | Those are not bugs, they are features. | 
 
 
  _________________
 www.pcedev.net
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		|  |