|
Post by sjgray on Jun 18, 2016 2:14:27 GMT
Not being a VDC expert, but thinking about this a little, what would happen if you physically changed the VDC dot clock? Swap out the 16MHz crystal module for something like an 18 or 24MHz module. You'd need to adjust the registers to get a stable picture of course but you can squeeze more pixels into the same space. If 18 or 24 MHz is too high for ram refresh then you might have to replace the DRAM with some fast SRAM and a latch to convert the memory interfacing. Maybe we can pump real VGA out of the chip??? ;-)
Steve
|
|
|
Post by mrbombermillzy on Jun 18, 2016 8:32:26 GMT
This is exactly what I am attempting to build ATM. The only thing I found online about VDC speed was that someone had o/c'd a '63 VDC but it would only do 20mhz.
I've ordered 18/20/22/24 MHz crystals and am trying to get some 60ns or lower drams too. Im hoping that the more mature process/revision of the '68 over the '63 will allow for a higher overclock speed. I then have to build a piggyback board (a bit like the '63 to '68 VDC upgrade board) with the clock,xtal and ram chips on and perhaps a nice big heat sink for good measure. Its then a case of tweaking the registers to get a stable picture.
I'm not too sure that the o/c will yield any particularly practical resolutions; perhaps if it was 1992 and we could still get hold of CRT multi sync monitors that would accept 16-30khz signals, then it would have more impact in the community. (Either that or reducing the h.char count to squeeze it up to meet 31khz like in Tokra's VGA mania demo). Maybe a combination of both higher dot clock and squeezing the displayed characters down a bit is the best option. Its all theory for now though.
However, I do hold out hope that the faster dram speeds will cure the higher resolution character corruption problems which are the main stopping factor in resolution enhancements. I believe the VDC was designed with the (broken) option to produce higher resolutions, but lacked the physical ability to, as the C= engineers were just about able to get the chip working at its standard 80 column setting so wouldn't have had time to test for all other programmatical possibilities of the unit and I very much doubt that they were thinking of maximum theoretical resolutions when selecting ram speed.
At least, putting the chip onto a test bed circuit with variable clock speeds and not restricted to any memory holdups, I should be able to figure out a bit more about what the chip is capable of.
Oh, and if anyone is wondering why its taking me so long; I have been waiting 1 month for a donor 128DCR machine to arrive and am currently waiting for a few bits from China (DIL socket,crystals) and I'm also trying to source the fastest drams that I can! :-)
|
|
|
Post by Pyrofer on Jun 18, 2016 9:57:49 GMT
This is an awesome idea. I hadn't thought of simply overclocking the VDC. My current plan was simply to replace the whole VDC with an FPGA that emulates it but outputs the picture as VGA or even HDMI.
Please keep us updated on your progress with as much detail as possible! I am excited to see where this goes.
|
|
|
Post by mrbombermillzy on Jun 18, 2016 10:10:09 GMT
I will do.
The main problem with the emulation is that, as far as I know, either VDC chip is not particularly well emulated. (Well, not anywhere near perfect anyway).
I'm hoping that I can develop the dot clock pushing and corruption curing side of things whilst someone else (hint hint: sjray! Lol) can sort out some sort of colour ramdac or something along those lines.
Put together, and if it all goes well, this could really rock the C128 graphics scene! :-)
|
|
|
Post by sjgray on Jun 18, 2016 12:05:55 GMT
Ok, you got me! How did you know I was thinking of adding a ramdac to the C128?
I actually had two ideas, the first (simpler method) which I just added to my ColourPET+G circuit, was to add a fast eprom. The 4 RGBI bits from the VDC would go into A0-A3 and A4-A11 would come from say the user port. The 8 eprom output bits would be treated as RRGGBBII and go into a resistor DAC and come out as RGB analog. By playing with the upper A4-A11 lines we can change the palette any time, but only fixed palettes. If we designed the palettes carefully and selected them on the fly we could generate nice 256-color screens.
Option two was a real RAMDAC chip. With this we would not be limited to fixed palettes. We would have to map this into memory but we could easily generate 16 million colors with 16 different colors per scanline. I picked up an IMSG176P-40 dip ramdac to play with.
Steve
|
|
|
Post by mrbombermillzy on Jun 18, 2016 12:38:09 GMT
Lol! Its one of the solutions I have explored too, along with one of the circuits on your ColourPET page was using a Ramdac system to generate the colours so I kind of guessed you might be heading in that direction!
I did also consider a VICIIe/VDC genlock but...one thing at a time and all that.
However, I really believe whatever route is taken here, it should be 'downwardly compatible with the regular vdc. I'm sorry if I keep repeating the 'maximum common benefit for the community' mantra, but I believe its what made the C64 scene a solid and arguably less fragmented one than the Amiga one (Which kick start ROM/RAM size/680xx processor do I need for this demo/game??!).
Although saying that, there's not really much VDC specific software to keep compatible with, so maybe just go for it.
Both of those solutions seem worthy of exploration, although I would probably go for the first one, as it is simpler and perhaps easier for the average C128 owner to make/afford?
|
|
|
Post by sjgray on Jun 18, 2016 13:54:24 GMT
Genlock... that's funny. I was looking at the C128 programmers ref for the VDC pinout yesterday to put into a Kicad library I'm building. I read about the INIT pin, which resets the counters and thought of the exact same thing. If we strip out the sync from the VIC-II chip and feed vsync to the INIT pin we could synchronize the VIC and VDC. Then if we monitored the VDC's RGBI for 0,0,0,0 (black) we could use that to superimpose the VDC pixels on top of the VIC-II pixels (after converting VDC to composite). You could then have 80 columns with sprites!
BTW, did you notice that the schematics and even the prg ref guide get /RES and INIT confused?
Steve
|
|
|
Post by mrbombermillzy on Jun 18, 2016 17:05:43 GMT
That's a good way to do it. However, might this reset perhaps affect any VDC memory fetches or anything like that? My solution would have been to phase lock the (double speed) VDC clock with the VIC one. Again, maybe having to tweak the VDC registers slightly so that the VDC can run at exactly 2x VIC CLK. There is also a CHRCLK output which looked as if it could come in handy timing wise.
I did consider re attaching the vertical interrupt line too. This would be SO useful. But where?...
I would also suggest to superimpose the VIC OVER the VDC which would be much more practical.
And yes the PRG is good for a basic foundation, but ultimately, you have to find out the gritty details yourself. I've found a lot of useful third party technical information but its for the '63 so not ultimately 100% accurate for the later '68.
|
|
|
Post by sjgray on Jun 18, 2016 19:00:57 GMT
That's a good way to do it. However, might this reset perhaps affect any VDC memory fetches or anything like that? My solution would have been to phase lock the (double speed) VDC clock with the VIC one. Again, maybe having to tweak the VDC registers slightly so that the VDC can run at exactly 2x VIC CLK. There is also a CHRCLK output which looked as if it could come in handy timing wise. I did consider re attaching the vertical interrupt line too. This would be SO useful. But where?... I would also suggest to superimpose the VIC OVER the VDC which would be much more practical. And yes the PRG is good for a basic foundation, but ultimately, you have to find out the gritty details yourself. I've found a lot of useful third party technical information but its for the '63 so not ultimately 100% accurate for the later '68. I assume by the description that INIT simply resets the screen counters, effectively forcing the frame to restart. Who knows what else it's tied to. I'm sure its going to affect other things that depend on the position of the frame. I'm pretty sure the INIT pin was specifically designed to sync the chip to another source. A similar function is available on the Yamaha V-series chips (V9938, V9958) and of course the Amiga around that time. Otherwise, without INIT I don't think there's any guarantee that the VIC and VDC frames start at the same time, which you need if you're superimposing them. I'm also not sure how you can put the VIC video on top of the VDC... how do you determined when VIC video is a specific colour that you choose to be transparent? It's easy with VDC as you have the 4 rgbi lines. Anyway, I guess we'll only know by trying. I don't think I'll be getting to the C128 any time soon. Id like to finish ColourPET+G first. Although you never know. When I get stuck on something or bored I'll often switch to another project for a while then when I get back to the original project I can have a new perspective on things. Steve
|
|
|
Post by Pyrofer on Jun 18, 2016 19:40:36 GMT
You can fairly accurately chroma+luma key because you can look at the Y/C lines and compare them with the black voltage. There are circuits to convert RGB to Y/C easily too so once you have them in sync I think the keying part is the easy bit. I had considered this all myself ages back. As far as the RGBI to RRGGBB conversion is concerned I have that pretty much solved with the GAL I developed. I get almost perfect colours now I would say that doing serious mods to the machine will greatly reduce the chance than anybody else will replicate the thing so your work will not have a great audience. It's that reason that made me write the Boulderdash game for 16k VDC with no mods. To this end while making a 256 colour mod would be awesome I am not sure how many people would bother making it. I would be much more interested in work to replace the VDC with an FPGA so you could replace a dead chip. Also you could put native VGA out on the FPGA making the whole video out a lot easier. I actually bought a FPGA dev board but am way over my head with the programming at the moment. It turns out FPGA is hard
|
|