AVR Freaks

How? Well, that Atomic Zombie fellow figured out something amazing on a day off.

Sheesh, it took me all summer to get a TFT display to say "BarefootElectronics.com."

Waiting excitedly for details.

"AVR Magician" would seem a minor title compared to "Atomic Zombie."

And, of course, "Anybody" could do it with an xMega. The Zombie challenge is to do it with an tiny 85!

Amazing!

If you're driving blue and red together, it seems to me your palette would be:

Where does cyan come from?

I'd guess from your schematic that you drive R and G by manipulating the internal pull-ups on PB0 and PB1, and HSYNC and VSYNC by driving PB0 and PB1 low (by setting PORTB0 and PORTB1 low and manipulating DDRB0 and DDRB1).

This seems to imply that your VGA monitor has high-value pull-down resistors on the colour input pins. Is this part of the standard?

JJ

Shame you can't read the prescaler register.

The other trick, that you are almost certainly aware of, is to put the AVR to sleep, just before the interrupt. This guarantees a fixed latency, but would involve a lot of cycle counting in H sync to know when to go to sleep mode.

Genius!

JJ

Who needs ARMs or C .......

I STILL have to try this. Needs a CRT monitor, or will LCD do?

I will never measure up around here! ;-)

Come back to the dark side.....forget C....

We are unworthy.

My next ATiny Demo will be a game I call "BONG".

Ohhh I thought it was named after the sound of you computer after "upgrading" to AS7!

The thread title has been edited to reflect the hardware changes. Used to be 4-colour + sync = 3 pins for video, + 1 pin audio, + 1 pin input = 5 pins.
Now it's 8 colour + sync = 4 pins for video, + 1 pin input = 5 pins. Nothing left for audio.
I'm very interested to see how Brad will pull it off. I have little doubt that he will!
Brad, if I think fo anything, I'l let you know!

Not only can you squeeze into SRAM space, and crank cycle counts up to whoopee, but you have so much flash space that you can light your cigar with a $100 bill...

// SETUP ATTINY-85 IO PORTS
sbi DDRB,0 ; COMPOSITE SYNC
sbi DDRB,1 ; RED COLOR BIT
sbi DDRB,2 ; GREEN COLOR BIT
sbi DDRB,4 ; BLUE COLOR BIT
cbi DDRB,5 ; JOYSTICK ADC

Five words (10 cycles?)  when three words/two cycles will do

If you place the line buffer in SRAM such that the very last auto-increment of Y uniquely sets one of the bits in YL or YH, then:

loop:
  ld r16,Y ;2
  out PORTB,r16 ;1
  st Y+,r17 ; 2
  bst <YH/YL>, <unique_bit>
  brbc T, loop ; 2

Now the loop is 8 cycles, getting you 115 pixels, but no need for a timer or interrupt.

EDIT:

Similarly, you could place the line buffer such that the last auto increment of Y results in YL=0:

loop:
  ld r16,Y ;2
  out PORTB,r16 ;1
  st Y+,r17 ; 2
  and YL, YL
  brne T, loop ; 2

AH, I like the way you think with the Timer idea!

Unfortunately, I am using both timers.

One triggers the Horizontal Interrupt every 1146 cycles, and the other de-jitters the interrupt.

Why do you need the second timer?  Surely you can dejitter a timer interrupt with its own TCNTn register.  We've had many discussions on this before I believe...?

You could also use the ADC interrupt, provided you triggered the start of a conversion such that the interrupt occurs at the precise moment you need it.  With a VGA line frequency of ~31.5 khz, you'd need conversions to come in at least that fast.  With a 36 MHz and /64, the ADC clock would be 562.5 kHz (good enough for 8-or-9-bit conversions).  A manually started conversion would take (about *) 13 clocks, or at an inherent rate of 43.269 kHz.  Not a good fit, since the conversion would need to be initiated while the line buffer loop was running.

EDIT:  checking my math... working in cycles instead of Hz... /64 and manual conversion is 64*13 = 832 cycles... so too fast... /128: 12*13 = 1664 cycles... so too slow. /EDIT

* Then there's the matter of synchronising to the ADC prescaler... something only done by ADATE mode... however you could manage this by selecting a trigger source whose bit will be guaranteed to be set (enable a pin change mask on the Vsync pin, but not the interrupt, and select ADTS[2:0]=0b110) , and manipulating the ADATE bit to trigger a the prescaler reset and a sample start, but I still see no easy way to set this up in the blanking period >>and<< get interrupted anywhere near the end of the line.

Hmmm... might be another way... I'll keep thinking on it...

Since I need to count to 1146

Right, now I remember.

Wait!  Oh!  Use the USI 4-bit timer and its overflow interrupt to get a 12-bit timer.  That's enough for 4096 counts.  TIMER0 could run at /1, and the jitter nulling code would only need to examine TCNT0.

Even if you don't use this to roll up the line buffer loop, it will free up a timer for other use (PWM on TIMER1/OC1B for audio?  No... that's for 'blue'...)

