Changes

b) The CRTC wrap-around address can end up anywhere in the middle of the display. eg. the first byte of a sprite may be at address #c7ff, the next horizontal byte will be at address #c000. So the sprite rendering routine can't simply use a simple Z80 instruction like INC L or INC HL to move to the next byte across, it needs to use either a combinations of INC HL: RES 3,H for even lines and INC HL: RES 4,H: SET 3,H for some odd lines, INC HL: SET 4,H: SET 3,H for others. There are other ways to get around this problem using AND's, OR's, tables etc. The best way to maintain speed may be to test if the overlap will happen before rendering the sprite and use fast routines if it doesn't.