AVR Freaks

Sweet Jeebuz!

Using an clock would buy you a 5th pin, but I guess that would be cheating ;)

I'd hazard a guess that you're somehow piggy-backing onto the HSYNC @ 31.4686 kHz, but I can't figure out how you might do that without breaking the VGA standard... and how you'd get two audio channels out of that, I don't know... unless you can do something similar with VSYNC as well...

I'll bet the diodes have something to do with it ;) ... and maybe some clever use of DDRB... but I'm too tired to think it through now... big day tomorrow, off to bed...

Really looking forward to following this project!

JJ

[edit] Wait! Do you use the red and green lines for audio during horizontal blanking? Each tied via a diode to the HSYNC line? I'll post a schematic if I can figure it out... likely not until Wednesday before I'll have time... I bet someone else will beat me to it ;) [/edit]

And what about left@low and right@high?

These would fall under:

OK... really... bed...

[edit]
OK, quick one before I go off to work for 13 hours...

If you are using SOG, and are only using two outputs for colour (green and red) with a little resistor-based mixing to get cyan and purple (magenta?), then you'd really need only two outputs for video, leaving two for audio...
[/edit]

JJ

Brad, once again you did it !
You should be honoured with the title "AVR Magician"

Nard

You're mad! Stark raving mad!

And I've GOT to build one of those! I even have an old vga monitor sitting here.

32 MHz.

Brain.  Hurts.

Some people make walking on water look so easy...

I wrote a game for the Atari 2600 a long, long time ago. It was crap. The game, that is, not the console.

I may as well go back to swinging a wrench and climbing ladders for a living.  I will never measure up around here! ;-)

Agreed. Amazing what he can do with an AVR.

Nard

Hmm. AS7 went in smoothly here. You'll conquer it, perhaps with a Tiny10 to do the makes.

I do this 184 times, fully unrolled.

That's over 1K of code space for just that loop!

What is being written back?  Always r17?

Well, if you're satisfied with 130 pixels, you can roll the loop back up:

loop:
  ld r16,Y ;2
  out PORTB,r16 ;1
  st Y+,r17 ; 2
  rjmp loop ; 2

continue:

Configure a timer interrupt (do you have any to spare?) to break in after 130 passes (exactly), and then dump the return address from the stack and jump past the loop:

isr:
  pop ; 2
  pop ; 2
  jmp continue ; 2

If you can put this right in the vector table (although you'll forfeit the next vector), the total cost of breaking in would be 10 cycles, so maybe you could only get 128 pixels.  If you can't lose the neighbouring vector, 12 cycles.

Although this drops you from 184 to 128 pixels, it also buys you 1K of flash.

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