Hmmm... USI counter can be clocked from TIMER0's compare match, but it's not clear which one, A or B.  Perhaps both?  Also not clear is whether it needs a positive edge on the compare match flag (which would require that an interrupt or software clear that flag each time), or if it takes the signal directly from the timer's compare unit.  A test on real hardware would be in order.  I'll see if I can do that this week (shop is a mess, haven't been doing any real AVR work for quite a while now, just feeding my need with Freaks).

The block diagram is no more clear:

I guess that you kind of know what the program do (I assume that mush of the code are inside an ISR), so it should be possible to back the timer in the ISR. (a couple of times).

Provided the ISR execution time is (after jitter nulling) constant, or can be made to be constant (I expect it can or already is).

And provided the time spent >>between<< passes of the ISR is under 256 cycles.  Which, I believe, it is.  920 cycles spent pushing out the line buffer, so max 226 cycles spent outside of ISR.  Far less, actually, with interrupt response time, jitter nulling, house keeping in the front and back porches...

So just precompute (by cycle counting at build time, possibly with the help of macros to do the arithmetic for you) what value to load into TCNT0, clear TOV0, and return.  Prescaler of /1.  No second timer.  No USI counter.

I like this better.

Hmmm... USI counter can be clocked from TIMER0's compare match, but it's not clear which one, A or B.  Perhaps both?  Also not clear is whether it needs a positive edge on the compare match flag (which would require that an interrupt or software clear that flag each time), or if it takes the signal directly from the timer's compare unit.  A test on real hardware would be in order.  I'll see if I can do that this week

OK, just did a test.

When USI is clocked from TIMER0 compare match (as the datasheet says), this is compare match 'A' only.  Not compare match 'B'.

It also takes its signal directly from the compare unit, meaning that it is not necessary to clear OCF0A after each match.

So, to configure TIMER0/USI to interrupt (USI_OVF) every 1146 cycles, you can run at /1 in CTC mode 2 with OCR0A = 190 (period = 191), and preload USICNT[3:0] with 0xA.  Six additional counts on USICNT[3:0] will result in a USI overflow interrupt.  191 x 6 = 1146.  Use USI_OVF_vect, but null jitter against TCNT0.

The catch is that you need to reload USICNT[3:0] every time.  Since you've got 191 cycles to do that before the next TIMER0 compare match, that shouldn't be a problem.  Do it after the jitter nulling and any other critical code.

This might be a bit more flexible than @sparrow2's suggestion because changes in ISR code during development wouldn't require you to re-precompute the value to load into TCNT0 at the end of the ISR.  However, his USI-less approach has a certain raw appeal which seems to fit well with Quark85's other design goals ;-)

Either way, TIMER1 is now free for other things.

Fantastic bong, by the way.

And what what is the limit for the internal osc, it could be really cool if the external clk could be removed.

On one test device I've cranked the internal RC up to a little over 14.5 MHz, which should theoretically allow a high frequency PLL system clock of 29 MHz.  However, the PLL multiplies the RC clock by 8 before it is divided down again by 4 to arrive at the high frequency PLL system clock.  So that's 116 MHz.  Unfortunately, the PLL is spec'd to saturate at 85 MHz (worst case), so as a guess I'd say it's unlikely that you could get as high as 29 MHz, at least not stably.

Regardless, the RC oscillator is certainly not stable enough (too much cycle-to-cycle jitter) to support a video signal.  Mind you, the PLL itself might provide a stabilising influence.  Tests on real hardware would seem to be in order, but even if ~29 MHz were stably achievable it would be challenging to keep it from drifting with temperature and voltage.  Would be hard to hit an exact frequency as well.  Changes in OSCCAL are pretty granular (~1% per step within each of the two ranges).

EDIT: Hmm.  I revisited the test results I'd gathered and apparently I had also tested with the hf PLL system clock.  It did in fact reach a wee bit higher than 29 MHz.  This implies that the PLL itself did reach 116 MHz.  Of course, this was for one device.  The PLL is still spec'd to saturate as low as 85 MHz.  My tests did not include the characterisation of jitter, neither for the RC directly, nor for the hf PLL clock.

Here's a graph:

Image is actually 1600x1200.  Right-click and 'save image' to view it full size in your own image viewer.

Probably still worth a try if Brad is up for it.  If it works, one more I/O!

/EDIT

EDIT2:  I just ran the test on another t85 (without graphing), and topped out at 29.362 MHz.  The next step down was 29.011 MHz.  That's a step difference of 1.2%.  /EDIT2

But if you have that on a separate line it will be low(or high depending on sync) for 96 clk cycles (out of 800), if you could make that as an sound enable, and then modulate the sound on one of the colours that should work (and since the line freq are >30KHz kind of ok), but that way you will need to make sound for all 800 lines (else there will be a big 60Hz hum ). 

If I recall correctly, the VGA spec has requirements in the H and V blanking areas w.r.t. the colour channel signals.  Some monitors might refuse to sync if there were signal present on the colour channels during the blanking period.  Other monitors might get confused when 'auto-detecting' image parameters (as most LCD monitors do these days).  It's worth a shot, though.

Or perhaps the joystick can sit on the RGB pins, and the make a conversation with 60 Hz, if green is used for sync, then it will fit fine with ADC on the R and B pin.

Interesting.  I'm not sure I follow though.  Are you thinking of something like this?:

        VCC
         |
---------+----+                          Colour
         |    |     +------------------> channel
         |    |     |                    output
        |R|   |     |
        |_|   |     |
         |    |     |      +------------+
         + /  |     |      |            |
          /   |     |      |  Joystick  |
         +    |     |      |  resistor  |
         |    |     |      |   network  |
   >-----+----+-----+------+            |
         ADC  |            |            |
              |            |            |
---------+----+            +------+-----+
         |                        |
         |                        |
        GND                      GND

While in the vertical blanking period, the pin is switched to an input with pullup, and the joystick's resistor network applies a voltage to the pin for the ADC to read.  Otherwise the pin is made an output and the drive strength overwhelms the joystick resistor network so that it doesn't affect the signal strength of the colour channel output.

Rather than use the internal pullup, the resistor network could connect directly to V_CC.

Care would be needed in the design of the resistor network.  IINM, Brad currently ties the ADC pin to VCC for the fire button.  With such an arrangement, a '0' output on that colour channel would sink a lot of current.  So the resistor network would need to ensure that never happens.  High-value resistors would be needed throughout, or changes in joystick input will result in perceptible voltage drop on the colour channel output.

However, moving the joystick to a colour channel output pin doesn't immediately solve the problem of where to put the audio.  Currently Brad has the joystick on ADC0/RESET, but without programming RSTDISBL.  It won't be possible (never say never?) to use /RESET as an output without programming that fuse, and Brad has been resistant to that idea in the past (I do it all the time on 8-pin tinies, I've made my own HVSP programmer).

Which clk speed do you give the ADC (it must be high :) ) 

36M/128 = 281.25 kHz.  A bit high for 10-bit, but plenty low for 9- or 8-bit.

perhaps try to program it as outpot, and make a tone, perhaps a "very" weak output. 

Unless RSTDISBL is programmed, PB5 cannot be made an output, and the internal pullup cannot be disabled.

The only way to affect /RESET without RSTDISBL, that I can think of, is to switch the MUX to ADC0.  Doing so will >>very slightly<< capacitively load the pin.  You could FM modulate an RC (or LC, or LRC) oscillator which used pin capacitance as (at least part of) the 'C'.  So an AF signal could be created by controlling where and when the MUX is changed to ADC0 and the joystick (and perhaps also the GND channel to drain the S/H cap, for more impact on C_PIN).

Which voltage did you make your PLL tests, 5V or ? does it matter?

~5V.  Didn't try lower.  Speed grade would require ≥ 4.5V for 20 MHz anyway, and of course > 20 MHz is out-of-spec ;-)

I don't think that there are to mush jitter in the internal clk, but could be wrong, and a speed change of +-1% should not matter for the monitor.(as long it's slow changes)

