VDC 8563 was first used in Commodore 900 and there were 2 options: 1024x800 gfx or text console. Details about console I forgot, but I'll search in resources. BTW - 8563 version used in C900 had dedicated 128k RAM. Why was this cutted out I'll never understand, even how was 128k VDC RAM handled. In 64k is place (only data) max. for 1024x512. But nice will be to see 1024px text mode, if you try it. It was overload in very old thread. I'll find link and C900 details and post it here. Of course my posts are not important in compare of emulator developers.
Commodore 64 was great, Commodore 128 is bigger, better, faster and more powerful... Commodore 65 was almost here, but C256 is coming and it will be earthquake...
Your maths should be correct for default values of a PAL c128 with newer ROM but it should be noted pixels per line will not always be a fixed number for all modes the VDC is capable of.
A simple formula to calculate pixels/line is (reg0+(SinglePixelMode?1:0)) x ((reg22>>4)+1).
For PAL c128 with new rom it would be (127+1)x(7+1)=1024 For NTSC with either ROM or PAL c128 with old rom it would be (126+1)x(7+1)=1016
The above assumes pixels/character during blanking and sync pulses is the same as the visible characters. It's been awhile since I've had some free time to play with emulator so I'll need to recheck but I think some of my timing tests I've used to explore other aspects of the VDC confirms the above formula.
Not really talking about 128 modes here, just how I capture the output from the VDC. The goal is to capture every pixel perfectly, digitally so the conversion works from a perfect source of the image. That way you get a VGA signal out as if it was the original picture... The problem of course is capturing every single pixel when you don't know HOW MANY there are lol. It seems my original assumptions about how to do it fail, but thats just how these things go. I have new, better ideas and WILL make this scandoubler work. A nice progressive scan de-interlaced VGA output from the VDC that's compatible with ANY display mode it makes? Lets try! My new method is much more adaptive and should work with more screen modes. I have already managed to view mode 1 mode mania in a de-interlaced VGA output and I can tell you, It looks.. Freaking... AMAZING.
What is this "SinglePixelMode" you are speaking of?
It's just referring to the normal mode of the double pixel feature that is controlled by bit 4 of register 25.
if bit 5 of VDC register 25 is 0 SinglePixelMode =1 (VDC 80 column) - normal
if bit 5 of VDC register 25 is 1 SinglePixelMode =0 (VDC 40 column) - double pixel
By default bit 4 is not set so SinglePixeMode would equal 1 in my formula.
Another useful formula once you know the pixels/line is clock speed/pixels per line = horizontal frequency where clock speed equals 16000000 for normal mode and 8000000 for double pixel mode. e.g when pixels per line = 1024 (default PAL new rom), horizontal frequency = 16000000/1024 = 15625 Hz.
The total pixel count may vary but at least the pixel clock remains constant. I just need to work with watching the hsync pulses instead of counting the pixels in and out. As I said, the advantage is that it should then deal with random modes better and push a little of the work out to the monitor connected.