Impossible Graphics Power from an ATiny85!

Go To Last Post
166 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andrewm1973 wrote:

Who-me wrote:

AtomicZombie wrote:
Yes, if you use a module, then for every burst of 40KHz it will output a negative pulse. At that level, you only need to convert the 14 bit packet into a command.

What I would like to do is only use an infrared photo sensor, and have to actually listen for the carrier wave and also decode the raw data.

If you want to use a simpler infrared photo sensor, perhaps a large pullup, can create a simple monostable action so the carrier is filtered  ?

However, the receiver modules are simple, and have good immunity to lighting etc, so they will be hard to beat.

 

Brad is the one that has tried it, So I'll let him confirm if the baseband signal sharing a pin with the audio is a problem, but I imagine it would be.

 

Issues like that are why I think a move to a 14 pin package makes much more sense.  

Then the software can have fewer self-imposed compromises, and a better performance results - and it's cheaper as a bonus :)

 

andrewm1973 wrote:

RC5 is something like manchester with a one or two kilohert baud rate from memory.  That would mean there would be a 1khz and a 500hz signal appearing there when buttons are pressed.

 

WRT just trying to AM demodulate (no bandpassing) the 38Khz with a large R (or RC), that would still have the baseband noise and loose the ambient light immunity of the 38Khz signal (its reason for existing)

Yes, the simple 'infrared photo sensor' likely needs some added bandpass configure and amplifier for those ambient and lighting rejection reasons, which is why I think the receiver modules are actually simpler to deploy.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would change the game going up to a SOIC14.  Then you COULD have a chip with 2K or RAM.  I don't think that is Brads game and he gets his fun by trying to squeeze it into the 8 pin chip with 512B RAM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andrewm1973 wrote:

It would change the game going up to a SOIC14.  Then you COULD have a chip with 2K or RAM.  I don't think that is Brads game and he gets his fun by trying to squeeze it into the 8 pin chip with 512B RAM.

 

The bigger challenge is to squeeze the operations into the code, The package limit delivers a predictable outcome, that limits what the software can deliver - even on 512 bytes RAM.

(There are 10 pin MCUs, just not very many of them...)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it's the draw of having only 4 real IO pins along with the 512 bytes of RAM that makes me like this uC. This DIP format also makes it friendly to anyone wanting to try this insanity.

 

I had some time to mess around with the TV remote, and yes it causes noise on the audio.

 

Perhaps it is time to call this project "good enough" finally and get it on a circuit board on top of that 9v battery as I planned.

Making demos is actually appealing because there is no input device required, just the Tiny85 and a few parts bin semiconductors.

 

I am going to complete a PCB now and leave this one as Quark-85 Demo Kube.

The Ball Demo is really nothing special, so and I want to do some over-the-top coding now.

With the new sound routine almost ready, Q85 will be capable of some much better demo productions.

 

If I have time, I will hand wire a board tomorrow, and then do a real PCB and post the files here.

 

This PCB sits on top of a 9v battery, which is clipped into a holder on the underside.

Plug in your monitor, speakers, and AVR programmer then hit the bare metal!

 

 

Brad

 

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

andrewm1973 wrote:

It would change the game going up to a SOIC14.  Then you COULD have a chip with 2K or RAM.  I don't think that is Brads game and he gets his fun by trying to squeeze it into the 8 pin chip with 512B RAM.

 

The bigger challenge is to squeeze the operations into the code, The package limit delivers a predictable outcome, that limits what the software can deliver - even on 512 bytes RAM.

(There are 10 pin MCUs, just not very many of them...)

 

No I think the bigger challenge is to get as much functionality out of 8 pins.

 

Impressive VGA demos on AVRs have been around for a decade (look at Craft by lft).

 

Large sprites have been around on AVR video things for quite some time (look at Brads own demo that had a horse running in it)

 

Squeezing insane amounts of action out of the available clock cycles has been done (look at my project T2K)

 

What brad has done here that is _amazing_ is getting more functionality from 8 pins than at first you would think is possible.

 

I'm pretty sure he wants to stay on 8 pins.

 

I would really like to see him be able to get that IR decoding working on 8 pins and will offer any suggestions and help I can to see him achieve it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

 

I had some time to mess around with the TV remote, and yes it causes noise on the audio.

 

Brad

 

Are you sure you want to give up there ?  As per my above post I'd like to see you get there if it is possible.

 

