Uzebox PAL support

[uze6666]

It is not problem with new TVs here in EUROPE.

Thats great news, case closed then!

Uze

[antibyte]

Some time ago i did run an atmega at 40 MHz generating white noise to a speaker
It did run, but i doubt also you get reliable results in any case.

[CompMan]

Some time ago i did run an atmega at 40 MHz generating white noise to a speaker
It did run, but i doubt also you get reliable results in any case.

What are you trying to say?

[antibyte]

I forgot to quote a post from page one ot this thread :

Code: Select all

I was looking at the AD725 doc and realized that for PAL it requires around 18Mhz. Doubling that, as required by the software, would give ~36Mhz! I didnt' try it, but I seriously doubt the mega644 will work at that speed.

Some time ago i did run an atmega at 40 MHz generating white noise to a speaker
It did run, but i doubt also you get reliable results in any case.

What are you trying to say?

[CompMan]

Okay, I see what you are saying.

Thanks,
Compman

[uze6666]

40Mhz? Thats 200% of the normal speed! I should try that one day. However, the problem was I could not find any crystal that is a multiple of the NTSC color burst (3.57 Mhz) above 28.6Mhz. Thats required by the AD725 and also makes better video sync.

Uze

[Johan]

So the only other alternative would be to develop something for the RGB SCART like everblue said. I saw a project on net the other day doing just that. This will however require a rewrite of most sync and rendering code, not for the feint of heart .

Thank you for the effort you've put into this cool project! I am waiting for my devkit to start writing code for AVR, so you can refer to me as a beginner. However, I have a question on this. The AD725 is an RGB to Composite or SVideo converter chip, right? So, why can't you just skip this chip and hook the RGB+sync directly to your tv? Is it another kind of RGB?

Best Regards

Johan

[davinci]

I was thinking of creating something similar myself, until I found this. I live in Europe, and I would like to get this working on a PAL system. So if I understand is there is no way to support Pal from the microcontroller with less than ~38MHz?

I have found some projects using an AVR to generate a PAL signals, but I'm not sure if it is usable:
http://www.serasidis.gr/circuits/colour ... ar_gen.htm
http://trznadel.info/kuba/avr/index.php

Also this one uses an external CPLD for phase shift. I know it is not as minimalistic, but its not a big change either:
http://www.innovativedevice.com/gamestation.htm

Unfortunately I'm more a software man myself, so tinkering with hardware is not my strongest side. Still, PAL would be nice

Regards,
Vincent

[villekille]

I think it would be possible to make a PAL version but it would require a different atmel controller, the new Xmega is a 32mhz device, it might overclock easily to 38MHz

[Fahr]

I had an idea regarding PAL (and perhaps the Uzebox in general) the other day and thought I'd share. I'm mostly (if not only) a programmer and I'm fairly new to the AVR world (though I did manage to build a Uzebox on a breadboard ), so I'm not actually sure if any of this makes sense, but bear with me...

From what I understand, the MCU has to run at twice the clock speed required for the 4FSC input of the AD725. A timer interrupt makes PB3 pulse every other clock cycle.
If that is indeed all there is to it, why not program the CKOUT fuse, wire CLKO (PB1) directly to the AD725 4FSC input and run the MCU at half the speed it runs at now? That way, an NTSC Uzebox could run at 14.318180mhz (no overclock required) and a PAL one could run at 17.734475mhz - very doable!

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.

I'm probably completely wrong about this one, but I thought I'd share it anyway. I would very much like it if someone can explain why this wouldn't work (assuming it doesn't). I'm thinking my perception of how the internals tick might be way off. I browsed through the Uzebox source, but couldn't find anything to either validate or refute my ramblings. Though that might be because I don't really read ASM very well