IIRC Brad has tried the internal RC for video in the past, with negative results.  Don't know if he tried the PLL though, and I don't know if the PLL exhibits better or worse cycle-to-cycle jitter.

About sound, I bet that a adc mux change (to and from ADC0), will make a small "click" on the reset pin.

Only if V_S/H is different than V_RESET.  You could ensure this by switching to the GND channel right before switching to ADC0.

What I was suggesting is to FM modulate an oscillator which depends upon the pin capacitance of /RESET.  Such a modulation would not be (greatly) dependent upon V_S/H, and would persist as long as the MUX is ADC0, rather than the single spike generated at the moment the MUX is switched.

I think that is the killer - other threads have shown relatively poor jitter on AVRs RC Osc

As was noted.

As was also noted, I believe Brad has already tried (and concluded it was too unstable), but I don't know if he did so with the hf PLL system clock.  The PLL will have different (if not better) characteristics than the RC oscillator which drives it, since the PLL's low-pass filter might quell some of the oscillator's jitter.  Perhaps not enough, however.  And perhaps the VCO itself wanders too much as well.

Still, worth spending 30 minutes to test, since it would buy an extra I/O pin.

It will also cost some resolution, though.  If 29.362 MHz is representative of the best a typical t85 can hit, that would limit a horizontal line to 932 cycles for the 800 pixels.  The 640 'visible' pixels would represent 745 cycles, and with Brad's 5-cycle unrolled loop, that's 149 pixels at most.

I think even if jitter is manageable, the drift and imprecise nature of the final system frequency will make it hard to meet VGA timing requirements.  Some monitors might like it, some might not.

Looking forward to it!

How do you plan to latch the 3-bit audio DAC using only passives?  I suppose if you allow yourself a half-dozen transistors...  or just one FET to act as a gate for a S/H cap.

Why would V-sync impose a 60 Hz signal on audio?  The line interrupt will still be happening (although it won't need to push out pixels), so you'll have the same sync point for the audio sample during the 45 non-drawn lines, including V-sync... or am I missing something?

Will the 0.6V drop of a diode (or 0.2-0.3V drop of a schottky) be low enough for the monitor to perceive the colour drive to be 'black'?  Or is there danger of a universe-devouring wormhole?

Welcome to AVRFreaks Jari.

Cheers,

Ross