A sprite is a rectangular box of pixels. It usually has a mask, to skip pixels where the background should be seen. Often there is one specific color reserved to avoid a mask. So the code fetches a pixelcolor and if its the special pixelcolor the "plotting" of the pixel will just be skipped and the position increased.
Make a routine which can set a pixel, set counters on the outside, calculate frame buffer offsets and line deltas (the outer loop setup) and then progress through each horizontal line. While you do that, you will realize a lot of possible optimizations. For example its terribly slow if you work on a pixel basis where the same memory adress is fetched, manipulated and written repeatedly - so you change it so each memory access happens only once and if possible, writes multiple pixels at once (as a democoder you would for example realize that a 65k color framebuffer uses 16bit per pixel and therefore you can write 2 or even 4 pixel at once with one write access (write access is the devil - they are usually what costs way more time than anything else).
Find out how to plot a point, add code for a special "mask" (traditionally the deepest black was the mask color), wrap it into a setup and inside a loop to plot X Lines of Y pixels - voila (software) sprites

Hope that helps.
ps: clipping is a special case obviously. Once you managed to plot a sprite into the middle of the screen, you can deal with those.
pps: my description is for a traditional "scanline/spanline renderer". if you implement that, you will also have the basics for a 3d spanline renderer for different shading algorithms. A flat texture of 32x32 is basically the same like a 32x32 sprite.