|
Post by sjgray on Jun 18, 2016 20:43:34 GMT
One of the things that would be cool with a simple eprom palette generator would be you could define different palettes and switch between them immediately This could let you have "pure" rgbi (no colour change) or "brown-fix" palette, or the C64's palette, or a grey-scale palette simply by selecting the upper address lines with the parallel port. Let's say you want to write pacman, but there is no "pink" colour.... just make a pacman palette! Or a you could do special effect... a totally black palette could let you blink the screen. Define several palettes with increasingly darker versions of the original colours and your screen could fade out. Pretty much all that is possible with one eprom, 8 resistors, some diodes, and maybe one ttl chip to generate csync from h+v-sync. It could all be external too, so it wouldn't involve any messing around inside the machine. It could probably be wired up very quickly.
I do agree though... we do need to recreate the VDC chip in FPGA, simply because the supply of replacement VDC chips is nearly non-existant. And of course adding features like VGA out would be really amazing.
Steve
|
|
|
Post by robertb on Jun 19, 2016 5:05:06 GMT
|
|
|
Post by mrbombermillzy on Jun 19, 2016 6:57:29 GMT
Yes, we were discussing in another thread the Scanntronik Genlock. This one would have to be a stripped down/simplified version to be cost effective and small enough though.
As for VDC emulation, there are several problems in the VICE x128 VDC emu and this seems like the most well developed one. Maybe see what Groepaz has to say as he seems to be dealing with that side of things. I think someone will eventually de-lid a VDC chip like they did on the SID to get to the bottom of it. However, as you imply, they are too precious and few and far between nowadays.
I'm pretty sure with a sped up dotclk and a reduction in h.frame size to increase frequency, you would lose a bit of that extra resolution, but we can hit 31khz at a fairly respectable resolution. Its then fairly trivial to convert the digital signal to rgb analogue. This would probably be a far easier job than FPGAing the VDC with a very high accuracy.
|
|
|
Post by Pyrofer on Jun 19, 2016 11:49:45 GMT
Yeah, I did consider the EPROM route. I was told the speed wouldn't be high enough, but meh. I am sure it would be. I think the only real problem is you only get 8 bits out, so RRGGGBBB or something unless you use two for a full 16bit palette. I think considering the total lack of software for the VDC getting "perfect" emulation on an FPGA isn't a show stopper. I had planned to just implement the basic bitmap and character map graphics and ignore most of the registers that change the output. As long you you allow for the ones that change the number of characters etc so the screen shows the correct image you can safely ignore all the dram refresh rate and output speed registers. As long as you implement the status register correctly I would imagine even Oblivion demo would work. This is the FPGA I bought www.ebay.co.uk/itm/262173530336 to try this. It would be good if we could all agree a standard platform going forward so that work isn't duplicated on incompatible systems.
|
|
|
Post by mrbombermillzy on Jun 19, 2016 12:34:04 GMT
Well, that's fine if it will work acceptably and we are going to use 'standard' 80x25 modes. Personally, I'm just wanting to see what I can do with a sped up and non memory restricted VDC. Perhaps some 'bolt on' compatible colour system too, hence Steve's project.
With a FPGA implementation, there will be another 'fork' of the C128 system for the future coders/system hackers to have to learn for program compatibility, (Hence my earlier stab at the Amiga and its many incompatible incarnations) as it will be close enough, but not the same as the real h/w. So there will have to be s/w versions for users with the 'real' h/w and users for the FPGA version.
Looking at my figures, so that I can give you a rough idea of what I should be able to do:
If I can hit between 20-24khz from the 8568 VDC reliably, which seems quite reasonable, I can get the VDC chip to interface to a VGA monitor at around 640 to 800 h.pixels. This should be with non corrupt characters on the screen and a little rgbi to rgba circuit.
Now, this 'upgrade' should just require a piggyback board, just like the 16 to 64kb VDC upgrade kits which are available for the C128 and earlier 128D models. It can also be switched on/off if required too. Now I would imagine most users would be pretty confident in doing the mod and it won't cost much either.
On top of this, the VDC will have the same nuances as it always did (perhaps now without corruption), and won't need any different techniques or workarounds. We could even burn a modified kernal ROM to set the tweaked registers for the upgrade kit. Now with the colour upgrade I believe that this path would be the cleanest way to go.
FWIW, if you are willing to lose the VGA frequency standard and still have an old school PC/Amiga multisync lying around, we should be able to hit 1280 or up to 1600 h.pixel modes.
|
|
|
Post by Pyrofer on Jun 19, 2016 12:46:15 GMT
Actually, if the goal is just to hit VGA freqs with normal resolutions I am all for that But as it would require changing the registers it would require a compatible mode in all software you wanted to run on it. I guess the "GOLD standard" here is 100% accurate FGPA with VGA output. The FPGA code can be updated as people find bugs and differences so once a few are out there to technically competent testers I think it could be nailed down quite quick. If you got it to run Oblivion I doubt anybody would find a further incompatibility as I am pretty sure nobody has ever gone that deep into tricking the VDC before or after. I would worry about over clocking my VDC too, even if a tiny bit. I never got the VGAMania demo to run either! I think it might be something to do with my sync pin connections but I never got it running.
|
|
|
Post by mrbombermillzy on Jun 19, 2016 13:08:26 GMT
If we could get RFO demo working correctly on a FPGA reimplementation of the VDC then I would be fairly happy with that. However my end goal is really to reliably (as in not being a substantial risk for any VDC owners) crank the clock speed up to get the maximum number of NON CORRUPTING characters on screen so that I can reduce the character h.size as much as possible to give a higher density colour cell ratio.. eg:
1600 h. Pixels / 4 pixel char size = 400 horizontal pixel resolution with completely independent colour pallette choice. NB: Initial tests have only allowed me to drop the h.char size to 7 pixels so there is still a possibility that I can't get it this low!
Equally important would be the 1280 to 1600 h.Res 'productivity' mode, which would have the same attributes as the standard VDC settings.
If you think you can get a reliable VDC core running then we could possibly have some o/c options on that too. Perhaps have it running at 32+mhz? :-) This would allow a higher resolution unlimited (as in any of the 16 colours) pallette density. And this is still without SJRay's colour modifications!
|
|
|
Post by sjgray on Jun 20, 2016 17:02:35 GMT
So, the last couple days I've been working on an RRGGBBII Palette Editor to support my ColourPET+G board. It's available here: github.com/sjgray/ColourPET-palette-editorGive it a try and let me know what you think. Right now it's fully functional and should be enough to create a Palette ROM. Once I get the ColourPET+G board working I might need to modify it a little, depending on the resistor DAC implementation. If anyone has ideas on how to fill 256 different palettes let me know! ;-) I might do a little mockup breadboard to test the concept on the C128 if I get some time. Steve
|
|
|
Post by robertb on Jun 20, 2016 18:46:02 GMT
...if you are willing to lose the VGA frequency standard and still have an old school PC/Amiga multisync lying around, we should be able to hit 1280 or up to 1600 h.pixel modes. Or use modern LED, multi-scan, VGA monitors, like the BenQ BL702A and the BenQ BL912. Truly, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htmJuly 30-31 Commodore Vegas Expo v12 - www.portcommodore.com/commvex
|
|
|
Post by robertb on Jun 20, 2016 19:14:44 GMT
...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??!). For Amiga games, that's easy - usually 68000 and OS 1.3 with 1 meg of total RAM, or 68020 and OS 3.0/3.1 with 1 meg of total RAM. For Amiga demos... whoa... we're talking a wide range of OS/RAM/680xx. Truly, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htmJuly 30-31 Commodore Vegas Expo v12 - www.portcommodore.com/commvex
|
|