Why the unusual frequency?

[Bunsen]

I hate to bring this back up

No, please do. I'm looking forward to further updates on this project.

what other effects would I see by bumping up the frequency? / to 8 MHz

Wait- up to 8MHz? I thought it was at 16MHz already?

Sorry I can't offer any advice on this, apart from heat issues, which I'm sure you've already considered. RAM timing?

 

[MarkS]

The logic board has circuitry that divides the clock signal in half. I would need to supply a 16MHz clock to the logic board in order to run the processor at 8 MHz.

 

[H3NRY]

The RTClock / calendar / PRAM chip has its own 32KHz crystal. Everything else runs off the "16MHz" clock. If you don't care about serial baud rates, floppy read / write, or video scan rates, you can experiment with over / under clocking.

 

[MarkS]

The RTClock / calendar / PRAM chip has its own 32KHz crystal. Everything else runs off the "16MHz" clock. If you don't care about serial baud rates, floppy read / write, or video scan rates, you can experiment with over / under clocking.

The video rate would be the reason to do this. Getting it from 15.6677 to 16 MHz would make it much easier to read. Nothing now runs off such an odd frequency and reading any data clocked off of that frequency presents some rather difficult challenges. But hey, Apple saved a buck or two on a baud frequency generator! :disapprove:

 

[Gorgonops]

I still don't understand why you simply can't source the clock off the Mac motherboard. If you don't want to solder to it use an alligator clip. I'm sure there's somewhere you can pin one one. (They sell teeny-tiny ones small enough to grab the legs of surface mount components, you know, let alone through-hole IC legs.)

 

[MarkS]

I can. The issue is the strange frequency. Most microcontrollers and processors are made today to use a evenly divisible clock frequency. I want to use the Propeller because it have built in video generation, but it works best with a 80 MHz clock (delivered via an external 5 MHz source clock and its internal PLL). Since there is an unique pixel on the video line at each clock pulse, I cannot simply read the video signal and act upon it. 0100011100000 would look like this to the Prop: 01010. Clearly not the correct pixel data. This means that I must run the prop at the 15.6672 frequency and test the video pin at each clock pulse. However, looking over the Prop's data sheet is not giving me much hope that this will work.

One thought I had was to use a serial in/parallel out shift register running off of the 15 MHz clock. Then all I would need to is read each output of the shift register with the Prop. This would guarantee the correct pixel data. At least I think it would...

 

[porter]

Can the propeller work from a 62.6688Mhz clock? If so it's sampling can synchronised with the mac's pixel clock at four times.

Alternatively, can it not use a 78.336Mhz clock? So instead of a 5Mhz clock, give it a 4.896Mhz clock derived from the Mac's crystal.

 

[Bunsen]

Porter's suggestion looks like the best yet. Gives you more cycles inbetween sampling to do other stuff. Not that you probably need them with 8 cores onboard.

Does the Prop generate VGA timing independently of its own clock frequency?

You may (or may not) find relevant information and/or inspiration in the MPxPlayer and EvilTim's other projects.

 

[Gorgonops]

I can. The issue is the strange frequency. Most microcontrollers and processors are made today to use a evenly divisible clock frequency. I want to use the Propeller because it have built in video generation, but it works best with a 80 MHz clock (delivered via an external 5 MHz source clock and its internal PLL). Since there is an unique pixel on the video line at each clock pulse, I cannot simply read the video signal and act upon it. 0100011100000 would look like this to the Prop: 01010. Clearly not the correct pixel data. This means that I must run the prop at the 15.6672 frequency and test the video pin at each clock pulse. However, looking over the Prop's data sheet is not giving me much hope that this will work.

This reference I stumbled across says this about video generation on the Propeller:

Each cog has a hardware video generator and two special counters (CTRA and CTRB)

* Both counters have 3 special registers (CTR, FRQ, PHS)

* The basic function of the counter is to add the quantity in the FRQ register into the PHS register. When and how this is done is determined by the setting of the CTR register.

* Counters can operate independently from cog CPU with clock rates (controlled by CTR, FRQ registers) from 500 kHz to 128 MHz. This done via a PLL and VCO controlled by bit PHS(31).

* CTRA is used by the video generator, when the video generator is utilized.

This implies to me that you can clock your output scan rate independent of your CPU clock rate. Assuming that PLL applies a divisor or multiplier to the crystal input rate it seems to me the only thing you'll have to do is adjust whatever sample video generation code you're using so it applies a different multiplier to compensate for your "odd" synchronous clock input.

Frankly, the Propeller would be practically unworkable if it didn't allow something like this. For instance, the example code I've seen implies that it's possible to switch from, say, NTSC to PAL video timing simply by adjusting software. If the output scan rate was somehow synchronous to the CPU clock then it seems to me it would be necessary to change a crystal to do that. (VGA vs NTSC might be possible with the same crystal, as VGA is basically 2x NTSC, but PAL throws a monkey wrench in the works.) It also looks like it's fairly trivial to use the same counters to generate oddball frequencies for, say, driving LCDs. Unless I'm missing something it seems this should be a solvable problem.

One thought I had was to use a serial in/parallel out shift register running off of the 15 MHz clock. Then all I would need to is read each output of the shift register with the Prop. This would guarantee the correct pixel data. At least I think it would...

I did suggest a shift register on the first page. ;^) If you're afraid of driving the propeller at a "strange clock" then a shift register should basically solve all your problems. According to my back of the envelope calculations you'll have to sample at *about* 2Mhz if you can grab parallel bytes instead of bits. Suddenly you can get a lot sloppier with your timing. (Ideally it would be nice if your shift register could generate an interrupt when it was time to clear it, but polling might work as well.)

 

[MarkS]

The Prop doesn't use interrupts, BUT by monitoring the clear pin on the shift register I could fake it.

I need to start prototyping. Something tells me this will be easier than I think, but I'm going to have to be a little more clever than I'm being.

 

[Gorgonops]

I'd probably suggest starting with one of those development boards that has a VGA plug on it so you can really wrap your brain around how video generation works on those things. It would probably clarify a lot of your questions better then a data sheet will.