|
|
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 mirkosoft on Apr 27, 2016 20:06:42 GMT
I tried to increment values, results are in attachment, I must to do it with SCPU @1mhz standard.zip (2.74 MB) interlaced.zip (2.77 MB) 23 |
|
|
|
Post by mirkosoft on Apr 28, 2016 22:34:18 GMT
So, I tested it again, now with SCPU @1mhz, results are bad. I increased VRAM refresh from 0 to 3. I mean it causes adapter CGA2VGA, I can't risk my 1084... screenshots are attached.
Miro normal.zip (2.92 MB)interlaced.zip (2.86 MB) |
|
|
|
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 mirkosoft on Apr 30, 2016 19:31:01 GMT
I can "remove" SCPU by simple way: Enable switch - it needs not removing phisically, this makes machine like stock config even without JiffyDOS.
I tested succesfully on my 1084 resolution 800x600, also 720x700 - no problem.
Miro
|
|
|
|
Post by mrbombermillzy on Apr 30, 2016 19:42:35 GMT
If you are getting OK results with your 1084 at 800x600 then I would be pretty sure that its either your cga to VGA converter and/or the monitor you are using it with (is it a flat screen or crt VGA monitor?).
My next step if your 1084 handled 800x600 well would be to suggest the next resolution up and see how it goes, but I respect your choice of not wanting to risk ruining your monitor.
Like I said before, perhaps we need to settle on a safe standard resolution that ALL our monitors can handle...800x600 is a pretty good place to stop :-)
|
|
|
|
Post by mirkosoft on Apr 30, 2016 19:55:55 GMT
In my eyes it is like this:
My CGA2VGA converter displays all correctly, 800x600 mode too - it have only one limit 1600x1200 pixels, I'm using many display methods to view or capture screenshots/video - by using this adapter, but I forgot anything... it can be problem - RGBI2SV - this allows me to display also stable non flickering image, but SV (S-Video) resolution is limited to 720 max. 768 pixels wide and 576 pixels high resolution.
But not problem to test! I forgot it!
I have my 1084 for one purpose only: using lightpen (I want later add lightpen support to The Ace OS to control system by this device - very interesant was cOS which is by interface controlled by touch). If I lost 1084 - I lost lightpen control, and for me not important lightgun games support...
I'm really balancing with decision... Please write all possible risks and what can be damaged - also if whole monitor work or RGBI only - how to get control over it if anything damages...
This night I'll test RGBI2SV.
Miro
|
|
|
|
Post by mrbombermillzy on Apr 30, 2016 20:37:24 GMT
The problem, in a nutshell, is getting 1024 horizontal pixels at a 15khz scan rate. It is pretty much at the limit timing wise of a crt monitor. Some monitors handle this stuff better than others.
If you want to attempt higher resolutions as safely as possible, then go up gradually. Try a slightly higher resolution then check for any high pitched noises or jittering on the display. If its OK, then go to the next resolution. Also leave the v. Res at 200 for now to minimise strain.
As for what could go wrong with the monitor.. I don't really know mirko, not being a TV engineer.
On my Aydin Ranger, the horizontal deflection failed (It basically draws everything in a single pixel wide line vertically on the screen). To be fair I hadn't found the safe boundaries and was pushing forward with 'bad' settings. (You can't find the limits until you pass them).
So I've basically tried to help you in that area so you don't have to do any wildly wrong settings. Other than that, its up to you.
|
|
|
|
Post by mirkosoft on May 2, 2016 17:13:32 GMT
So, I tested RGBI2SV adapter and results are perfect - look into archives in attachment. Only one thing is for me ?unknown? - why interlaced mode looks like standard?
Perfect, only create handler to use it and it will be great!
Miro normal.zip (1.95 MB)interlaced.zip (1.6 MB) |
|
|
|
Post by mrbombermillzy on May 2, 2016 18:56:42 GMT
Well done :-)
I gather that the screen pictures as they go up have more refresh time applied?
So what resolution was this? (Please don't make me count the characters in the photos...my poor eyes!)
You will get 'proper' interlace by setting it to either 254 or 253. I can't remember offhand which one. One of the settings is line doubling mode and the other is true interlace.
|
|
