I'm not very good at reading other people's code, so I don't know how much help I'll be. But if I had to guess, I'd guess that the problem is probably in 4858-4861, though I don't understand exactly how those events work.
In 4855, you're using a smooth LERP calculation to make the target gradually close in on the player. But then in 4858-4861 it looks like you're using an abrupt 'stop-start' mechanism to make the camera follow the target: the camera won't move at all until a certain threshold is met, and then as soon as that threshold is met, it will move the full amount of MarginH (or MarginV). I don't know what MarginH is, but let's say it's 5. I can imagine that you might then get a situation where each frame the camera moves something like 0, 0, 0, 5, 0, 0, 5, 5, 0, 0, which would be jittery. I imagine that imposing a hard stop-start mechanism at this stage probably nullifies the smoothness of your LERP calculation in the earlier 4855 stage.
I think you should try and make the camera follow the target in a gradual way, along the same lines of how you have the target following the player. In fact, I wonder if you shouldn't more or less swap the target and camera around, using the smooth LERP calculation for the camera, and placing the hard limits on the target instead. Try something like this:
Code:
4855: Set targetX to range(FloatX[M] + CameraShiftX, CameraMinimumX+160, CameraMaximumX-160)
Set targetY to range(FloatY[M] + CameraShiftY, CameraMinimumY+120, CameraMaximumY-120)*
4858-4861: Disable these for now. Rework them into the code later if still needed
4863: Set cameraX to cameraX + (targetX - cameraX) * 0.2
Set cameraY to cameraY + (targetY - cameraY) * 0.2
* Range(... is just a slightly neater way of doing the Min(Max(... expression you had.