The 1FPS is caused by the fact that the images are taken with a mechanical shutter, which slows everything down, and each image must be encoded separately.
I'm not aware of any evidence the mechanical shutter is the limiting factor here. Obviously running it at video frame rate would be bad from a component life POV, but the actual mechanism can
move very fast.
IMO, the main contributors are reading out the sensor to camera RAM, encoding jpeg or video, and writing to SD.
Superficially, you'd expect going from 8 MP to 2 MP to make each of these steps take 1/4 the time, since they are all essentially bandwidth limited. So naively 4 FPS should be possible. We can sanity check this by noting 640x480 video is ~0.3MP, which by the same calculation would be ~27 FPS, which is close enough to the actual video spec of 640x480 @ 30.
The actual S3 continuous shoot spec is better (2.3 FPS in "high speed continuous"), so there might even be some headroom... However, there's no guarantee you can actually program the hardware to do readout or encoding at arbitrary resolutions, and if it is possible, significant reverse engineering and new development would be required to do it.
But I bet that there might be some juice in it to maybe achieve a better resolution... The only issue, is that, I'm not a very good programmer,
So here's the thing. You're arguing with people who
are good programmers or at least have well over a decade of experience with these cameras firmware, apparently based on no more than gut feeling.
We're telling you based on our experience that it's unlikely to be possible, and that just figuring out exactly what is possible would be a lot of work. You could be right, but the only way you are likely to convince us is to do the work.
and CHDK doesn't have any tutorials or very good documentation so I don't think I can help...
The primary thing required is reverse engineering, which by definition involves figuring out things that you don't have good documentation for