Uzebox PAL support

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox PAL support

Post by uze6666 »

Fahr wrote:When I first thought of this, I figured that halving the Uzebox speed would severely cripple its power, but then this occured to me; in order for PB3 to produce a burst every other cycle, it needs an instruction, right? Which means HALF of all instructions executed are used for pulsing and the remainder is used for processing. If one eliminates the need to pulse by using CKOUT, should that not theoretically keep the Uzebox running at the same processing speed? Instead of having half the cycles available at 28mhz, you'd have all cycles available at 14mhz.
Hehe, nice try! ;) However the PB3/AD725 clocking incurs no overhead to the execution speed as this pin automatically toggles when a hardware timer attains a target value (in this case "1", or each other clock). So no need for interrupts here, and it's the beauty of AVR devices! :) That said, *some* cycles could have been saved if the CSYNC pin used the 16 bit timer OCx pin instead of interrupts. But I didn't saw that when doing the original design and after the AVCore & Fuzebox where out, it was too late...

Now, what about trying the SCART interface made by F0lken?

-Uze
Fahr
Posts: 15
Joined: Sun Feb 07, 2010 6:44 pm

Re: Uzebox PAL support

Post by Fahr »

uze6666 wrote:Hehe, nice try! ;) However the PB3/AD725 clocking incurs no overhead to the execution speed as this pin automatically toggles when a hardware timer attains a target value (in this case "1", or each other clock).
Yeah, I thought something like that might be the case. That's too bad :( it was a nice idea...
uze6666 wrote:Now, what about trying the SCART interface made by F0lken?
I've already been messing with SCART as a hardware interface. As you may know, SCART is a multi-purpose interface that carries practically all signals. Theoretically it can carry RGB, composite and S-video, but only one at a time and it depends on the TV which ones it accepts. I've wired and used it with both composite and S-video signals without any problems, but it seems my TV refuses to accept RGB with any timings other than PAL. This may well be because the CSYNC signal is optional in SCART RGB. Many consoles that support SCART RGB output (PAL SNES and PAL Gamecube for sure) merely send +12V across it at all times. Cheaper (older) TVs may not read the SYNC at all in RGB mode and simply assume PAL timing.
I'll be testing it on a newer TV shortly and if I get that working, I'll report back my findings in another post. I was thinking of drawing up a schematic that wires a SCART connector for all 3 signals with a switch to decide which one you want. Stay tuned for more on that :P

However, if you're suggesting I try to get an RGB signal across the SCART directly and eliminate the AD725 (and thus the need to run at exactly twice the NTSC clock), that might be a bit trickier (though not impossible). I'd need to find a usable speed for the MCU that can generate the output at PAL timing. As stated above, a SYNC signal isn't needed at all when using SCART RGB and some TVs may not even support it.

That being said, I don't think it'd be wise to run the Uzebox at a significantly reduced speed. The PAL color burst is 4.43361875 MHz, opposed to the NTSC one at 3.579545 MHz. Running at roughly the same speed (26.6017125 MHz for instance) would only give you 6 cycles per color burst instead of 8. In order to get 8 cycles (like with the NTSC one), you'd need to run at 35.46895 MHz and then we're back to the original timing problem.

Would it be doable to run the Uzebox with 6 cycles per burst instead of 8? Would it require significant rewrites? You might even get it to output composite PAL across the AD725 if you use a secondary stand-alone clock at 17.734475 MHz.

- Fahr
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox PAL support

Post by uze6666 »

I'll be testing it on a newer TV shortly and if I get that working, I'll report back my findings in another post. I was thinking of drawing up a schematic that wires a SCART connector for all 3 signals with a switch to decide which one you want. Stay tuned for more on that :P
Sure, please do so. We need more research done on PAL/SECAM/etc.
Would it be doable to run the Uzebox with 6 cycles per burst instead of 8? Would it require significant rewrites? You might even get it to output composite PAL across the AD725 if you use a secondary stand-alone clock at 17.734475 MHz.
The color burst cycles and color modulation is all done by the AD725, we don't have control on this by software. Keeping the 28.8Mhz clock for the MCU while using a secondary crystal @ 17.734475 MHz just for the AD725 is the easiest solution for PAL. However, I suspect this could cause some color artifacts due to the two clocks being asynchronous....but I could never test that. If you could test it for PAL that would be great.

-Uze
Fahr
Posts: 15
Joined: Sun Feb 07, 2010 6:44 pm

Re: Uzebox PAL support

Post by Fahr »

uze6666 wrote:The color burst cycles and color modulation is all done by the AD725
Be that as it may, doesn't SOME of the timing still come from the Uzebox? What about the number of pixels per line or the number of lines per screen or the SYNC? Those values are different for PAL as well. I would think some modification is required there, at least?
uze6666 wrote:If you could test it for PAL that would be great.
I'll see if I can get my hands on a 17.734475 MHz oscillator module, as the AD725 is not going to accept input from just a crystal I think... It also seems that any oscillators that produce a multiple of the PAL burst are very hard to find. I may have to get a crystal and make my own oscillator...

