Help
The params. There's also player damage (0x40) and invincibility (0x80).
int spread_speed = current_param & 0x03;
int current_cycle = (current_param & 0x3C) >> 2;
This is immediately followed by a suspicious line of code:
spread_speed |= spread_speed << 1;
Here's what this looks like in GAME2.ASM from MZX 2.51. Notably there is a comment before it that doesn't match what is actually happening:
; BL= SPEED BITS << 2 + SPEED BITS
and bl,1+2
mov al,bl
add bl,bl
setflag bl,al
If the behavior here matched the comment, this would explain why the cycle count is 4 bits; speed 0 would map to 0 cycle counts, speed 1 to 5 cycle counts, speed 2 to 10 cycle counts, and speed 3 to 15 cycle counts. The real behavior doesn't make as much sense though, mapping speed 0 to 0 cycle counts, speed 1 to 3 cycle counts, speed 2 to 6 cycle counts, and speed 3 to 7 cycle counts. This suggests 3 bits of cycle count would suffice (as the remaining 4th bit is completely wasted).
For speeds 1 ("2") and 3 ("4"), the slime blob doesn't even wait this long though, because of the next issue in the code:
// Clear cycle
current_param &= 0xC7;
This fails to clear the lowest bit of the cycle count, meaning slimes at speed 1 ("2") and 3 ("4") will actually wait 1 cycle count less. The result is that the two slowest slime speeds are actually the same!
More to the point, though, this failed bound suggests the spread speed was going to be expanded to 3 bits but this wasn't properly implemented. This is supported by the fact that the slime blob param dialog previously allowed selecting values from 1 to 8. The wrong bound for the dialog goes all the way back to 2.02.
Expanding the slime blob spread speed bound would clean up/version lock the current awkward behavior and seems in line with what was intended to happen here. If this happens it should be a 3.00 change.