tricks to simplify coding

edited March 2010 in Development
When i started with programming in assembler i had very simple approach to do things. Just shifting bytes around, doing simple tests and so...
Later i started thinking about data structures like as 'objects' pointed by index register and subroutines as 'methods' on them. Of course there is nothing like inheritance or encapsulation but such approach still helps to keep me aware of what i'm doing.
Recently, i find myself using another helper like this:
call_from_table
	;HL = table
	;A  = ITEM


	add a, a
	add a, l
	ld l, a
	jr nc, call_from_table1
	inc h
call_from_table1
	ld a, (hl)
	inc hl
	ld h, (hl)
	ld (call_from_table2 + 1), hl
call_from_table2
	jp 0	

so i can do this in code
        ld a, (ix + FRAC_PEN)
	ld hl, p2_fracpentab
	call call_from_table  

...
p2_fracpentab
	.WORD pen_0      ;adress of subroutine for pen 0  etc.
	.WORD pen_1
	.WORD pen_2
which is actualy switch(var) command, less or more .

i wonder, if you use your own snippets to make coding easier.
Post edited by Fikee on
«1

Comments

  • edited March 2010
    I use some PRINT AT routine with BC as Y,X
    PRAT  LD A,22
          RST 16
          LD A,B
          RST 16
          LD A,C
          RST 16
          RET
    

    My call from table used in ZX81EMUL
    A holds code 0-255
          LD A,(DE)  ; DE = Programcounter
          LD L,A ; to lowbyte
          LD H,B      ; B = constant, start of table highbyte
          LD H,(HL)  ; Fetch Highbyte
          JP (HL)  ; jump to routine by value of A
    
    The jump table is 1K in size, 256 bytes for highbyte, 768 bytes for 256 JP NN instructions starting with 00,03,06,.....,FF,02,05,....,FE,01,...,FD

    Also some searchfunctions to find the nth record/textstring/level.
  • edited March 2010
    And to scan the keyboard in my MiniGames I always use this:

    waitkey  xor a
             ld hl,23560 ; last key pressed, filled through IM 1
             ld (hl),a ; set to NO VALID KEY
    wkey     or (hl) ; Wait until valid key in (hl)
             jr z,wkey
             or 32 ; make it always lowercase (ENTER becomes ;)
             ret ; A holds value of key pressed
    
  • fogfog
    edited March 2010
    is there anything like this for the speccy though ?

    http://codebase64.org/

    :)

    I'm from a c64 background , well coding wise. Would like to see a site with parallels that all machine use... e.g. change border / screen colour ... pixel and char shift routinues etc.
  • edited March 2010
    You should get a copy of ZX BASIC, and also look at the forums ( http://boriel.com ) there.

    Even if you don't want to use a basic compiler, the asm library folder for that has a LOT of assembler routines that you might find useful. (and if anyone knows a way to make them more optimal, I'm sure Boriel would love to hear from you). All the basic operations are laid bare in there - it's the run time library for the compiler, in essence.

    Furthermore, we're adding in extra libraries, so the help/tutorial/ideas forum has listings for things like a fast square roots, fast sin (and thus cosine and tangent) functions and so forth.

    Pretty much all of the above is likely to be copy-paste useful for an assembly programmer.

    I would also recommend "z80 assembly language subroutines" by Leventhal and Saville (1983) as a great source of coding structure concepts.
  • edited March 2010
    Fikee wrote: »
    When i started with programming in assembler i had very simple approach to do things. Just shifting bytes around, doing simple tests and so...
    Later i started thinking about data structures like as 'objects' pointed by index register and subroutines as 'methods' on them. Of course there is nothing like inheritance or encapsulation but such approach still helps to keep me aware of what i'm doing.
    Recently, i find myself using another helper like this:
    call_from_table
    	;HL = table
    	;A  = ITEM
    
    
    	add a, a
    	add a, l
    	ld l, a
    	jr nc, call_from_table1
    	inc h
    call_from_table1
    	ld a, (hl)
    	inc hl
    	ld h, (hl)
    	ld (call_from_table2 + 1), hl
    call_from_table2
    	jp 0	
    

    That code won't work. Here's a fix...
    call_from_table1
    	ld a, (hl)
    	inc hl
    	ld h, (hl)
    
    
            ld l,a
    
    
    	ld (call_from_table2 + 1), hl
    call_from_table2
    	jp 0	
    

    Here's a better version...
    call_from_table1
    	ld a, (hl)
    	inc hl
    	ld h, (hl)
            ld l,a
            jp (hl)
    
  • edited March 2010
    frobush wrote: »
    Here's a better version...
    call_from_table1
        ld a, (hl)
        inc hl
        ld h, (hl)
        ld l,a
        jp (hl)
    

    And even better (above code is JUMP from table) :
    call_from_table1
        ld a, (hl)
        inc hl
        ld h, (hl)
        ld l,a
        call 111 ; In ROM is this "jp (hl)" So you do CALL (HL)
    
  • edited March 2010
    Dr BEEP wrote: »
    And even better (above code is JUMP from table) :
    call_from_table1
        ld a, (hl)
        inc hl
        ld h, (hl)
        ld l,a
        call 111 ; In ROM is this "jp (hl)" So you do CALL (HL)
    

    Oh, okay then...
    call_from_table1
        ld a, (hl)
        inc hl
        ld h, (hl)
        ld l,a
        push hl
        ret
    
  • edited March 2010
    frobush wrote: »
    Oh, okay then...
    call_from_table1
        ld a, (hl)
        inc hl
        ld h, (hl)
        ld l,a
        push hl
        ret
    

    That's the same as JP (HL).

    I use the CALL (HL) to handle the keypresses in a game
    where HL points to the routine for up/down/left/right.
  • edited March 2010
    I use similar things (though I never use the ROM)
    WorkSPLoop:
                    	ld		a,(hl) 				; type index (or 0xff = end of vars)
    			add		a,a
    			ret		c                                      ; can only have 0x7f types!
    
    			push	        hl
    
    			ld		de,T_SPData			; temp sprite data store
    			ldi		; TYP
    			ldi		; XNO LO
    			ldi		; XNO HL
    			ldi		; YNO LO
    			ldi		; YNO HI
    			ldi		; GNO
    			ldi		; FLG1 LO
    			ldi		; FLG1 HO
    			ldi		; FLG2 LO
    			ldi		; FLG2 HO
    
    			add		a,SPTypes &0xff
    			ld		l,a
    			ld		h,SPTypes / 0x100
    
    			call	        JumpHL
    
    			pop		de
    			ld		hl,T_SPData			; temp sprite data store
    
    			ldi		; TYP
    			ldi		; XNO LO
    			ldi		; XNO HL
    			ldi		; YNO LO
    			ldi		; YNO HI
    			ldi		; GNO
    			ldi		; FLG1 LO
    			ldi		; FLG1 HO
    			ldi		; FLG2 LO
    			ldi		; FLG2 HO
    
    			ex		de,hl
    			jr		WorkSPLoop
    
    JumpHL:
             		ld		a,(hl)
    			inc		l
    			ld		h,(hl)
    			ld		l,a
    			jp             (hl)
    
  • edited March 2010
    frobush wrote: »
    That code won't work. Here's a fix...
    sh*t, a type error
    Here's a better version...


    thats what happen when coding in night :/ actually, the unnecessary writting was introduced when i changed call to jp. but sure, no excuse for such lame construction. i accept my punishment whatever it is.
  • edited March 2010
    Fikee wrote: »
    sh*t, a type error

    thats what happen when coding in night :/ actually, the unnecessary writting was introduced when i changed call to jp. but sure, no excuse for such lame construction. i accept my punishment whatever it is.

    That's okay - I'm getting a bit of a pasting myself! LOL!

    I'm going to hang up my coding clogs real soon! They are getting smelly!
  • edited March 2010
    This is a similar trick to the one used previously, but with a different purpose - get the current PC, without relying on the ROM:
    tmpspc:	equ	16384
    	ld	de, (tmpspc)
    	ld	hl, $E9E1
    	ld	(tmpspc), hl
    	call	tmpspc
    hlhere:	ld	(tmpspc), de
    

    After it's done its work, it'll leave the address of "hlhere" in HL. I use this in relocatable code so that I can work out addresses of tables and whatnot, often doing a PUSH HL / POP IX combo, to give me a base for indirect addressing. It's worth noting though that when you call code via a USR statement, BC contains the address called, and this can also be useful.
  • edited March 2010
    Has anybody programmed the Z80 on the Gameboy?

    It has a slightly different instruction set.

    No 'djnz'. But auto increment/decrement of HL...
     ld a, 50
     ld (hli),a
     ld (hli),a
     ld (hli),a
     etc
    


    Here, look at this (my Mr.do! code)...

    http://web.archive.org/web/20070511225944/myweb.tiscali.co.uk/frobush/mrdo.txt

    EDIT - stick that up your arse!
  • edited March 2010
    frobush wrote: »
    Has anybody programmed the Z80 on the Gameboy?
    always wanted to do something for gameboy, it is nice machine (the first one). but never get too much far just checking specs :)
  • edited March 2010
    hehe, back in 89 i would kill people for seeing commented source by Joffa. or sell my body for a dirty things. now, it just comes to me. world is changing.

    EDIT: i wonder which assembler was used to compile it. never seen HEX directive before.
  • edited March 2010
    Fikee wrote: »
    i wonder which assembler was used to compile it. never seen HEX directive before.

    I was using the Ocean assembler - running on an ST, which had loads of made-up opcodes to produce the Z80 Gameboy code. It wasn't very reliable, not what I was used to (the in-house Special FX system), but had to use it because it was a multi-player link-up thing. One ST and two Wideboys. It never worked of course. You would be lucky if the the two GBs kept in sync for a minute.

    We all got made redundant anyway before it was finished - the limited release has the two player option removed! (I have a copy- from Germany - R@RE).

    do.jpg

    If anyone wants it feel free to make an offer. I'll sign it too!


    The HEX directive was just that. You used a utility to grab graphics and saved out in various formats. 'HEX' was just save out as hex in source. None of that was typed in!
  • edited March 2010
    frobush wrote: »
    Has anybody programmed the Z80 on the Gameboy?

    It has a slightly different instruction set.

    No 'djnz'. But auto increment/dectrement of HL...
    Sadly I am guilty of doing some Gameboy stuff a few years ago. Don't forget the GB CPU's fantastic SWAP instruction for swapping the high and low nibbles of any 8-bit register or the contents of HL.

    A great time saver!
  • edited March 2010
    Chris Pile wrote: »
    Sadly I am guilty of doing some Gameboy stuff a few years ago. The GB's CPU also has the fantastic SWAP instruction for swapping the high and low nibbles of any 8-bit register or the contents of HL.

    A great time saver!

    Yeah, if you look throught the code you'll see a lot of this!

    Always thought this was funny...
    KEYS		LD	A,$20		;READ CURSOR PAD
    		LD	(PORT),A
    		LD	A,(PORT) 
    		LD	A,(PORT) 
    		CPL
    		AND	%1111
    		SWAP	A
    		LD	C,A
    		LD	A,$10
    		LD	(PORT),A
    		LD	A,(PORT)
    		LD	A,(PORT)
    		LD	A,(PORT)
    		LD	A,(PORT)
    		LD	A,(PORT)
    		LD	A,(PORT)
    		CPL
    		AND	%1111
    		ADD	A,C
    		LD	C,A
    		LD	(KEYPRESS),A
    		LD	A,$30
    		LD	(PORT),A
    		LD	A,C
    		RET
    

    I had an early Gameboy to work with. This was priceless! All Gameboy games had to work on this machine no matter what! This was one of the 1st, I don't know, 10,000 units produced - later models were improved - but all games had to work perfectly on one of these!

    EDIT - I love waking up to the smell of a burning Gameboy! (We went through about two a week)
  • edited March 2010
    frobush wrote: »
    ... it was a multi-player link-up thing. One ST and two Wideboys. It never worked of course. You would be lucky if the the two GBs kept in sync for a minute...

    Arrghh! The nightmare I had with the GB's link cable!! I reckon I probably spent more time (too much time!) on getting this to work than on any other single part of the game - especially on the bits that mattered! Sadly, it shows! I put it down to the usual movie licence rush-to-finish! That's my excuse, and I'm sticking to it!

    Still - at least one reviewer said "The implementation is absolutely flawless" when he wrote about the link cable support... The rest of the review isn't worth mentioning!! :lol::lol::lol:
  • edited March 2010
    Chris Pile wrote: »
    Arrghh! The nightmare I had with the GB's link cable!! I reckon I probably spent more time (too much time!) on getting this to work than on any other single part of the game - especially on the bits that mattered! Sadly, it shows! I put it down to the usual movie licence rush-to-finish! That's my excuse, and I'm sticking to it!

    Still - at least one reviewer said "The implementation is absolutely flawless" when he wrote about the link cable support... The rest of the review isn't worth mentioning!! :lol::lol::lol:

    Come on Chris - what game is this! I need to know!
  • edited March 2010
    Release a game when it isn't finished!

  • edited March 2010
    frobush wrote: »
    Come on Chris - what game is this! I need to know!

    Haha - I'm not sure I'm brave enough to admit it!! :lol::lol::lol:

    Think comic-book movie tie-in, Patrick Stewart, Hugh Jackman... :oops:

    The game-play ended up an absolute abortion! The play-testers (read secondary school drop-outs!) had too little time to fine-tune the game before the (movie) release deadline.

    Which was a shame really, as all of the parameters within the main engine were tweakable by the testers themselves. So they could have created something that played a damn sight better than the lame effort that eventually hit the shelves!

    Still - the graphics looked pretty if nothing else. Oh, and the link worked well. ;)
  • edited March 2010
    I would suggest that title of this thread contains an internal error. Tricks don't simplify coding.

    They make your code less simple, much harder to understand after two weeks. Using various tricks may make your code more efficient but not simpler.

    ;)
  • edited March 2010
    Chris Pile wrote: »
    Haha - I'm not sure I'm brave enough to admit it!! :lol::lol::lol:

    Think comic-book movie tie-in, Patrick Stewart, Hugh Jackman... :oops:

    Well, it's obviously X-Men. Did you work for Software Creations at all?
  • edited March 2010
    Ralf wrote: »
    Tricks don't simplify coding.

    They make your code less simple, much harder to understand after two weeks. Using various tricks may make your code more efficient but not simpler.

    ;)

    Two weeks? Is that it? Two weeks?

    My life.

    Two f*cking weeks!
  • edited March 2010
    frobush wrote: »
    ... Did you work for Software Creations at all?

    No. The dying embers of Probe - of which a couple of blokes forked-off and formed Crawfish Interactive. The CGB version of XM was done at Crawfish for Activision. I was there until just before their demise. Razorback Developments was born from the death of Crawfish by David Leitch - who worked as a freelancer for Crawfish and (getting it back on Speccy topic!) did some Speccy stuff and is listed on Infoseek HERE.

    Just a few days ago I found out the ex-CEO of Crawfish is now an actor!! How people's lives pan out is fascinating! :-o
  • edited March 2010
    Flipping heck - just been routing around and found this...

    Spiderman__X-Men_Arcades_Revenge_GEN_ScreenShot3.jpg

    My graphics on "Spiderman And The Xmen Vs Arcade's Revenge"! That's Gambit. I did Storm too!

    EDIT - SNES
  • edited March 2010
    frobush wrote: »
    Flipping heck - just been routing around and found this...

    Spiderman__X-Men_Arcades_Revenge_GEN_ScreenShot3.jpg

    My graphics on "Spiderman And The Xmen Vs Arcade's Revenge"! That's Gambit. I did Storm too!

    EDIT - SNES
    Blimey - Xmen everywhere!! I'd (very easily!) forgotten all about Xmen for the last ten years... Damn you fro for mentioning the GB link cable and bringing it to my mind again! ;) :lol:

    It's true what they say you know - the past always catches up and gives you a bloody great bite in the arse! :-P
  • edited March 2010
    Chris Pile wrote: »
    Blimey - Xmen everywhere!! I'd (very easily!) forgotten all about Xmen for the last ten years... Damn you fro for mentioning the GB link cable and bringing it to my mind again! ;) :lol:

    It's true what they say you know - the past always catches up and gives you a bloody great bite in the arse! :-P

    Yeah, sorry for side tracking you interesting post - it's just that this was work that I did that I haven't seen ever!

    Sorry!
  • edited March 2010
    frobush wrote: »
    Yeah, sorry for side tracking you interesting post - it's just that this was work that I did that I haven't seen ever!

    Sorry!
    No apologies needed... Sometimes it's good to just browse through a stash of CDs and/or floppies discovering stuff you created and had forgotten about! Nostalgia knows no bounds! :smile:

    Anyway, getting back to Fikee's original post - here's my number one "trick" to simplify coding:

    Comment, Comment and Comment again!!

    Makes the code a whole lot simpler when you stumble across it again in a few years time! ;);)
Sign In or Register to comment.