joeldipops / gbz80-pseudoops Goto Github PK

SPRITE_SIZE EQU 4

; Don't think this is possible, but worth a shot.
setOAMStage: macro
OAMStage SET \1
endm

;;;
;
; @param \1 Sprite number
; @param \2 X position
; @param \3 Y position
; @param \4 Pointer to image tile
; @param \5 Flags
; @param \6 preserve HL - if 0, HL will be affected, if 1, HL will be unchanged.
;;;
updateSprite: macro
IF (\7 == 1)
push HL
ENDC

ld HL, OAMStage + (\1 * SPRITE_SIZE)
ldi [HL], \2
ldi [HL], \3
ldi [HL], \4
ldi [HL], \5

IF (\6 == 1)
    pop HL
ENDC

endm

updateSprite 3, OAMStage, 32, 32 CursorFrame1, (HAS_PRIORITY | USE_PALETTE_0), 0

Pretty much what is says on the "tin" :P

Macros loading from memory (addAny, for example) do not use ldh when effective/possible.

Both doc comments and readme.md are missing some instructions or have incorrect cycles/bytes/flags for certain cases.

This line makes orAny [hl], [hl] only read from memory once, which is not expected behavior.
This could be useful for reading STAT, for example, or acknowledging by polling memory (some mappers, including custom, work this way)

This is a really interesting project you have, that really adds a lot of convenient value in a really straightforward, un-intrusive way. I think it's pretty common for developers to create macros for things that would make sense to be instructions, but aren't. A library that provides many of them all at once makes a lot of sense.

A collection of like-minded macros I wrote before but haven't gotten around to publishing involved making jumps clearer. They add pseudo-instructions for jr, jp, call, and ret for when the previous operation (a sub or a cp) produced a "less than", "greater than", "less than or equal", "greater than or equal", "equal", or "not equal" condition.

I feel like instructions of that sort might make sense for this library. I've attached my previous code. If you think the idea is appropriate for your library, feel free to use it to any extent you wish, harvesting directly, or just inspiring your own macros developed to your particular style and standard.

I will warn that while I'm pretty sure they work correctly, they are a year or two old, I never used them in a real project, I don't remember how well I tested them, and so any or all of them may well be implemented incorrectly :D

https://gist.github.com/DonaldHays/a2cdddba571a20d73e9b5f6550695cf3

This comment states that this is for MBCs with higher ROM bank counts, when it's really per ROM, and only applies to MBC5.

As well as things like HIGH($4321).

I realised that I've over-complicated ldAny by checking for r8, n8 or [HL], and then realising I'd also need to check for LOW(r16), HIGH(r16) and more.

It should be easier to check for any square brackets instead.

There might still be an issue when passing certain strings baked in to macro-vars, but will be a cleaner anyway.

jr is used much, much more than jp, yet only jp has macros defined for it.

Try to improve mult op by using example here: http://wikiti.brandonw.net/index.php?title=Z80_Routines:Math:Multiplication

originally here: #8

'Now constant time, and uses less regs'
eg.

;;;
; mult r16, r8
; Multiples an 8-bit number (in LOW(\1)) with H, result in HL
; @param \2 A temporary register. Make SURE it's not one of H, L, HIGH(\1), or LOW(\1).
; @return HL The result
; @return HIGH(\1) 0
; @return \2 0
; @return ZF Set
; @destroy CF
;;;
mult: macro
ld L, 0
ld HIGH(\2), L
ld \2, 7

; Optimized first iteration
sla H
jr NC, .loop\@
ld L, LOW(\2)

.loop@
add HL, HL
jr NC, .noAdd@
add HL, DE
.noAdd
dec \2
jr NZ, .loop@
endm

After looking at the src for https://github.com/ISSOtm/rgbds-structs I think I've discovered that you can use quotes to test what's passed in eg
IF ("\1" == "A")

This would mean I could make the ops I'd dreamed of such as ld16 BC, HL instead of ld16 B,C, H,L

In fact I could improve my macros so much by cutting out useless cycles depending on the params

eg. ldAny A,A

ldAny: macro
IF ("\2" == "A")
ld [\1], \2
ELSE
ld A, \2
ld [\1], A
ENDC
endm

Really hope it works the way I think...

If this line is hit, flags are modified, whereas all doc comments state the macro doesn't affect them.

This condition can never be met.

Unsure how to fix it.