Was the noise from the TV remote when trying to use the baseband or the modulated signal?  If it was the 38Khz being a problem then its game over I guess though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@brad - PB4 is an ADC pin.  You could modulate the voltage on that between 5v and some other high voltage that is well above the sync "low threshold" at the RC5 baseband rate and still get data at non-sync times.

 

You would go blind during sync.  But IR remotes transmit each button press over and over, so you should be able to get a good read in there somewhere.

 

Edit: Ignore what I said about going blind during sync and that being a problem.  I just looked up the VSync period on VGA - it is only 2 H_periods or 1/15000s period.  That is and order of magnitude less than a bit time in the manchester RC5 stream.

 

It should be trivial to put a 38Khz IR receiver module (GP1UX or something) shared with the Sync pin (PB4) and get the baseband manchester with the ADC.

Last Edited: Sun. Mar 11, 2018 - 11:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I m convinced... thanks for the push to keep going and the ideas!

 

I did some further experimentation and found that I can actually share sync with the color pins in several ways.

Having RGB and Sync on 3 pins leaves B.5 for input and one free pin for sound (Timer1 PWM).

I have a really nice set of sound routines that use PWM and even include waveforms and ASD ramps.

So I think the key to getting proper input and good sound is to make pin sharing work properly again.

 

Here are the possible ways to share pins RGB with sync...

 

1) Originally, I used a pullup and just had sync and color together, but it fails on 50% of monitors and degrades image quality.

 

2) Last night I tried using 1 4.4v zener as "voltage level gate" to share sync and color and this works...

 

 

RGB is tristated : DDRB sets pixels (pins set hi), and pin pulled low for sync.

Unfortunately, the circuit above suffers some image quality loss.

When a pixlel is off (hi-z), there is a bleed (slow turn off?).

 

For a 3rd attempt, I am allowing myself the use of a transistor (per pin) somehow.

This is fair game since I already have one to amplify sound, and it won't be required.

 

Perhaps some kind of 3 input NAND gate.

Sync (Red) only pulls lo if all 3 color bits are hi.

Somehow this also blocks output of color, as this would cause an image failure.

Such a scheme would loose one color, but to win, I could go from 8 colors to 7.

 

I am looking at other ideas as well.

Maybe there is some kind of ultra fast switching 4.4 zener that won't leave image gosting.

 

Brad

 

 

andrewm1973 wrote:

@brad - PB4 is an ADC pin.  You could modulate the voltage on that between 5v and some other high voltage that is well above the sync "low threshold" at the RC5 baseband rate and still get data at non-sync times.

 

You would go blind during sync.  But IR remotes transmit each button press over and over, so you should be able to get a good read in there somewhere.

 

Edit: Ignore what I said about going blind during sync and that being a problem.  I just looked up the VSync period on VGA - it is only 2 H_periods or 1/15000s period.  That is and order of magnitude less than a bit time in the manchester RC5 stream.

 

It should be trivial to put a 38Khz IR receiver module (GP1UX or something) shared with the Sync pin (PB4) and get the baseband manchester with the ADC.

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe there is some kind of ultra fast switching 4.4 zener that won't leave image gosting.

Maybe, but it isn't likely in my parts bin ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good point... this project has always promoted a single DIP Tiny85 and some common parts.

A common transistor would be fine. I guess the zener idea was a departure from the original goal.

 

I know there is a simple answer to this 3 state IO sharing...

 

Pin Z = Sync Hi / Color Lo

Pin Lo = Sync Lo / Color Lo

Pin Hi = Sync Hi / Color Hi

 

The fact that all color lines are 70-80 ohm terminated has been a plus to making this work on all monitors.

 

Here is what I have come up against so far in various attempts...

 

- Mixing sync and sound results in hearing the 60 Hz vsync frequency.

- Mixing sync with color results in either out of spec sync, or distortion in color.

 

I have not explored using a transistor for separation yet.

 

The ultimate goal would be to go back to separate Hsync and Vsync, shared with the 3 color pins.

This leaves B.5 for joystick (tv remote) input, and Timer1 for very good PWM sound.

 

I will continue my attempts to make this work.

A 2 transistor solution would be acceptable using 2N3904 or other common NPN.

 

Will report back as soon as I have a new attempt programmed and tested... pass of fail!

Brad

 

 

 

joeymorin wrote:

