Well, I suppose it's not THAT bad. It's just annoying as heck to work out a usable cycle 73 hmove routine. The best I've worked out so far is to use a table, which of course sacrifices about 160 bytes of rom for the table. Assuming that hitting RESPx at cycle 76 counts as the end of a scanline and not the beginning of the next then the table I have written should work out... hopefully.

Not really in the mood to muck with it right now beyond inserting the table into the rom.

This is the table of values I've come up with, where the top 4 bits hold the finetuning for the HMOVE and the lower 4 bits hold the loop counter needed to position the RESPx to the proper cycle. Tried to set it up so the routine would have time to do a few extra little things prior to starting the loop if needed. Not the best solution I'm sure, assuming it even works, but for now it'll have to do.

TABLE_Cycle73 ; Given X 0-159, it will retrieve the fine/coarse adjustment.
   .byte                           $10, $00, $F0, $E0, $D0, $C0, $B0, $A0, $90, $80
   .byte  $61, $51, $41, $31, $21, $11, $01, $F1, $E1, $D1, $C1, $B1, $A1, $91, $81
   .byte  $62, $52, $42, $32, $22, $12, $02, $F2, $E2, $D2, $C2, $B2, $A2, $92, $82
   .byte  $63, $53, $43, $33, $23, $13, $03, $F3, $E3, $D3, $C3, $B3, $A3, $93, $83     
   .byte  $64, $54, $44, $34, $24, $14, $04, $F4, $E4, $D4, $C4, $B4, $A4, $94, $84
   .byte  $65, $55, $45, $35, $25, $15, $05, $F5, $E5, $D5, $C5, $B5, $A5, $95, $85
   .byte  $66, $56, $46, $36, $26, $16, $06, $F6, $E6, $D6, $C6, $B6, $A6, $96, $86
   .byte  $67, $57, $47, $37, $27, $17, $07, $F7, $E7, $D7, $C7, $B7, $A7, $97, $87
   .byte  $68, $58, $48, $38, $28, $18, $08, $F8, $E8, $D8, $C8, $B8, $A8, $98, $88
   .byte  $69, $59, $49, $39, $29, $19, $09, $F9, $E9, $D9, $C9, $B9, $A9, $99, $89
   .byte  $6A, $5A, $4A, $3A, $2A, $1A, $0A, $FA, $EA, $DA, $CA, $BA, $AA, $9A, $8A