I appreciate all the positive comments!
I have totally decoupled the Fetch from the Display now.
I realise that I have had the fetch model correct all along. But I was confused that the fetch cycles could be something like 42 cycles long, and then simply BPLMOD -4 to ensure that a valid line is fetched... Then just use the Display window to clip out the pixels that aren't needed... Not super impressed, as this is difficult to optimise from an emulation view point.
The issue is how Denise actually uses the BLPxDAT data...
Looking at the hires Workbench display we can see that
1. Fetch starts at DMA cycle 56, (up to) 4 bitplane words are now fetched into the BPLxDAT registers and they are ready for use by Denise by cycle 59.
2. But the DIW doesn't start drawing until pixel 129 (DMA Cycle 64.5), so the first fetch is discarded (good because the first 16 pixels of each line are just junk anyway).
3. The next DMA fetch starts on cycle 60, with the BPLxDTA registers being ready for use by cycle 63...
4. But DIW doesn't start drawing until cycle 64.5...
5. The next DMA fetch starts on cycle 64, BLT4DAT now contains the word from the next fetch cycle.
6. Half a cycle later Denise starts drawing the data found the BLTxDAT registers... Now only BLT3DAT, BLT2DAT and BLT1DAT registers are valid.
My solution is to have Denise counters running 2.5 cycles early, So when it uses the BLTxDAT registers they contain the correct data for that fetch cycle...
So far this is working for both KS1.3 and KS3.1 normal Hires and Lowres screens (I've not even attempted BPLCON1 emulation yet), but feels like a horrid kludge which is going to come back and bite me at some point (The HRM does state that there is a 5 cycle delay at the end of the fetch and the first position on screen, but it's unclear if this is a fetching delay or a drawing delay
)... Any suggestions?
-Edit- I've also made the decision to split the Hires and Lores code paths completely.