SpritesMind.Net

First off, I am fully aware that H32 is not officially supported for the 32X. But it does work.

What I have noticed though, at least on my setup (NTSC model 2), is when H32 is being used, the 32X frame is shifted to the right about four pixels, revealing a slither of the Genesis graphics on the left side, while the right side of the 32X frame extending past the end of the Genesis frame by a proportional four pixels. As soon as I go back into H40, the 32X frame will go back to it's normal horizontal position and correctly line up with the Genesis frame.

1) Does anyone know why this happens?

2) Does anyone know if this happens on all Genesis/32X/region combinations?

3) Does anyone have a clever way to get around this to try and get the two frames to line up?

1) The problem is that MD uses a hack to make H320 timings match those of H256 (sorry, I don't like the H32 and H40 names). The way it is done is by generating an external pixel clock (EDCLK) where some pixels are slowed down during Hsync period. It is why you set bit 7 in VDP register $0C when using H320, it selects the external pixel clock instead of internal one, where all pixels are always 8x MCLKs long or 10x in H256. Using external pixel clock in H256 resuts in messed up display since most pixels are 8x MCLKs long while normal H256 has only 10x MCLK long pixels.

32X actually uses the EDCLK signal to align itself with MD output, and since H256 doesn't use this signal at all, things end up offset. It is why H256 is "not suppored". In addition H256 has slightly different centering of the image compared to H320.

Similarly, using H320 with internal pixel clock (bit7 of $0C zero) where all pixels are 8x MCLKs long (I call it H320F, where F means fast due to faster video timings) will also be offset on 32X, although to what extent I'm not sure.

2) it is same for all hardware combinations

3) there's no fixing this