Maybe there is some kind of ultra fast switching 4.4 zener that won't leave image gosting.

Maybe, but it isn't likely in my parts bin ;-)

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Sun. Mar 11, 2018 - 03:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I just remembered this project I built a few years back...

 

https://www.avrfreaks.net/forum/atiny-liberation-self-replicating-boot-unloader

 

 

 

This unit gives the Tiny85 full use of ALL IO pins, and allows normal editing in AVR Studio.

No HV programmer required, just one extra Tiny85 and a 6 pin ISP header.

 

Since this is an extension to the ISP programmer, and not part of the Quark-85 circuit, it breaks no rules for single IC design.

 

I forgot about this Tiny Liberator until I seen in in my parts bin this afternoon.

 

Brad

 

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
Unfortunately, the circuit above suffers some image quality loss. When a pixlel is off (hi-z), there is a bleed (slow turn off?).  

 

You could try a fast diode in series with the Zener. An LED can be used as a low voltage zener too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting, never tried an LED as a Zener!

 

Ok, I tried several LEDs in place of the 1N4371 zeners I have on the pin sharing test board.

Red and Blue Leds are far worse, but the Green LED was slightly better than the zener.

Very cool, but the image is still not good enough for my standards.

Looks like sharing the RGB line in any way is always going to degrade the image.

 

I think the best plan is either my Quark-Loader or my currently unreleased Audio Boot Loader.

 

Brad

 

 

 

Who-me wrote:

AtomicZombie wrote:
Unfortunately, the circuit above suffers some image quality loss. When a pixlel is off (hi-z), there is a bleed (slow turn off?).  

 

You could try a fast diode in series with the Zener. An LED can be used as a low voltage zener too.

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like time is going to be extremely scarce for me starting tomorrow, so I have to turn the light off in my hacking lab for a while.

It was fun digging back into AVR over the last few days!

Hope to be back to look at this project again before winter.

 

Cheers,

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about this.  The fastest signal that can be on PB0 in normal operation is 8Mhz (5clks).

 

Size the AC coupling cap and the storage cap and resistor in the below envelope detector such that the transistor can only turn on when a 20Mhz signal is present.

 

When you want a sync program Timer0 to make a 20Mhz square wave. AFAIK a signal on the RGB lines will be ignored during the porch/sync.

 

Will just be a balancing act getting the values to turn on the BJT for 20Mhz and not for 8Mhz.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

That circuit idea is very interesting, I will beta test that sometime for sure, thanks!

 

For this project, I have finally made a decision on the final IO configuration and programming method.

Last night I found yet another unpublished project I did that called "The Tiny ReAnimator".

 

Instead of using the boot-loading method (which wastes precious bytes), this one zaps the fuses back to normal.

I know fuse resetting is common, but this project does have a few unique points (at least for me)...

 

- AVR ISP can remain plugged in, and works as normal. No pulling and reinserting the ATiny.

- Runs on 5v, and has built in charge pump (I see this was also done by someone else now).

 

The project basically disconnects the AVR ISP, does a quick HV fuse reset, and the reconnects the ISP, all very quickly.

It seems a logical build for anyone wanting to use any ATTiny to its fullest (like this project requires).

 

Brad

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andrewm1973 wrote:
AFAIK a signal on the RGB lines will be ignored during the porch/sync.

 

I think that is a bad assumption, as the smarter monitors auto-scale and auto-offset, and we have found pixels in flyback (of course) can confuse that process.

 

Not to mention a circuit this complex, has many more solder joints than a 14 pin package change - ie it is no longer the simplest design.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am going to breadboard my "Tiny ReAnimator" project and post it here.

This now addresses all of my IO pin problems, and opens up many new doors.

 

I can now post my much improved PWM sound routines, that even include ASD ramps.

There are 3 voices, each with various waveforms including white noise.

Each voice has several effects as well, such as mod, vibrato, portamento, etc

 

From this point on, all of my ATTiny work will allow using every PIN as full IO.

The limitations have been removed, and Quark-85 shall move up a level very soon!

 

This will be the new IO map...

 

B.0 > Color Red

B.1 > Color Green

B.2 > Color Blue

B.3 < Clock Input

B.4 > PWM Audio

B.5 > Composite Sync

 

Once I have that working, I will find a way to swap in the ADC during blanking as input.

I was able to do this on any of the color lines without distortion, since they are pulled low already

 

