"Who cares if it's slow, at least the code is correct" - someone who never wrote 8-bit code in their life It at least managed to regurgitate the fast multiply-

"Who cares if it's slow, at least the code is correct" - someone who never wrote 8-bit code in their life It at least managed to regurgitate the fast multiply-by-10 algorithm, which of course exists in countless examples all over the web. But then, instead of maybe repeating that twice to multiply by 100, it produced absolutely insane code which - even at a glance - can't be correct unless the input happened to be zero: ; No decimal point, multiply by 100 ld b, h ld c, l add hl, hl ; * 2 add hl, hl ; * 4 add hl, hl ; * 8 add hl, hl ; * 16 add hl, hl ; * 32 add hl, hl ; * 64 add hl, bc ; * 65 add hl, hl ; * 130 ld b, h ld c, l srl b rr c ; * 65 add hl, bc ; * 195 add hl, hl ; * 390 add hl, hl ; * 780 srl h rr l ; * 390 add hl, hl ; * 780 srl h rr l ; * 390 srl h rr l ; * 195 srl h rr l ; * 97.5 add hl, hl ; * 195 add hl, hl ; * 390 srl h rr l ; * 195 add hl, hl ; * 390 srl h rr l ; * 195 add hl, hl ; * 390 srl h rr l ; * 195 add hl, hl ; * 390 srl h rr l ; * 195 add hl, hl ; * 390 srl h rr l ; * 195 add hl, hl ; * 390 srl h rr l ; * 195 add hl, hl ; * 390 srl h rr l ; * 195 jr done_convert First a bunch of random left shifts and additions that overshoot the target, then an even more directionless attempt of correcting the result that seems stuck in a loop until it just gives up. Kind of reminds me of "PanicSort" (xkcd.com/1185) And as you mentioned, it ignores overflow, which might be a real problem since even if it worked correctly, it could only handle amounts up to $655.35. A better solution would have used BCD arithmetic, which the Z80 provides some dedicated instructions for.