My VDC is defective?!

Started by Hydrophilic, October 13, 2009, 01:41 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Hydrophilic

Thanks for the links.  Now I need to install those 64K RAM chips so I can try the VDC at 750x600! 

Boy am I slacker!  It's been a year now, I haven't done any of the stuff I said I needed to do... well I did make a case for an RGBI 2 SVideo and put up some photos up on my site.  But it was for somebody else (I still need to finish the case for myself).  There aren't any construction details, sorry.  You should be able to see how it was assembled, the only other thing you need to do is drill some holes in a case big enough to hold it.  I don't have a drill template or sizes or anything like that for you.  I'm pretty precise when it comes to software, but real sloppy when it comes to hardware.

Horizontaly trickery?  Now I'm even more curious to try it.  I found my TV will tolerate some fudging of values; quite a bit in the vertical but not so much in the horizontal.  It will blue screen if the values get too far out of wack.

From the CSDb page and the included readme, it is not clear if this is for NTSC or PAL or both.  More importantly it requires burstload device.  I have 2 1571s and they both do an okay job of reading data, but it is nearly impossible to format a disk (newly opened disks mind you) because of the f#$king retarded head design.  So I guess after I install the RAM, I would need to re-write the software as well.  This might take a while...

Question is, would it be better to re-write the demo to use normal KERNAL routines, or re-write the uIEC firmware to support burstload... Now that's a dumb question!  I hope I don't brick my uIEC...
I'm kupo for kupo nuts!

tokra

I came upon this thread yesterday, while trying to understand interlace VDC. I've used interlace in the past, but never really understood HOW the modes worked, I just had some value-tables from a magazine that created different resolutions and just used these.

I'm wondering why the original (non-interlace) VDC-values for registers 4 and 5 are $20/$00 for NTSC and $27/$00 for PAL. According to "Mapping the C128" this comes out to 264 scan lines for NTSC and 320 for PAL - 33*8 / 40*8. Following Hydrophilic's earlier posts this shouldn't be right, since this would come out to 528 (264*2) lines for NTSC and 640 (320*2) for PAL, while the standards call for 525/625 lines respectively.

Do I miss something? Or do the original VDC settings just "bend" the standards a little? I could understand 528 lines for NTSC in that case, but why not use 39 for PAL which would come out to a much closer 624 lines?

Once I get a grip of this I'd like to go back into my old programs to tweak ther interlace-resolutions for more compatibility.

Hydrophilic

You got it right.  They bend the standards.  For example, the popular ZED text editor (very nice, in my opinion) also bends the standards.  According to the author, he just tried different VDC values until he got something that "looked good".  Commodore monitors, in fact most CRTs, are quite flexible in the vertical department.  They tend to be a bit more picky for the horizontal frequencies, but there is still some slack.

These "sloppy" standards cause most of the problems people report when trying to use an LCD display, in my opinion.  I'm not saying that sloppy values are good, but I do think it is amusing that futuristic (modern) equipment lacks the ability to sync to a variety of frequencies like the archaic (vintage) equipment.

The thing that always confused me (still does) is the VDC registers are sometimes X-1, sometimes X, and other times X+1... and the documentation is not always clear as to which "flavor" a particular register requires.  So I guess experimentation was necessary.  Anyway, have fun tweaking!
I'm kupo for kupo nuts!

tokra

I've played around with 50 character-lines on PAL yesterday. According to your earlier calculcations, I set Register 4 to 77 (78*8=624 raster lines) and set register 5 to 1 so I would get 625 lines (= PAL). However any odd value in register 5 leads to the interlace being screwed up as if the interlaced screen is displayed at least a line to low, making the chars unreadable. Any even value however will produce a stable picture with the interlaced chars looking as they should. I tried the NTSC values you are using as well but get the same results, the characters will only be readable with even values in regsiter 5. I'm using a Commodore 1901 monitor at the moment, the original Monitor Commodore suggested for the C128. I'm just in the process of getting a simple monochrome cable for the RGB-port that uses its 50 Hz BAS-signal and once I have this I will do some more tests on my projector.

I'm wondering: Since you are getting a stable picture with odd values in register 5 on NTSC - do you get the unreadable chars with even values?

Furthermore I keep wondering why Commodore chose 640 lines as initital value for PAL instead of 625 or even 624 as would be more logical. Also, why didn't they set register 0 to 127 leading to a very neat 15.625 kHz raster rate (exact PAL). Maybe there is a correlation between the higher raster rate of 15.748 kHz and the 640 lines...? Any idea?

As a bonus, browsing my disks, I found an old 50 char-lines interlace program from the german "64er Sonderheft 22" (= October 1987):


10 fast:bank 15
20 a=dec("cdcc")
30 sysa,77,4
40 sysa, 3,8
50 sysa,0,36:sysa,64,7
60 sysa,50,6
70 poke2607,16:sysa,16,20
80 print "{clr}"
90 :
100 for i=0to1999step200
110 sysa,128,24
115 :
120 sysa,(2000+i)and255,19
130 sysa,(2000+i)/256,18
140 sysa,iand255,33:sysa,i/256,32
150 :
160 sysa,200,30
170 sysa,(6096+i)and255,19:sysa,(6096+i)/256,18
180 sysa,(4096+i)and255,33:sysa,(4096+i)/255,32
190 sysa,200,30
200 next

This is pretty straightforward. It sets register 4 to 77 (= 624 lines) and doesn't mess with register 5 at all, leaving it a 0. It sets the ram-refresh to 0 however as you suggested to as well. I've tried it on my machine and values of 3 in register 36 still work. It has a nice little copy routine accessible by "goto 100" that copies the top half to the bottom.

Hydrophilic

Wow, that is really strange that using an odd number messes up interlace on PAL.  I'd have to play with my C128 again to be sure, but as I recall, my NTSC did need an odd number in register 5.

In fact, since the same chip (8563) is used for both NTSC and PAL (unlike VIC which has different chips), I am quite confused...

Quote from: tokraAlso, why didn't they set register 0 to 127 leading to a very neat 15.625 kHz raster rate (exact PAL). Maybe there is a correlation between the higher raster rate of 15.748 kHz and the 640 lines...? Any idea?
Wow, I always assumed both standards used 15.75 kHz raster rate... thanks for the info about PAL.  I wouldn't think there would be a correlation between horizontal size and number of rasters, but I guess it is possible.  After all, this thread started because interlace didn't work for me when using the "correct" horizontal size, at least not until the change to the DRAM refresh rate.

It seems after 9 revisions, the VDC still has bugs...
I'm kupo for kupo nuts!