I am finding another problem.

Try out this program:

cls()
poke(0x8000,5)
?peek(0x8000)
memset(0x8000,0,0x8000)
?peek(0x8000)

You get back 5 each time, which is incorrect as we just cleared memory.

Apparently 0x8000 is being misread as zero when used as a hexadecimal argument for a command.

Yeah, it does look like memset does nothing when its third argument is negative, but that also seems like it might be intended behavior?

Well how do you clear out the top memory ? :) No I'm pretty sure it needs to read back internally 32768. If it can read that high with 0x8000 it should be able to count that high too if only in this instance.

Currently I am using memset() at 0x7FFF length and then POKE() the last value which is clumsy to say the least.

I agree that the third argument should really be treated as unsigned, where 0x8000..0xffff are 32768..65535.

For the moment you could bodge it with something like this, so your outer source code doesn't look ugly:

_memset,memset=memset,function(d,v,l)
  while(l<0) _memset(d,v,32767) d+=32767 l-=32767
  return _memset(d,v,l)
end

-- probably need memcpy too
_memcpy,memcpy=memcpy,function(d,s,l)
  while(l<0) _memcpy(d,s,32767) d+=32767 s+=32767 l-=32767
  return _memcpy(d,s,l)
end

With that, you could even clear vram + upper ram, e.g. memset(0x6000,0,0xa000). Basically, it'd work the way you expect, except it's a bodge.

Ah, ooh ... Not quite so busy for me, @Felice. I am just using this:

memset(0x8000,0,0x7fff)
poke(0xffff,0)

Right, I was just offering a bodge so you could write it the way it ought to be, and then if zep fixes memset() and memcpy(), then you just delete the bodge and your code is good to go.