Last weekend I was testing my RGBI to S-Video converter to see what it could do, but it went wacky in interlace mode. So I tried plain monochorme and it was still wacked. I tried doing other stuff not using interlace (and using monochrome to avoid possible conversion issues), but still got some wacked out results.
I think my VDC is defective!
Can somebody tell me if this is the right code to set interlace on NTSC VDC?
W=DEC("CDCC"):BANK15
SYSW,64,4:SYSW,50,6:SYSW,56,7:SYSW,3,8
When I do this, the top half becomes a "squashed" vervision of the text and the bottom half becomes garbage, as expected for interlace mode without a 50-line editor active.
BUT, in the top half, the characters are staggered (rightward) like it is trying to output 84 characters per row.
If I change horizontal displayed to 77, I get as expected, staggered output (leftward). If change to 79 displayed, it is almost normal (staggered one char per line). But if I go up to 80, it is not normal, there is a large jump in staggering (rightward).
Okay, I thought, for some reason it doesn't like 80 characters/row interlace mode.
I changed horizontal total to 79 and got the slight (leftward) stagger of characters. Then to make it look pretty (not staggered), I changed the address/row increment (register 27) to one. Did this make a pretty picture? No, it went bonkers again!
So then I thought, fork interlace mode, let's try something else.
There is quite a lot of unused border on both left and right of my screen. I tried different row widths (horizontal displayed). I can get 90 characters on screen horizontally.
But for some values, VDC goes bonkers. Like with 83 characters, some characters "dissappear" for no reason. At another value, I think 85, some of the characters would repeat. At higher values, like 88 to 90, the VDC would both miss characters and repeat characters.
There seemed to be no pattern to what characters would vanish or be repeated (not a specific char from the font, or regular repeating of characters).
My VDC is just spitting out crud. I think it's defective! I can get a screen shot if anybody thinks that would help.
BTW, I haven't dissassembled my "new" C128 yet, so I don't know what Rev. the chip is. While I was posting this, I just thought that I could PEEK $D600 to find out.
Quote from: Hydrophilic on October 13, 2009, 01:41 PM
Last weekend I was testing my RGBI to S-Video converter to see what it could do, but it went wacky in interlace mode. So I tried plain monochorme and it was still wacked. I tried doing other stuff not using interlace (and using monochrome to avoid possible conversion issues), but still got some wacked out results.
I think my VDC is defective!
Hmmm. Before you blame the C128, is it possible that the RGBI-to-S-Video converter is at fault? The only way to know for sure is to get a RGBI cable connected to the C128 and to an 80-column monitor. Then you can see if the results are the same.
AmiWest Show on October 16-18,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
I bypassed the converter and used plain monochrome to eliminate the converter as the culprit. I remember interlace working through monochrome with my old 128, back in the day.
Since the output is "almost" correct when the horizontal displayed is 79 but goes completely nuts when set to the normal 80 value, I think my chip is defective.
If somebody with an NTSC setup could check the code I'm using, it would be appreciated.
W = DEC("CDCC"): BANK 15
SYS W,64,4: SYS W,50,6: SYS W,56,7: SYS W,3,8
If my code is right, then I'll see if I can find the 8563 from my old 128 and swap parts. But I'd like to be sure the code is right before opening my "new" 128.
I tryed your code in vice and had to modify it to this to keep from getting errors
w=(dec("cdcc")):bank15
sysw,64,4:sysw,50,6:sysw,56,7:sysw,3,8
good luck with display
You need parantheses around the DEC function... strange...
I didn't know VICE supported interlace... which version do you have?
80 is the correct / default value of horizontal displayed for non-interlace. I don't ever remember having to change it to 79 back in the day for use with interlace. I was trying different values, like 79, just to see what would happen. It works like it should, each row is offset by 1 character. With 80 the rows should all be aligned but it seems like VDC is putting an extra 4 chars on each row... I think my VDC is defective.
Last night I tried searching the web for some code on this topic and quickly found this thread. Google sure is quick to index Lance's site!
Eventually I found one example code but it was for bitmap mode. Seems he had to change the vertical fine adjust from default of 0 to 3 for interlace to work correctly on one of his two C128s. I was hoping my VDC just had this same type of defect so I tried, but had the opposite result: when I put any odd value in vertical fine adjust, the screen would flicker horribly but appear the same as before with any even value.
I was hoping BigDumbDinosaur or somebody with a known good (NTSC) setup could check the code on a real C128:
W = DEC("CDCC"): BANK 15
SYS W,64,4: SYS W,50,6: SYS W,56,7: SYS W,3,8
Quote from: Hydrophilic on October 15, 2009, 01:01 PMI was hoping BigDumbDinosaur or somebody with a known good (NTSC) setup could check the code on a real C128:
W = DEC("CDCC"): BANK 15
SYS W,64,4: SYS W,50,6: SYS W,56,7: SYS W,3,8
O.K., I just tried that out with my NTSC C128DCR connected via 80-column RGBI cable to a Magnavox RGB Monitor 80.
QuoteWhen I do this, the top half becomes a "squashed" vervision of the text and the bottom half becomes garbage, as expected for interlace mode without a 50-line editor active.
BUT, in the top half, the characters are staggered (rightward) like it is trying to output 84 characters per row.
If I change horizontal displayed to 77, I get as expected, staggered output (leftward). If change to 79 displayed, it is almost normal (staggered one char per line). But if I go up to 80, it is not normal, there is a large jump in staggering (rightward).
Okay, I thought, for some reason it doesn't like 80 characters/row interlace mode.
I changed horizontal total to 79 and got the slight (leftward) stagger of characters. Then to make it look pretty (not staggered), I changed the address/row increment (register 27) to one. Did this make a pretty picture? No, it went bonkers again!
So then I thought, fork interlace mode, let's try something else.
There is quite a lot of unused border on both left and right of my screen. I tried different row widths (horizontal displayed). I can get 90 characters on screen horizontally.
But for some values, VDC goes bonkers. Like with 83 characters, some characters "dissappear" for no reason. At another value, I think 85, some of the characters would repeat. At higher values, like 88 to 90, the VDC would both miss characters and repeat characters.
And that's what I seem to get, too (without looking at any of your screenshots).
AmiWest Show on October 16-18,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
Thanks for your report, RobertB! Maybe my VDC is normal? It sure doesn't act the way I remember my old C128 worked back in the day, but it could be bad memory... over 20 years now! :o
I guess I'll try some different values and see if I can get a good interlace picture. If all else fails, I can always dig out that old 8563...
Edit
I remember writing something about VDC interlace awhile back and found this thread (http://www.commodore128.org/index.php?topic=2364.0). According to my own post, the vertical sync width needs to change too! I tried again using my suggested value of $89 instead of $49 for register 3 (Vert/Horz Sync Width).
This produced a "better" interlace but it was still wrong. Next I noticed in my comments that vertical total is really vertical total-1 (register 4). Simply doubling from 32 (default) to 64 was wrong. So I thought it should be 33*2-1 = 65. This produced an even better interlace picture, but... it is still wrong... For example, at the top of the screen where it prints BASIC BYTES FREE, the number 3 is clear and legible; but farther down the screen where I typed my SYS commands, the 3's were so blury that they looked like 2's :(
So then I did some math: 66*8 = 528. That is too many rasters for NTSC (should be 525). So 66-1 = 65 (the value I just tried) is wrong. And the first value, 65-1 = 64 is also wrong because 65*8 = 520 is too few rasters (remember 525 NTSC rasters).
Finally, I tried using 65-1 = 64 for register 4 and I changed the Vertical Total Adjust (register 5) from the default of 0 to 5. This results in 65*8+5=525 rasters (correct for NTSC).
The result? A "perfectly" interlaced picture. I say "perfect" because although the image was properly interlaced now, my defective(?) VDC is still displaying garbage characters on the right of the screen and the text is staggered right, as if VDC was displaying 84 characters per line...
I'll wory about the staggered characters later. Immediately I wanted to see if my RGBI to S-Video converter would display interlace. I changed to S-Video on my TV and... a "perfectly" interlaced picture in full color ;D .
(I also tried other odd values like 1 and 3 instead of 5 for register 5, but they produced a terrible display.)
So thanks again to RobertB for testing. And thanks to Lance for keeping my posts from days gone by (and making them easy to find). Without you guys, I may have given up!
Of course the staggered character problem remains. And I still suscpect my VDC is defective. So if anyone would care to test my new code, I will be extremely grateful to know if the following produces a correct interlace display on a real NTSC C128 (note the bottom half of the screen will contain "garbage" due to attributes being displayed as characters):
W=DEC("CDCC"):BANK 15
SYS W,DEC("89"),3: SYS W,64,4: SYS W,5,5: SYS W,50,6: SYS W,56,7: SYS W,3,8
/Edit
Quote from: Hydrophilic on October 19, 2009, 02:08 PM
So if anyone would care to test my new code, I will be extremely grateful to know if the following produces a correct interlace display on a real NTSC C128 (note the bottom half of the screen will contain "garbage" due to attributes being displayed as characters):
W=DEC("CDCC"):BANK 15
SYS W,DEC("89"),3: SYS W,64,4: SYS W,5,5: SYS W,50,6: SYS W,56,7: SYS W,3,8
O.K., I've tried out the new code. Strangely, when I tried it the first time, it displayed the screen but after a few seconds, the computer reset itself. Doing it a second time, I see the screen is back with no resetting from the C128DCR.
QuoteThe result? A "perfectly" interlaced picture. I say "perfect" because although the image was properly interlaced now, my defective(?) VDC is still displaying garbage characters on the right of the screen and the text is staggered right, as if VDC was displaying 84 characters per line...
I'll wory about the staggered characters later.
The screen is interlaced; however, the Commodore credits at the top center are not quite centered anymore, the READY prompt is way to the right with the lines of code underneath the READY prompt (making them way to the right). The READY prompt with your lines of code are then repeated again staggered slightly more to the left. Finally, the READY prompt is repeated again in the center and then the bottom half of the screen is filled with garbage. Far to the right is a column of dashes and a few blinking red garbage characters are to right center, one at the center, and more at the bottom 5 lines.
Back from the AmiWest Show,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Thanks again RobertB for the feedback!
I also get the garbage characters on the right... really strange! I don't know what the VDC is doing there, there are no changes to any horizontal registers! Those garbage characters apparently cause all the other text to shift rightward (or leftward as you say... I need to post a screen shot).
What still puzzles me, is with chars displayed horizontal (register 1) set to other than 80, like 79 or 81, the garbage disappears and the screen looks like you would expect which is bad since the Editor relies on 80 physical chars/line.
I looked through my collection of chips from my old C128 and thankfully the 8563 is there. Rev9 to boot!
Since you're also getting garbage characters, I need to investigate the software more before tearing open my "new" C128. I really have no more theory to work with. So I'll take a peek into ZED which I've heard supports 50-line editing.
Quote from: Hydrophilic on October 21, 2009, 02:32 PMSo I'll take a peek into ZED which I've heard supports 50-line editing.
Yes, ZED 0.77 definitely supports 50-line editing (well, actually 51 lines). It is my text editor of choice when I am working in the native C128 80-column mode, and it works with a C128's 16k video or a C128DCR's 64k video. It is readable with 51 lines on my 20-inch RGBI monitor.
There are no garbage symbols whatsoever when in that
interlaced mode,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
I just checked out the code for ZED. For no obvious reason, interlace mode changes the horizontal total - 1 (register 0) from default of 126 to 128.
With register 0 default value of 126 = 127 chars = 127*8 pixels = 1016 pixels. And with 16.000MHz dot clock, this results in 1016/16MHz = 63.5us raster time or 15.748 kHz raster rate. This is perfect agreement with NTSC standard (within limits of 8-pixel char).
Obviously, for both my VDC and RobertB's, this does not work for interlace mode.
Using a register 0 value of 127 = 128 chars -> 15.625kHz raster rate, I get correct interlace, and more importantly, the lines are not "staggered" left or right. All text is properly aligned.
However, the 4 right-most characters have a defect. 2 of those have the "red" color attribute and the other two have correct "cyan" attribute but the character may be deformed. Some characters, like space, are not affected, but many are.
Using ZED's register 0 value of 128 = 129 chars -> 15.504kHz raster rate, I get both a correct interlace and no corruption of attributes on the right of the screen. This works in both monochrome, and through my RGBI -> S-Video adapter ;D
Note: register 0 is horizontal total - 1, and not horizontal displayed (register 1). Register 1 is left at default of 80 chars/row. The extra "characters" of horizontal total (register 0) are used for the left and right borders and the horizontal blank/sync signals.
However, 15.504 kHz raster rate is off a bit from the NTSC standard, and more importantly there is no logical reason for this. Consulting the C128 PRG, there is also no documented reason for this neccessity. Maybe one day I'll test my Rev9 VDC and see if it behaves better.
ANYWAY, the correct code for NTSC interlace on my current VDC is:
W=DEC("CDCC"):BANK15
SYSW,128,0: SYSW,DEC("89"),3: SYSW,64,4: SYSW,5,5: SYS W,50,6: SYS W,56,7: SYS W,3,8
If any other real C128 NTSC users would care to test the code, I'd love to hear the results!
Note: the bottom half of the screen is expected to contain garbage because this tiny code does not setup a 50-line editor so the bottom 25 lines display the attributes of the top 25 lines as if they were characters.
BTW, the only change I made from previous code is the change of register 0 from default of 126 to 128. ZED uses different settings. In particular, it uses a smaller vertical total and vertical sync position but uses a larger character height (9 instead of 8 pixels). I'm guessing this is to provide an extra raster between character rows to make them easier to read. Also, ZED does not change the vertical fine adjust like I do. With an odd character height (9 instead of 8 pixels), ZED's total number of rasters turns out to be odd, which appearantly is needed for VDC interlace. Because my code doesn't change char height, the total number rasters would be even, if I didn't change the vertical fine adjust (register 5).
Other notes:
I can display 53 lines no problem. But if I go for 54 lines, the top of the first line is cut off. This is not because the raster goes above the top of my screen. I can set the background color to something other than black and color appears in the top cut off region.
In interlace mode (50 or 53 lines), I can not display more than 80 chars horizontal (register 1). An attempt do so will result in extreme corruption of the screen. In non-interlace mode, 83 characters was possible with no corruption or with moderate corruption when set to 90 characters per row.
The VDC is a strange POS.
Edit
Tried to clarify difference between horizontal total and horizontal displayed
/Edit
Quote from: Hydrophilic on October 22, 2009, 04:01 PM
ANYWAY, the correct code for NTSC interlace on my current VDC is:
W=DEC("CDCC"):BANK15
SYSW,128,0: SYSW,DEC("89"),3: SYSW,64,4: SYSW,5,5: SYS W,50,6: SYS W,56,7: SYS W,3,8
Ah, now the opening C128 credits at the top are centered properly; however, it is hard to read the characters... it almost seems that each line of characters blends with the line above it or below it.
The column of garbage on the righthand side of screen is gone, as are any red garbage symbols in the upper half of the screen. The lower half of the screen still has blinking red and non-blinking white garbage.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Thanks again RobertB. That's an excellent description of what I see. So now I know the magic numbers for the VDC interlace mode, and that my VDC is not completely defective. Of course I'm most happy this all works through my RGBI to S-Video adapter (http://sites.google.com/site/h2obsession/CBM/C128/rgbi-s-video).
Quote from: RobertB...it almost seems that each line of characters blends with the line above it or below it.
Yes the lines are very close together. I suspect this is why ZED changes the char height from 8 to 9 pixels (err, rasters). This provides an extra raster of space between character rows. Since my TV is quite large, it is easy to see they are seperate, but from a distance, (or I imagine on a Commodore monitor) they "almost seem to blend"
Quote from: RobertBThe lower half of the screen still has blinking red and non-blinking white garbage.
Just as expected. The VDC is displaying the attribute bytes in RAM as if they were characters (so you get "garbage") and those characters get their attributes from un-initialized RAM ("blinking red and non-blinking white"). The simple test code doesn't change the attribute pointer in either the VDC or in C128 Editor.
It is just a few more POKEs to add to correctly set the attributes. For a "perfect" display you'd also want to clear the RAM in the bottom half too. Even with such longer code, the lower half of the screen would be forever unreachable with the C128 Editor because it is hard-coded for 25 physical lines. Which is why you need a special editor like ZED.
------
Last week I had a realization after all this discussion and testing. Since the results are reproducible, the magic code must be based on the internal operation of the VDC (not documented in the C128 PRG or anywhere else to my knowledge). Because interlace works with fewer than 80 characters, or with 80 characters IF you expand the horizontal total, the problem must be the VDC does not have enough cycles to fetch data from RAM with the settings I originaly tried.
I find that kind of odd since the VIC has plenty of time. Of course VIC is only 40 columns instead of 80, but the VDC runs at twice the speed. Also the VIC has to allocate time for 8 sprite data / pointer fetches per raster which as we know is not possible with VDC.
The second part of my realization is that maybe my original code (which is more compatible with NTSC specs) would work if the DRAM refresh rate were reduced. I've read that the default value is 5 and that a value as low as 0 causes no problems. When I get the time, I'll test this theory.
EditTried to describe the bottom-of-screen result better
/Edit
Quote from: Hydrophilic on October 28, 2009, 03:15 PM
Since my TV is quite large, it is easy to see they are seperate, but from a distance, (or I imagine on a Commodore monitor) they "almost seem to blend"
Ah, I did use the Magnavox 13-inch Color-80 monitor for my tests and did not use the bigger Sears 20-inch RGB/monitor/t.v.. Perhaps if I used the bigger one, I would have seen a difference.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
I was right! ;D The VDC appearantly doesn't have enough time (for whatever reason) to access VRAM in interlace mode with the default Horizontal Total (register 0) of 126 (on NTSC remember).
ZED overcomes the problem by fudging the NTSC standard and changing Horizontal Total from 126 to 128 (in addition to vertical changes which you would expect when doubling the vertical resolution).
My solution is to leave the NTSC specs intact (Horizontal Total does not change) but instead to change the DRAM Refresh Rate (register 36). The default value of this register is 5. It has been reported that values as low 0 work. Here are some screen shots, in reverse video mode (it shows corruption better).
NOTE: in each screen shot, the bottom contains garbage because I was too lazy to write code to clear the 25 new lines added by interlace mode..
Default DRAM Refresh of 5 (very bad, made me think my VDC was defective):
(http://sites.google.com/site/h2obsession/CBM/C128/images/DRAM5Rev_sd.jpg)
Using DRAM Refresh of 4 (only a little problem on the right):
(http://sites.google.com/site/h2obsession/CBM/C128/images/DRAM4Rev_sd.jpg)
Using DRAM Refresh of 3 (perfect, but still reverse video):
(http://sites.google.com/site/h2obsession/CBM/C128/images/DRAM3Rev_sd.jpg)
Using DRAM Refresh of 3 (normal video):
(http://sites.google.com/site/h2obsession/CBM/C128/images/DRAM3_sd.jpg)
What I want to know is why, why, why does the horizontal rate have anything to do with the vertical rate. I suspect even Bill Herd doesn't know the answer to this one...
Finally:
You can activate NTSC VDC Interlace Mode with the commands:
W=DEC("CDCC"):BANK15
SYSW,64,4: SYSW,5,5: SYS W,50,6: SYS W,56,7: SYS W,3,8: SYS W,3,36
(somebody should check to be sure)
And you can read a full description/summary here (http://sites.google.com/site/h2obsession/CBM/C128/VDCinterlace).
Edit: I made the images slightly smaller to fit the page better. The full size images are available at the web page listed above. /Edit
Nice work, HP. It's too bad no one ever wrote a book on the VDC. I probably have more books on the C128 than anyone, and even the couple with the best VDC coverage don't reveal much.
Thanks for boldly going where no one has gone before! :o
Quote from: Hydrophilic on November 12, 2009, 08:17 PM
You can activate NTSC VDC Interlace Mode with the commands:
W=DEC("CDCC"):BANK15
SYSW,64,4: SYSW,5,5: SYS W,50,6: SYS W,56,7: SYS W,3,8: SYS W,3,36
(somebody should check to be sure)
Yes, on my NTSC C128DCR interlace mode is active, opening titles perfectly centered (with garbage in the bottom half of the screen).
QuoteAnd you can read a full description/summary here (http://sites.google.com/site/h2obsession/CBM/C128/VDCinterlace).
Thank you for that bit of credit on your page; that was most unexpected. :)
If no one from PAL land helps you out with your VDC questions, I have a friend who lives near Heathrow, England, and when I make it out to his place in the summer of 2010 or 2011, I can check with his flat C128s there.
That would be a long wait,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Quote from: airship on November 13, 2009, 03:13 AMThanks for boldly going where no one has gone before! :o
Cue the Star Trek music! ;)
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
PAL flat & PAL D here.
Hydrophilic wrote on his webpage -
QuoteOf course, PAL Real Interlace mode on the VDC needs to be tackled next. Since I don't have any PAL equipment, I can only hope to get some feedback from users in other countries...
There you go, Hydrophilic. Blacklord offers his PAL C128 services. If you have any code for him to try out, post it here.
I would try, but my PAL plastic C128D doesn't display well with my NTSC 80-column monitors. :)
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
NTSC flat C128 with 64K memory expansion board here. Works fine, garbage in the bottom half of the screen and all. Title centered, proper side borders.
Only problem is I can't check til I get back home in three weeks.
Thanks for the feedback airship! And again RobertB.
Quote from: BlacklordOnly problem is I can't check til I get back home in three weeks.
No worries. I think I'm out of my VDC programming for the moment. I'm having fun with my uIEC right now in addition to re-installing/fixing operating systems on my new IBM-Compatible PC. Plus I still need to finish the case for my RGBI 2 SVideo. And build a case for the uIEC... good thing the holiday season is here so I'll have a little more free time.
So don't hold your breath, but don't worry either because... I'll be back. In particular, there's that unanswered post somewhere calling for a program to test all VDC modes, and it's been annoying me for a while now...
Quote from: Hydrophilic on November 17, 2009, 12:06 PM
Plus I still need to finish the case for my RGBI 2 SVideo. And build a case for the uIEC...
Don't forget to post photos and details on how you built the cases. :) My RGB-to-SVideo, my uIEC/SD, and my SD2IEC all need cases.
Getting a case around my IDE64 v4.1
would be a problem, though,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
This thread brought the following to mind :
http://noname.c64.org/csdb/release/?id=44110
http://www.kludgesoft.com/downloads/vdcdemo-d71.zip
I'm told that this demo uses an evil trick to get more mem bandwidth. It decreases horizontal frequency a bit. Not all monitors enjoy this, I would assume. I've not been able to test on real hardware yet.
XmX
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 (http://sites.google.com/site/h2obsession/CBM/C128/rgbi-s-video)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 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.
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'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.
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...