Is there any implementation of scrypt that allows a specific limit on memory? The answerer has commented that scrypt's memory use is "only a function of r". $\:$ However, he has

not addressed my argument that it also depends on N, in one of my comments from over 5 days ago.

I had somehow gotten the impression that scrypt offered a separate memory-factor in addition

to its main work-factor. $\:$ However, the (original?) scrypt paper does not have such a parameter.


  Do any implementations of scrypt offer a way to limit
  
  its memory usage without that limiting its runtime?


Looking at that paper, I see that there would be an obvious way to do so: in the definition of 

ROMix (on page 6), add an input M and replace the instances of N in steps 2 and 7 with M.

Alternatively, one could replace those two Ns with max(M,N) and replace

the N in step 6 with max(N,(2*N)-M), or with something similar to that.
Deﬁnition 4: The key derivation function scrypt is deﬁned as
  scrypt(P, S, N, r, p, dkLen) = MFcryptHMAC SHA256,SMixr(P, S, N, p, dkLen)
  
  The limits on the size of p and dkLen exist as a result of a corresponding limit on the length of key produced by PBKDF.
  
  Users of scrypt can tune the parameters N, r, and p according to the amount
  of memory and computing power available, the latency-bandwidth product of the
  memory subsystem, and the amount of parallelism desired; at the current time,
  taking r = 8 and p = 1 appears to yield good results, but as memory latency
  and CPU parallelism increase it is likely that the optimum values for both r and
  p will increase. Note also that since the computations of SMix are independent, a
  large value of p can be used to increase the computational cost of scrypt without
  increasing the memory usage; so we can expect scrypt to remain useful even if the
  growth rates of CPU power and memory capacity diverge.


Source.

This SO answer elaborates on the factors more clearly.


  $N$: General work factor, iteration count.
  $r$: blocksize in use for underlying hash; fine-tunes the relative memory-cost.
  $p$: parallelization factor; fine-tunes the relative cpu-cost.


Source.

If you want to increase memory hardness, raise r. This will also raise execution time, so you might want to lower N at the same time.