How about using an actual switch chip to switch between RRGGBBII and RRGGBBHV? The two intensity networks are high resistance so a high resistance switch should be acceptable. So, how about using a 4053B to switch modes? (or the bloody fast 74lv version) Avaliable in DIP, 175 ohm on resistance and fairly quick. (easy to find better switches if tiny surface mount packages are fine. like TL52055 or 74LV4066D )
Unfortunately, an analog switch won't work. One pair of signals, either the colors or the syncs -- but not both -- has to be inverted between the I pins and their selected outputs. The reason is that the idle state for the colors is low and the idle state for the syncs is high. The switch has to be made asynchronously during the idle state, and neither the sync nor the color outputs can change when that happens. Moreover, the syncs have to be driven high with a fairly low impedance when they're not being asserted, which would not happen with an analog switch.
Phil,
I noted in the text that 74LVC00 & 74LVC08 would be used. These have delays are typically 4.7ns max. So maybe this is too great at 40ns per pixel.
Your observation is correct.... The 74LVC00 should be an 74LVC32 OR gate and using De Morgans theorum this is an AND gate with inverters on both the inputs and outputs = NAND with input inversion.
So the logic should be...
When /SYNC is high, the AND gates for the intensity I0 & I1 are enabled and I0 & I1 are passed through at the same level. The OR gates for the HS & VS are acting as NAND gates with inverters on the inputs so since /SYNC is high, the NAND gate is effectively off forcing the output HIGH. (The I0 & I1 inputs are irrelevant)
When /SYNC is low, the AND gates for the intensity I0 & I1 are disabled and I0 & I1 are forced low, irrespective of their I0 & I1 inputs. The OR gates acting as NAND with inverters on the inputs for the HS& VS are enabled by the low on /SYNC (because of the inverters on the input to the NAND equivalent) and the inputs I0 & I1 are passed with inversion (because of inverters on the input to the NAND equivalent). Therefore, software will require the HS & VS bits to be reversed to normal - ie they will be 00 in code when displaying data and become 1 when HS and/or VS is required and the gate will invert this - ie the VGA will be /HS & /VS = active low.
Didn't realize the idle states were different. That's going to make any single chip solution difficult.
Moreover, the syncs have to be driven high with a fairly low impedance when they're not being asserted, which would not happen with an analog switch.
I'd say that depends on the analog switch and how stiff a pull up resistor you want to use. I.e. the TL52055 has about a 1 ohm on-resistance so a prop pin could drive a 300ohm pullup though it. (through a 74LV4053 the prop could likely manage a 1K pullup) With the different idle states, the circuit will need a pair of inverters somewhere. Might as well use them to buffer the sync signals so the DC loading on the sync lines isn't an issue. Alternatively, Assuming the 74LV4053 was used the third SPDT switch could be wired as an inverter. (still one short...)
I'm afraid that won't work either. The reason is that the signals pass through both logic sections without inversion, and one of them -- but not the other -- has to be inverted.
/SYNC has to change state during the idle phase of P16 and P17, and neither the colors nor the sync outputs are allowed to change state when /SYNC changes state. That's because /SYNC is not synchronized to the video PLL. The idle phase of the syncs is logic high. The idle phase of the colors is logic low. So one -- and only one -- of them has to be inverted when they pass through the gates from P16..P17. In your schematic neither is inverted. In my schematic the syncs are inverted but not the colors.
Phil, are you seeing a glitch problem?? (problem discovered)
Thinking this through, we are going to require all video bits (P16-23) to be made "0" at the end of the video during the porch period. During this time we can enable the Pxx /SYNC pin to be a "0" (active low). This will block the video out on the I0 & I1 pins, holding those at "0", and enable the HS & VS gates. AHA!!! The HS & VS will glitch active ( become active) and since we cannot control this synchronously we will have a glitch.
Back to the drawing board because we need I0 & I1 to be "0" as a default and only be a "1" for the HS & VS active pulses in the video register and inverted for the /HS and /VS (0 active) VGA signals.
Thanks heaps. WOndering if all this is worth it??? What is your opinion as I really value your input?
Kuroneko: Seems we cannot synchronise the signals properly to avoid shimmering, so we have to gate the signals.
Don't see the problem here. The [thread=139112]128xH/P drivers[/thread] do something similar in that they have a left and right driver pair. In the middle of the screen they overlap by 2 characters. The same approach can be taken for a pin group change. As an added benefit you are not tied to a particular idle state.
The HS & VS is not so critical for the delay so there are a few options here. So a 74LVC1G04 (to invert /SYNC) and a 74LVC2G00 would do the job.
When doing this sort of glue work, look at the 1G57/1G58, 1G97/1G98 or 1G99 which are configurable Logic gates.
So they can do a single IP bubble, as required.
That usually means only one part to stock, once you have chosen a favourite.
jmg: I already stock and use the 1G97. However, in this circuit it gains me nothing - I can replace the 1G04 and 2G00 with 2x 1G97 but the 2G08 would require 2x 1G97's and they are IIRC 6.7ns which is more than I think would work.
AFAIK, writes to vcfg are not double-buffered to occur at waitvid intervals but happen immediately. IOW they are sync'd to the system clock, not to the video PLL. So, even if you used that method, you would have to make the switch during a defined idle state where the pixels controlling the I and sync pins are all low. That would entail inverters on the sync pins. Now, you're right that a pair of inverters is less hardware than what we're discussing and would work under one condition: that changing vcfg on the fly does not reset the internal video counters and keeps the timing intact. The working assumption here, so far, is that making that change will mess up the timing. Do you have knowledge to the contrary?
Now that I think about it more, maybe it could be done without the inverters, assuming the timing doesn't get messed up. In this method, dira for all 10 pins would be set high, with outa for the sync pins also set high. The procedure for doing the syncs would be:
1. Do one waitvid with all the color pins low.
2. Change vcfg to point to the sync pins.
3. Do one waitvid with the sync pins high.
4. Clear dira for the sync pins. They're now under the control of the video machinery.
5. Perform the syncs using waitvid.
6. Do one waitvid with the sync pins high.
7. Set the outa bits for the sync pins back to ones.
8. Change vcfg to point to the color pins.
So the big remaining question is whether changes to vcfg alter the timing or whether the internal counters continue to run as if nothing changed.
Coming from the NTSC world - in VGA is there a border interval between the active video and the sync? I'm thinking that you do a WAITVID which includes border & sync coding then immediately do an OUTA to the pin which controls the HV mux. This does mean the "mux" might need to be a more complex part (PLA?) to ensure:
1. Prop output for black is the same as HV sync idle
2. When HV is selected the video is black
3. When HV is not selected HV is sync idle.
It should be possible to configure it so when the mux pin is not used the HV pins are passed through. However, handling different pos/neg sync combinations is probably best handled with a different "mux" rather than more configuration pins. (Or maybe the mux could have the pins but they could be wired to the Prop or tied high or low.)
Nope: 'afraid not. It suffers the same issues that Cluso's circuit did. The net inversion though the gates for I0 and I1 has to be different from that of H and V. If you replace the ANDs with NANDs and delete the post-inversion for H and V, you'd have it.
1. Do one waitvid with all the color pins low.
2. Change vcfg to point to the sync pins.
3. Do one waitvid with the sync pins set to idle state.
4. Clear outa for the sync pins. They're now under the control of the video machinery.
5. Perform the syncs using waitvid.
6. Do one waitvid with the sync pins set to idle state followed by low to prepare for switch over.
7. Set the outa bits for the sync pins back to idle state.
8. Change vcfg to point to the color pins (once driven low).
Changing pins and pin group only controls the mux. The frame counter remains untouched (not even a reset will affect it).
Thanks, kuroneko. But when you quote someone, please don't change the text within the quote; do it separately in your own post. Now I have to go back to the previous page to see what I wrote to compare it with your mods.
The delays for I0 & I1 are the important ones to be minimised. We can get to ~2.1ns with the NXP version (not TI or others) 74LVC2Gxx.
Andy's circuit can be minimised to make single gates into the I0 & I1 lines.
I think it best we work out the circuit that will work reliably first. We can minimise the gates later.
Certainly it would be nice to keep the software that creates the pixel color info the same. But this is not a requirement (at least for me). However, I do want to ensure that it will work first time, and that it is worth the extra logic.
So, will the extra two I bits give a (much) better display ???
kuroneko: I think you may be onto something here. The video logic will be using the same PLL clock.
So by using a couple of extra waitvid's I think we could be able to switch banks of pins without loss of sync.
One thing to remember (it may help) is that the output pins are OR'ed so I presume OUT[xx]=1 and DIRA[xx]=1 would effectively take/release control of the pins from being forced high.
Are we sure all VGA's will work using "0" HS & VS active ???
Phils cct in #30 can have the I0 & I1 gates replaced with an NXP 74LVC2G125 which is a pair of tristate buffers with low enables. The /HS & /VS can use an NXP 74LVC2G00 which is a pair of NAND gates. Note software requires the HS and VS to be inverted ie active high. Only 2 sot style 8 pin chips and 6 resistors (a pair of resnets), and 1 prop pin is required.
Provided the HS and VS are inverted in software, by keeping the SYNC pin high, the circuit will remain compatible with the old vga circuit.
So the burning question remains.... Is the extra circuitry/software worth the trouble and how much better will the display be ?
Is the extra circuitry/software worth the trouble ...
Or, more to the point, is the extra circuitry even necessary? Pursuant to Kuroneko's contribution, I would say no, assuming you can spare two extra pins for sync instead of one. Plus, by doing it all in software, you're not stuck with having to choose the sync polarity ahead of time. Nonetheless, it was a fun exercise to come up with an external switching scheme that works.
If it were me, I would use an external circuit that can suppress parts of the primary signal, otherwise do it all in software. VGA overlay, as in using more than one video generator, is of limited use because the signals can only add together. Overlaying bright white onto an image works. Overlaying black on a white image can't work. Build a circuit to fix that, and some very useful options are on the table.
Consider text. One could have monochrome text defined as a mask. That text could be stamped right on top of a lower resolution color image, yet remain at high resolution. Or imagine a low resolution high color option, say 80x100 pixels, full screen. Apply the color at low resolution, then fill in detail with monochrome graphics. Couple that with tiles, and it will be complex, but very lean in terms of overall RAM footprint.
Comments
Lawson
-Phil
I noted in the text that 74LVC00 & 74LVC08 would be used. These have delays are typically 4.7ns max. So maybe this is too great at 40ns per pixel.
Your observation is correct.... The 74LVC00 should be an 74LVC32 OR gate and using De Morgans theorum this is an AND gate with inverters on both the inputs and outputs = NAND with input inversion.
So the logic should be...
When /SYNC is high, the AND gates for the intensity I0 & I1 are enabled and I0 & I1 are passed through at the same level. The OR gates for the HS & VS are acting as NAND gates with inverters on the inputs so since /SYNC is high, the NAND gate is effectively off forcing the output HIGH. (The I0 & I1 inputs are irrelevant)
When /SYNC is low, the AND gates for the intensity I0 & I1 are disabled and I0 & I1 are forced low, irrespective of their I0 & I1 inputs. The OR gates acting as NAND with inverters on the inputs for the HS& VS are enabled by the low on /SYNC (because of the inverters on the input to the NAND equivalent) and the inputs I0 & I1 are passed with inversion (because of inverters on the input to the NAND equivalent). Therefore, software will require the HS & VS bits to be reversed to normal - ie they will be 00 in code when displaying data and become 1 when HS and/or VS is required and the gate will invert this - ie the VGA will be /HS & /VS = active low.
I'd say that depends on the analog switch and how stiff a pull up resistor you want to use. I.e. the TL52055 has about a 1 ohm on-resistance so a prop pin could drive a 300ohm pullup though it. (through a 74LV4053 the prop could likely manage a 1K pullup) With the different idle states, the circuit will need a pair of inverters somewhere. Might as well use them to buffer the sync signals so the DC loading on the sync lines isn't an issue. Alternatively, Assuming the 74LV4053 was used the third SPDT switch could be wired as an inverter. (still one short...)
Lawson
I'm afraid that won't work either. The reason is that the signals pass through both logic sections without inversion, and one of them -- but not the other -- has to be inverted.
-Phil
/SYNC has to change state during the idle phase of P16 and P17, and neither the colors nor the sync outputs are allowed to change state when /SYNC changes state. That's because /SYNC is not synchronized to the video PLL. The idle phase of the syncs is logic high. The idle phase of the colors is logic low. So one -- and only one -- of them has to be inverted when they pass through the gates from P16..P17. In your schematic neither is inverted. In my schematic the syncs are inverted but not the colors.
-Phil
Thinking this through, we are going to require all video bits (P16-23) to be made "0" at the end of the video during the porch period. During this time we can enable the Pxx /SYNC pin to be a "0" (active low). This will block the video out on the I0 & I1 pins, holding those at "0", and enable the HS & VS gates. AHA!!! The HS & VS will glitch active ( become active) and since we cannot control this synchronously we will have a glitch.
Back to the drawing board because we need I0 & I1 to be "0" as a default and only be a "1" for the HS & VS active pulses in the video register and inverted for the /HS and /VS (0 active) VGA signals.
Thanks heaps. WOndering if all this is worth it??? What is your opinion as I really value your input?
The HS & VS is not so critical for the delay so there are a few options here. So a 74LVC1G04 (to invert /SYNC) and a 74LVC2G00 would do the job.
Kuroneko: Seems we cannot synchronise the signals properly to avoid shimmering, so we have to gate the signals.
When doing this sort of glue work, look at the 1G57/1G58, 1G97/1G98 or 1G99 which are configurable Logic gates.
So they can do a single IP bubble, as required.
That usually means only one part to stock, once you have chosen a favourite.
AFAIK, writes to vcfg are not double-buffered to occur at waitvid intervals but happen immediately. IOW they are sync'd to the system clock, not to the video PLL. So, even if you used that method, you would have to make the switch during a defined idle state where the pixels controlling the I and sync pins are all low. That would entail inverters on the sync pins. Now, you're right that a pair of inverters is less hardware than what we're discussing and would work under one condition: that changing vcfg on the fly does not reset the internal video counters and keeps the timing intact. The working assumption here, so far, is that making that change will mess up the timing. Do you have knowledge to the contrary?
Now that I think about it more, maybe it could be done without the inverters, assuming the timing doesn't get messed up. In this method, dira for all 10 pins would be set high, with outa for the sync pins also set high. The procedure for doing the syncs would be:
2. Change vcfg to point to the sync pins.
3. Do one waitvid with the sync pins high.
4. Clear dira for the sync pins. They're now under the control of the video machinery.
5. Perform the syncs using waitvid.
6. Do one waitvid with the sync pins high.
7. Set the outa bits for the sync pins back to ones.
8. Change vcfg to point to the color pins.
So the big remaining question is whether changes to vcfg alter the timing or whether the internal counters continue to run as if nothing changed.
-Phil
1. Prop output for black is the same as HV sync idle
2. When HV is selected the video is black
3. When HV is not selected HV is sync idle.
It should be possible to configure it so when the mux pin is not used the HV pins are passed through. However, handling different pos/neg sync combinations is probably best handled with a different "mux" rather than more configuration pins. (Or maybe the mux could have the pins but they could be wired to the Prop or tied high or low.)
I believe that the circuit I presented above in post #30 would meet all of your criteria, with the addition of a pull-up on SyncEn.
-Phil
Given your stated objective of software compatibility, didn't you mean to put the inverters on I1 and I0?
-Phil
Only if compatibelity to existing VGA drivers is no criteria.
Here is a circuit which may work:
Edit: Sorry Phil I have deleted the prevoius post, because there was an error in the schematic... your response was a bit too fast
-Phil
This will only inverse I0 and I1 and is otherwise the same. But how about that:
-Phil
-Phil
Andy's circuit can be minimised to make single gates into the I0 & I1 lines.
I think it best we work out the circuit that will work reliably first. We can minimise the gates later.
Certainly it would be nice to keep the software that creates the pixel color info the same. But this is not a requirement (at least for me). However, I do want to ensure that it will work first time, and that it is worth the extra logic.
So, will the extra two I bits give a (much) better display ???
So by using a couple of extra waitvid's I think we could be able to switch banks of pins without loss of sync.
One thing to remember (it may help) is that the output pins are OR'ed so I presume OUT[xx]=1 and DIRA[xx]=1 would effectively take/release control of the pins from being forced high.
Are we sure all VGA's will work using "0" HS & VS active ???
Provided the HS and VS are inverted in software, by keeping the SYNC pin high, the circuit will remain compatible with the old vga circuit.
So the burning question remains.... Is the extra circuitry/software worth the trouble and how much better will the display be ?
-Phil
Consider text. One could have monochrome text defined as a mask. That text could be stamped right on top of a lower resolution color image, yet remain at high resolution. Or imagine a low resolution high color option, say 80x100 pixels, full screen. Apply the color at low resolution, then fill in detail with monochrome graphics. Couple that with tiles, and it will be complex, but very lean in terms of overall RAM footprint.