It's not like I wasted several hours trying to fix it back to 60Hzsteve3000 wrote:That's great! (well the 57Hz is great, not the missing 2 pixels)
It was my test - forgot to explain that. 57Hz means your CR code is good.
Okay, that rules out CR completely then.
We know the parameters are geometrically correct, as the screen displays okay under emulation with all pixels showing. I have however manipulated all the parameters, so the screen doesn't move during pokemode. Some values needed increasing by 2, some reducing by 2. The conversions are now:steve3000 wrote:The pixel left/right shift is very strange. You've confirmed your code gives the same result as mine in the VIDCompare programme, so since we've gone about this with two different translation methods (actually three if you count my BASIC routine), then we can be fairly sure we're getting the 'right' values. So I'm not sure why the shift is happening. I would just double-check your HSWR code though (I'll check mine when I'm back), as it is the shift that is not correct - the left/right chopping occur as a result of that 2 pixel shift...(although if you do solve HSWR, then check how HDSR/HDER respond with the fixed HSWR). If we can't spot an error in our translation, then I can go back to the RO source and see if there's anything obvious there which RO does and we don't...
HCR - 6
HSWR - 8
HBSR - 16
HDSR / HDER (+3 1bit, +11 2bit, +15 4bit, +17 8bit)
HBER - 16
HCSR - 11
HIR
VCR + 32
VSWR - 1
VBSR - 1
VDSR - 1
VDER - 1
VBER - 1
VCSR - 1
VCER - 1