|
Post by mrbombermillzy on Apr 2, 2016 14:41:08 GMT
Reg 0 notes:
In theory, to fit the 15khz standard screen timing, a resolution of approx 1024x256 @50hz should be possible, taking into account other timings like flyback time. Therefore, this resolution should be attainable (as I have now shown). By setting register 0 to 132 we have a total of 132 chars/1056 pixels. My monitor needs 4 chars (minimum) for flyback pulse when the displayed chars are pushed right up on either side of the h. pulse. Even then the colour saturation level fades down to nearly grey. I believe this is because the monitor cant cope rather than the VDC. (Possibly the signal levels in my home made rgbi to rgba circuit are not 100% correct).
|
|
|
Post by mrbombermillzy on Apr 2, 2016 14:33:28 GMT
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.
|
|
|
Post by mrbombermillzy on Apr 2, 2016 14:27:02 GMT
Here are the settings that I used to get the high resolution modes on the VDC display along with the important notes and observations that I logged. Although not being as thorough as I would have liked (time always being short) and perhaps not 100% accurate (especially concerning error distinction between VDC chip and monitor) I hope that I can at least give you guys some idea as to which settings to explore.
Remember, I have tested these modes on a Sony PVM 20M2E monitor which was a pretty top notch broadcast quality monitor so it may be more capable and/or less fragile than your screen. I suggest that if you really want to have a go, try the lower resolution settings first and check for any whining or odd smells/smoke, etc.
I would also recommend setting the registers in the order I have presented them here. Often setting certain ones before others can result in loss of sync/control or worse.
960x200:
Reg: Val: 36 0 0 132 1 128 3 74 2 102 34 112
960x296:
6 37 7 38
960x592i:
8 253
1024x200:
36 0 0 132 1 128 3 67 2 102 34 105
1024x296/i: set regs 6,7 and 8 as above
|
|
|
Post by mrbombermillzy on Mar 29, 2016 20:26:02 GMT
...and finally... By tweaking and coaxing the registers in a certain order and managing to shave some of the h.flyback pulse size, I now present you with 1024x200! 1024x296/592i was also managed as before, but I didnt take photos for that. Also at some point I will tweak to get at least one more v.char so we can have 1024x304/608i, but my eyes are almost bleeding and my monitor is close to packing up, so maybe another time. Although I have said this is really pushing the boundaries I am sure there should be some more modern equipment that should be able to display the whole frame on screen without having the problems that these old and probably mis-adjusted monitors show. At least you now know it is possible :-)
|
|
|
Post by mrbombermillzy on Mar 29, 2016 9:06:37 GMT
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?
|
|
|
Post by mrbombermillzy on Mar 28, 2016 19:12:50 GMT
So I had a bit of spare time to look into this again. Its out of my scope to look into the VDC bandwith character corruption problems which was pointed out by Tokra and Hydrophilic previously. This will be studied at a later date. For now though I am doing my best with the inadequate tools that I have (i.e. my current 15khz monitor) to bring a higher resolution for the C128. I have had to show the screen without all the characters being visible as the h.size needs adjusting and that pot is inside the cabinet, which will be a real PITA to get to currently: As you can see, even with the characters which are not visible over the horizontal borders there are 110 horizontal characters and the visible h.res is about 880 pixels wide. Now if I show you a skewed picture which displays the edges (along with the h/v sync pulses which is very useful) you should be able to count the extra characters which should be able to be displayed once I can get to the h.size adjustment: You can see Ive maxed out the characters right up to the h.pulse on either side. I also tried to skim some time off of the pulse width but the monitor was starting to complain so I had to back off. :-) After counting the extra characters from this image with the characters that were on the previous screen image, I came to a total of 120 characters which should make this screen 960x200 resolution. Then after maxing out the vertical resolution we get the below: Which gives a 960x296/960x592i resolution, although Im sure I can squeeze another 2 characters in the vertical size with a bit of adjusting here and there. However its getting late and my monitor and eyes have had enough for now. :-)
|
|
|
Post by mrbombermillzy on Feb 10, 2016 19:17:15 GMT
Oh and just for the record, I did try your program and it was corrupting by the third iteration.I have a 128d with the 64k xx68 vdc.
|
|
|
Post by mrbombermillzy on Feb 10, 2016 18:18:22 GMT
Thinking about it guys, I think we will be wasting our time looking to deeply into this if you consider that the vdc is a bit touchy about being ready for data, even from assembly. I dont think we are working on solid foundations using this basic program to acess the vdc and wondering (without testing the ready flag or possibly an interrupt) why its going wrong. What I propose is we should write a vdc test suite in assembly which is a mix of tokra and my basic program plus extra stuff mixed into one.
I have quite a busy schedule for the next few days but I will try to get something up and running soon. Or perhaps we should discuss what to include first! Lol
What do you think? :-)
|
|
|
Post by mrbombermillzy on Feb 9, 2016 20:16:30 GMT
Oh I see. So apart from what I described as the fault you are also getting a character dropped and spat out somewhere else or not at all. I didnt look at the last pics so I wasnt aware of what you were really getting at. Hmm.. This shouldnt be a problem at that character count. I will investigate further. Give me a couple of days as Im quite busy atm and I will run your program and try to find out whats going on.
|
|
|
Post by mrbombermillzy on Feb 9, 2016 19:34:46 GMT
hydrophilic : lol yes very indepth analysis. We will get into colour cell limits and vdc bandwith issues when I have a bit more time! :-) However, for such a simple program (and its not trying any realtime maxing out of the vdc) then all this is overkill for the above problem.
|
|