|
Post by mrbombermillzy on Apr 30, 2016 19:24:10 GMT
I'm not at all sure what the problem is here mirko. At first I was thinking noisy clock signal or a fussy vdc ram refresh rate. However, the display seems to be corrupt for 2/3rds of the way down and then it is fine!? I wonder if its the cga to rgb adapter you are using. Is there any chance you can try a 'safe' resolution; perhaps 720x200 on your 1084 monitor without any in between circuits interfering? (I'm not sure that my converter circuit isn't causing some colour saturation or artifact problems with my testing, but I'm generally just about getting by with it.)
Im getting to the point where I'm thinking of breaking out the oscilloscope and testing the vdc signal timings. I just don't have much time. (Just finding my 'scope will be a major ordeal!)
Also its useless to just get the correct results on my equipment if other vdc revisions are going to act differently.
To this end I've just invested in another 128d :-) I should get that in 2 weeks and I will retest my vdc settings on 3 different machines along with the rev. number of each one along with any variations that I notice.
However, in the meantime, can you try the lower resolution that I suggested? Also, if it is still the same result, is there any way you can disconnect the SCPU and any other carts/peripherals?
|
|
|
Post by mrbombermillzy on Apr 26, 2016 19:02:05 GMT
Ok, well try incrementing the refresh (from an initial value of 0) in steps of +1 and see what happens. Even if you just get to 3 you should see some improvement in the level of corruption.
|
|
|
Post by mrbombermillzy on Apr 26, 2016 18:12:34 GMT
I suggest incrementing from 0 upwards as just leaving the value at the default may not always get your monitor to sync. The character corruption does get eliminated so dont worry about that not clearing up...I would rather you get corrupt characters to start with rather than send your monitor out of sync..much safer! :-)
|
|
|
Post by mrbombermillzy on Apr 25, 2016 17:49:18 GMT
Try incrementing the vram refresh rate (register 36) in steps of +1 (from 0) until your monitor starts to get shaky. Mine can only get to about 5 before it starts having trouble. You should begin to see the corruption getting less problematic as you raise the number of refreshes per scanline value. However, as the characters get less corrupt your monitor will have more trouble stabilizing as you are now adding extra refresh time to the horizontal frame timings. This is the balance you have to find on YOUR monitor. Let me know what results you get.
|
|
|
Post by mrbombermillzy on Apr 24, 2016 16:05:58 GMT
That looks much more corrupted than what I get! Have you set the vram refresh down as low as it will go? Also what VDC version/revision do you have?
|
|
|
Post by mrbombermillzy on Apr 18, 2016 18:22:12 GMT
Hey hydro!
Im currently working for UPS and have the same problem, so I completely understand what you mean.
In this day and age its trying to get things out and make a profit as quick as you can, cutting as many corners as you can.
I have complained to management several times now about not being happy having to blatantly lie about my work.
I would give an example but knowing my luck, a UPS web crawl spider bot or google linked word flagging system will catch me out and they will sack me for 'lying'! Lol
And going back to your description, the world is made harder for those who tell the truth more often...you wont get job x because you havent lied through your teeth on your CV,etc,etc.
I know it sucks but at least you have your integrity, which is worth much more. (Although you will be skint for it with a worse job!) :-)
|
|
|
Post by mrbombermillzy on Apr 2, 2016 15:11:02 GMT
General notes/conclusions:
On old crt equipment at least, there is a constant battle of compromise between monitor stability and char corruption.
The way I see it, you can either buy a modern tft/flatscreen that has either a digital rgb input (or perhaps invest in a converter for a rgba screen), or you can replace your VDC vram chips for ones that require less refresh intervals before losing/partially losing their contents. The latter solution is probably a bit much.
I will conduct further testing when I have time, but that is something I really dont have atm, so I am writing this to hopfully help others to test the boundaries of their own equipment.
It would be great to hear about the results others have had using these values that I have provided as a starting point for further enhancing the C128 VDC resolution.
Perhaps if you could let me know in this thread what monitor you have and the vdc version and revision (if you know it) and a description of how well your setup coped with the chosen resolution.
With this information, we can begin to formulate a best safe average resolution for use in games, etc.
Give it a go, but be careful!
Phew! Thats it from me for a while now. :-)
|
|
|
Post by mrbombermillzy on Apr 2, 2016 15:00:10 GMT
Register 6 notes:
My monitor can cope with 37 visible vertical chars before sync is lost.
Register 7 notes:
A sync position of 38 is adequate for my monitor to display 37 characters vertically (296 pixels). The vsync pulse being much smaller than the h. one (only 4 scanlines).
I still need to work on some adjustments so that I can possibly add 1 or maybe 2 extra chars to the v. Displayed char count.
|
|
|
Post by mrbombermillzy on Apr 2, 2016 14:55:36 GMT
Register 3 notes:
Vertical pulse size (in scanlines) should be left as standard at 4 scanlines (register value of AND 64). However, h. pulse width can certainly be reduced from its standard value of 10 chars (reg value of AND 9). My monitor can drop the pulse width down to 4 chars (AND 3 value).
Register 2 notes:
So far, we can set high h. char displayed number values but will not see all the chars on screen unless we adjust the h. sync position. Set at 102 this brings the character starting display position to within 1 char of the h. pulse on my monitor.
Register 34 notes:
You will find the no of h. displayed chars will not be visible unless you also reduce this value. This register basically adds extra chars to the right side of the display.
My monitor, with a value of 105 can take the visible displayed characters to within 1 char of the h. pulse.
Note that this does have consequences;
Being so close to the h. pulse (with the pulse being on the right) reduces the colour intensity (as described in reg 0 notes).
|
|
|
Post by mrbombermillzy on Apr 2, 2016 14:44:50 GMT
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.
|
|