Brad

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Mon. Mar 12, 2018 - 08:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
I am going to breadboard my "Tiny ReAnimator" project and post it here.

 

Do you remember if you measured the actual HV threshold & and time-requirements ?

 

This has come up in another thread & spec is 12V +/- 0.5V, but actual threshold will be ~mid-way between VccMAX and 11.5V

A simple 5V charge doubler can get to 10V, (likely ok?), and I've run spice over a simple Inductor-flyback scheme that can do 12V, but only for short times. (~100us)

Last Edited: Mon. Mar 12, 2018 - 10:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Last time I messed with the project, 10v was enough, but 9v was not.

I thought 9v would be a nice way to use a simple battery, but it failed.

 

I also found that a simple reset of the AVR was as good as the doing the controlled VCC startup.

 

The main hurdle with my "Man in The Middle" HV fuse reset was the method to allow it to work in circuit with not only the AVR ISP in place, but also the project being made.

Quark-85 has some 75 ohm terminated IO (VGA color) as well as a pulled up IO (Sync), so you can't load up the IO with anything else.

 

I also did not yet test my theory that I could sneak in and do the HV reset right before Studio begins an upload, making the entire thing seamless.

If that isn't feasible, it only requires tapping a push button once before uploading from Studio.

 

I had the following goals for The ReAnimator Project...

 

1) Always remain in AVR Studio

2) Never have to touch the hardware

3) Full IO access to all Tiny pins

4) No bootloader (memory loss)

 

To make this work, I ended up with an inexpensive "lo tech" mechanical solution... small signal relays.

These are less than $2.00 each, and don't care about IO direction, and add no load.

Here is how I connected everything (from Atmega88 to ATTiny)...

 


////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// TINY RE-ANIMATOR SOURCE TO TARGET IO CONNECTIONS
////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// ATINY85		AVRISP 	    	ATMEGA88	RELAY.NC        RELAY.NO
////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// P1 / B.5 / RST	P5 / RST	12V SOURCE	ISP RST		12 VDC
////////// P2 / B.3 / CLK	----------	P26 / C.3	EXT CLK		PINC.3
////////// P3 / B.4 / OC1B	----------	----------	--------	-------
////////// P4 / --- / GND	----------	----------	--------	-------
////////// P5 / B.0 / MOSI	P4 / MOSI	P23 / C.0	ISP MOSI	PINC.0
////////// P6 / B.1 / MISO	P1 / MISO	P24 / C.1	ISP MISO	PINC.1
////////// P7 / B.2 / SCK	P3 / SCK	P25 / C.2	ISP SCK		PINC.2
////////// P8 / --- / VCC	----------	P27 / C.4	VCC 5V		PINC.4
////////////////////////////////////////////////////////////////////////////////////////////////////////

 

I will show this build in detail as I finally put it together properly.

Hope to get a few hours on Sunday to hack away.

 

Brad

 

 

Who-me wrote:

AtomicZombie wrote:
I am going to breadboard my "Tiny ReAnimator" project and post it here.

 

Do you remember if you measured the actual HV threshold & and time-requirements ?

 

This has come up in another thread & spec is 12V +/- 0.5V, but actual threshold will be ~mid-way between VccMAX and 11.5V

A simple 5V charge doubler can get to 10V, (likely ok?), and I've run spice over a simple Inductor-flyback scheme that can do 12V, but only for short times. (~100us)

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Tue. Mar 13, 2018 - 12:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Here is the schematic for my Tiny ReAnimator...

 

This just lives between the AVR ISP plug and the target.

The clock is also on the target side.

 

The three DPDT relays allow everything to work like an ISP.

Having to pull the Tiny to program it was unacceptable to me.

 

Operation is simple... press the button before uploading in AVR Studio.

The result is being able to use every IO pin in a Tiny for input or output.

 

I am going to make a hand wired PCB and show this working soon.

 

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Tue. Mar 13, 2018 - 06:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool!

AtomicZombie wrote:
I am going to make a hand wired PCB and show this working soon.
In its own thread?

Reasons : visibility and to match what you created in

ATiny Liberation!... Self Replicating Boot Unloader.
https://www.avrfreaks.net/forum/atiny-liberation-self-replicating-boot-unloader

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like a plan, I will open a separate thread once the ReAnimator is living on its own board.

 

I updated the schematic a bit to show what wires actually go between the target and the ReAnimator...