addHL and subHL affect flags, and are smaller

Most importantly, addHL and subHL now affect the flags as you would expect from a 16 bit addition/subtraction. This seems like it'd be preferred behaviour, however I realise any code relying on it not affecting flags would break. One byte saved in addHL, and two bytes saved in subHL. Due to the branching nature of the original code, it's difficult to compare speeds, subHL is either 1 or 6 cycles faster depending on branching, and addHL is between -1 and 3 cycles faster. If the chance of a carry is 50%, addHL is expected to be a cycle faster, but for a chance of carry below 25% (so a < 0x40) this will be up to a cycle slower.

kernel/core.asm

@@ -52,29 +52,24 @@ intoIX:
 	pop 	ix
 	ret
 
-; add the value of A into HL
+; add the value of A into HL, affecting flags like an ordinary addition
 addHL:
-	push	af
+	push	de
-	add	a, l
+	ld 	d, 0
-	jr	nc, .end	; no carry? skip inc
+	ld	e, a
-	inc	h
+	add	hl, de
-.end:
+	pop	de
-	ld	l, a
-	pop	af
 	ret
 
-; subtract the value of A from HL
+
+; subtract the value of A from HL, affecting flags like an ordinary subtraction
 subHL:
-	push	af
+	push	de
-	; To avoid having to swap L and A, we sub "backwards", that is, we add
+	ld	d, 0
-	; a NEGated value. This means that the carry flag is inverted
+	ld	e, a
-	neg
+	or 	a		;reset carry flag
-	add	a, l
+	sbc	hl, de		;There is no 'sub hl, de', so we must use sbc
-	jr	c, .end		; if carry, no carry. :)
+	pop	de
-	dec	h
-.end:
-	ld	l, a
-	pop	af
 	ret
 
 ; Compare HL with DE and sets Z and C in the same way as a regular cp X where