I was going to post something like that anyway, then you ninja'd me

Ugg. I forgot how absurdly limited the z80 instruction set is. All my C/x86 tricks are LESS efficient in z80.

Bam!

Code:


Of course, this is going to be fastest on a 64-bit CPU...

Regardless, if speed is what you want, a lookup table will easily win

On a similar note, write a routine that will take an 8-bit number and double each bit to get a 16-bit value. For example, 10110001 -> 1100111100000011. No look-up tables allowed, of course.

I have 34 bytes and 136 cycles (input in A, output in HL)

Edit2: Fixed counting error (again)

I've read hakmem and the stanford bit twiddling file too

I'm posting this code to save it until I try it out. I have no idea how fast it will be (or even how many bytes it is, but I like its style

The last 2 lines are optional, since calc84maniac didn't specify the routine had to be reusable. Without them I come to 37 bytes. Not sure how many CCs, but it'll vary depending on the number of 1s and 0s in the byte passed in a,

Code:


[edit]
fixed, one of my bit patterns was off. still not sure how many cc's.

136 clocks. 34 bytes. I win.
Edit: addition fail. 140 clocks 135 bytes.

Code:

Is that the whole thing? Why are you rr l'ing before you've assigned a value to l?

I rr l so I can get what was in carry later

My chart that I have beside it is What's in A, what's in Carry, and what did I rr l.

Shouldn't there be an "rrca" before the first line?

calc84, you are correct. I must have missed that on the copy paste. I'll fix that now.

Here's mine:

Code:

Hello!

It's not my turn to post, but I'm going to anyway 'cause I need a routine. Here is the task: create a routine that clears (white) a horizontal line on screen. BUT - not just any horizontal line, but a horizontal line that starts at h, l (x, y) and has a width of a.
So, if I were to, say, use this syntax:
ld h, 15
ld l, 20
ld a, 10
call ClearHorizLine
I would expect a horizontal line to be cleared at (15, 20) on screen that was 10 pixels long.

And....GO!

That isn't an algorithm challenge, its a "you're too lazy to just code it yourself" challenge, and those challenges suck.

Bah! Be that as it may, these kind of routines are huge and deserve optimization.

My solution, 70 bytes (I know smaller is possible, but I'm going for speed as well as size)

Code:

It's not as good as calcs, but it's what I've got

Code: