New higher resolution C128 VDC mode

Like you imply, this is pushing the theoretical limits and I would be very surprised if most monitors can reach this target resolution on screen, at least without some sort of manual adjustment.

As Ive warned previously, trying to hit this limit may damage your monitor. Its only that I have 2 spare Sony PVMs that I am attempting these crazy modes. As you may recall I have already lost a C= Ranger monitor in the quest for breaking the current C128 VDC resolution size.

Obviously, there is still work to be done, like how to avoid character/attribute data corruption. I had plenty of that in testing and pushing these limits. However, I will point out that the corruption was minimized at certain resolutions as opposed to others. I could not formulate a pattern but it was definitely not increasing as the resolution was increased, so perhaps not a memory bandwidth problem.

I also discovered a neat trick where setting the h.pulse width just below its stable limit would cause a slow screen fade to black. Probably not something to do on a regular basis but still interesting.

I have attempted all this from a practical side as I dont believe there is enough decent literature on the xx83 (let alone the xx68) VDC. The C128 PRG just seems to dictate the registers as if someone was told what to write but didnt know what it meant, and the other couple of books that deal with the VDC to any detailed extent dont provide much more insight.

There is fairly decent information on the 6545crtc and its derivatives including the ones that went into the C= PETs but who knows what different tweaks went into the later VDC and its revisions?

That is so cool mrbombermillzy !  I especially like pic#2 with the H and V sync visible!

I hope you made good notes, and can post the register settings you used!

I tried calculating value, and came up with 115 cells (920 pixels) horizontally ...

Reg 0: 126 +1 = 127 horizontal (8-bit) cells = 127 * 8 = 1016 "virtual" pixels (IMPORTANT: includes border and sync!!)
Reg 1: 115 +0 = 115 horizontal displayed (8-bit) cells = 920 "real" pixels
Reg 2: 116 +0 = H-SYNC position... after 115 visible cells, and 1 (right) border cells = 8 (right) border pixels [ this leaves 127 - 116 = 11 characters for SYNC + (left) border ]
Reg 3: x9 = H-SYNC width (+1 assumed) = 10 (8-bit) cells = 80 "invisible" pixels [ which leaves 11 - 10 = 1 characters (8 pixels) for (left) border ]
Reg $16 (22): $78 (standard value for 8x8 cells)
Reg $22 (34): 126 = display begin (blanking end) = 127 (total cells) - 1 ... left border will be blanked 1*8 = 8 pixels (visible left border = 8 - 8 = 0 pixels)
Reg $23 (35): 115 = display end (blanking start) = 116 (H-Sync position) - 1 ... right border will be blanked 8 pixels (visible right border = 8 - 8 = 0 pixels)

This assumes the VDC needs at least 1 left and 1 right border cell, and the number of H-Sync cells is 1 plus the value in (low bits of) register 3.

Of course your image shows you can do without any border?  Have you tried reverse-video mode to see if any horizontal border remains?  If that is true (no border at all), then I'm guessing you also reduced blanking to zero also (the display enable/begin registers)?

And if your counting is correct (120 horizontal chars), then I guess you also reduced the H-Sync width by a little (down to 7 chars) or maybe increased the horizontal total?

Hmmm, I wonder what is vertical max on PAL monitor?

Oh yeah, almost forgot to ask... are the characters on far left and right of screen corrupt?  Or did they just happen to be *** on every other line?

Anyway, thanks for sharing.  Great work!

---

[edit]
Oh, first part was written before seeing new 1024 mode! So yeah, you are obviously increasing horizontal total (and reducing horizontal sync rate).

Like you, I agree the docs for VDC by CBM were not well-written and seem to contain errors. And nobody else seems to have clarified register use.

That's why I'm still hoping you made some notes about the VDC register values you used (and what resulted on-screen). I have several tables of values I plan to test once I find the time to sit down in front of my real Commie...

Oh yes, but looking closer at posted pics, there is very obvious corruption in there! Very interesting corruption indeed.  Also interesting it doesn't get worse as you continue to increase resolution!  So now I really need to sit down in front of my Commie and see what is max before it starts to foul up, and maybe why it gets messed up??  Alas we may never know why!

Reg 36 notes:

Vram refresh values at minimum (=0) do not take the horizontal time from the monitor so they are visibly stable. However, the displayed chars suffer from corruption by the lack of ram refreshes. But as the refreshes per scanline value increases to =5 the char corruption becomes less prominent. Alas, the pvm starts to lose h. stability with raster jitter and chars curling in the h. plane.

Always set reg 36 to =0 then dial in all the other register values. Then after that you can attempt to increase vram refresh amount.
If you dont do it this way round, you may not get a display after changing a register.

Register 1 notes:

As stated in reg 0 notes, the flyback pulse for my monitor needs at least 4 chars to keep the screen from totally losing sync. Therefore the maximum displayed no of chars must be 128/1024 pixels.

N.B:  Users with 15khz scanrate capable tft screens may be able to reduce the flyback pulse further as no retrace time should be necessary.