Update on the SCART: turns out my TV DOES support RGB with SYNC. The problem was in the SCART cable I used; it's fully wired, but mainly intended for composite. This means that pins 19 & 20 are crossed from one end to the other, to make composite input and composite output appear on the same pin on either end. In RGB mode, pin 20 is used for SYNC, assuming you have a straight SCART without crossovers. For my SCART cable, wiring the SYNC to pin 19 solved all problems and the picture is crisp and excellent!
A note of warming though; I tried wiring pin 19 and 20 together so it would work regardless of the SCART cable used and that caused the TV to send a rather severe spike back into my circuit, which fried my AVR Dragon! :(
Experimentations will resume once I get a new programmer :\

- Fahr
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox PAL support

Post by uze6666 »

Be that as it may, doesn't SOME of the timing still come from the Uzebox? What about the number of pixels per line or the number of lines per screen or the SYNC? Those values are different for PAL as well. I would think some modification is required there, at least?
Yes you're right, I replied a bit too quickly this morning. There's a few threads on the PAL topic here. Hardware wise it's easy to "fix". However, the software has always been the problem since the CSYNC signal will indeed be different from NTSC. I don't think the timing would be that hard to tweak to handle PAL, but I'm unsure if the embedded kernel in games could be coded to handle both standards without game recompilations. Not that it's a big deal in itself, but again I'm wondering about the time base differences 50Hz vs 60Hz and the 625 vs 525 lines issue? I don't thing most are interested in coding/tweaking 2 versions of their games against standards they can't even test. That's why, I think, most discussions always ended up with someone mentioning that all relatively recent TVs sold elsewhere than in North America supports NTSC (and/or it's timing)...
Update on the SCART: turns out my TV DOES support RGB with SYNC. The problem was in the SCART cable I used; it's fully wired, but mainly intended for composite. This means that pins 19 & 20 are crossed from one end to the other, to make composite input and composite output appear on the same pin on either end. In RGB mode, pin 20 is used for SYNC, assuming you have a straight SCART without crossovers. For my SCART cable, wiring the SYNC to pin 19 solved all problems and the picture is crisp and excellent!
Great news! So now, we know it can work fine with SECAM & PAL TVs using the SCART interface! :D

-Uze
Fahr
Posts: 15
Joined: Sun Feb 07, 2010 6:44 pm

Re: Uzebox PAL support

Post by Fahr »

uze6666 wrote:I don't think the timing would be that hard to tweak to handle PAL, but I'm unsure if the embedded kernel in games could be coded to handle both standards without game recompilations. [...] That's why, I think, most discussions always ended up with someone mentioning that all relatively recent TVs sold elsewhere than in North America supports NTSC (and/or it's timing)...
That's a valid point and now I've figured out the wrongly wired pin on my SCART, I don't really see much sense in getting it to output PAL either... The simple fact is that PAL requires more pixels on more lines and thus more processing power, which may not be readily available without clocking the MCU to insane speeds.
So the question becomes; is it worth it? Having it output PAL will definitely mean a decrease in all other areas, leaving less computation power for game logic and who knows what else... And personally; I don't really SEE any difference. It's not like we're talking about using HD instead of NTSC (though it would be interesting to see the Uzebox output HD :P perhaps in 10 years).
So perhaps the previous conclusion was correct and we should let this one go... Since RGB SCART works fine with the correct wiring, I don't really see any use anymore.
uze6666 wrote:Great news! So now, we know it can work fine with SECAM & PAL TVs using the SCART interface! :D
That's right! :D But do note that if you wire the Uzebox directly to a SCART CABLE, you want to wire the SYNC to pin 20. If you wire it to a SCART SOCKET (like I did), you want to wire it to pin 19! I've just checked and various sources say that all SCART cables have pins 19 and 20 inverted. The same is apparently true for audio and composite video. I've not yet wired up the audio connector, but it's something to keep in mind!
I will eventually make a schematic for a SCART connector carrying all 3 possible signals with a switch.
martink
Posts: 1
Joined: Thu Jun 17, 2010 1:52 am

Re: Uzebox PAL support

Post by martink »

If you are still looking for a volunteer to do the PAL testing then I can probably help out here, am just waiting for the parts to arrive for my scratch build. NTSC is just not going to work in Australia (where I live) so am happy to spend whatever time you need to get this going.

M.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox PAL support

Post by uze6666 »

If you are still looking for a volunteer to do the PAL testing then I can probably help out here, am just waiting for the parts to arrive for my scratch build. NTSC is just not going to work in Australia (where I live) so am happy to spend whatever time you need to get this going.
Yes, still looking... 8-) So what exactly are you gonna build? With the AD725 configured in PAL mode or trough an SCART interface?

-Uze
Post Reply