Quark-85 Demo Kube - 184 x 240 VGA with 8 Colors and Sound on an Tiny85!!

Go To Last Post
438 posts / 0 new

Pages

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

Ok, I did the same test with an ATMega328, and all but 1 out of 4 would run by extensive tests at 42MHz for an hour.

I am going to drop the clock back to a "safe" 36MHz, and say that the 328 can overclock just as well as the ATTiny.

 

Since I have a 328, I am going to port my Driver there, and see what 256 colors looks like at 184x240.

I might even divide the Vertical by 3, and just run it at 184x160 for a more "normal" aspect ratio.

In the game I started, using square Sprites makes them look way to wide.

 

It will still be cool to see a 28 Pin DIP AVR spewing out 184x160 VGA with 256 colors + stereo sound with no extra hardware.

Ok, I will let the 328 cook for the rest of night at 36MHz while I go back to cooking my own hardware with my pal Jose Cuervo.

 

Holiday Greets to all!

Brad

 

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

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

AtomicZombie wrote:
I am now going to port my new VGA Driver from Quark-85 into this one and make some adjustments.

Having 20 IO Pins means 256 colors with a possible resolution of 200x240!

Stereo sound and a 5 switch joystick as well.

 

If I like what I see, I may let this project "grow" a little, and call it Quark-88.

I just can't handle the idea of an ATiny and a transistor.... ack!

I won't argue with progress ;-)

 

It would be nice to see Quark-85 mature and released, if only to enjoy the sound of crickets when you post it on Hackaday...  Hey!  That can be the first demo!

 

If moving towards sync-on-whatever was originally motivated by unsatisfactory results when multiplexing sound and video onto one of the pins, there may yet be an answer to that.  Probably not forthcoming from me, though... I feel decidedly behind the curve in this thread!

"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."

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

 

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

AtomicZombie wrote:

I dropped an ATMega88P on a breadboard, and shoved in a 40MHz clock.

No issues, my SRAM and IO has run since this afternoon, checking ever location.

 

You can check margins, by slowly lowering Vcc. until  problems appear, and running above 5V gives a bit more speed.

Also try some ATMega88PB / ATMega328PB, which I think are a die revision.

 

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

Interesting, I will have to try it back at 40MHz with 6v and see what transpires.

On XMega, I found 64Mhz to be absolutely safe, but over-volted to 5V, they ran up into 75MHz.

Never any heat, not even a detectable amount on the chip surface.

 

Will report back what the 328 does with 6v.

 

Brad

 

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

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

I would avoid going above AbsMax ratings, but certainly 5.5V will buy margin and if you drop the Vcc, you can get an idea of just how close you are to the limits. (ie how much Temperature margin you may have)

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

One could fear that the megas weakest point are multiplier are that a part of your tests?

 

I would not fear that anything bad happens with a 5V AVR at 6V (don't use it in a real design). But to run stable the power need to be clean, and only small loads on the IO's (and only small load changes).

So for the video generation you need to have a low capacitive load on the lines.

 

Some old rules for RAM chips:

10% faster at the highest legal voltage compared to the lowest.

10% for low temp compared to high

10% low load on IO's compared to high.

 

 

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

Ok, here is what I have come up with...

 

ATmega-328 can do just above 40MHz, but ATMega-88 can to 45MHz.

So, like the ATTiny, I will just continue to use 36MHz to be "safe".

I am only running at 5v, to keep my parts simple.

 

Yes, my "OverClock" test routine, exercises every single instruction, and every byte of SRAM and program memory.

The only thing not tested is EEPROM, as I already know that does not play well at breakneck speed.

 

As for my Video Engine, it has migrated very nicely to the ATMega-328, and I now have a new project called Quark-328.

I will continue with the Tiny version, but make onto a Demo platform and drop the joystick.

I will keep working on improving the pin sharing sound output at a later date.

 

On the new one, Quark-328, I have it doing the following...

 

- 184 x 160 VGA with 64 colors. (I divided the 480 horizontal by 3 this time for a better aspect ratio).

- 2 channel stereo sound, which will soon include complex waveforms and envelope generation (C64 Style).

- C64 / Atari compatible joystick port.

 

The Video Engine is almost identical, so the guy on Hackaday will still claim it is impossible (this is good).

I can also bitmap the entire screen at 64 colors, and then lay sprites over top! Impossible with 2K of SRAM?.. nope!

One might say, that would require almost 30K of SRAM and a lot more horsepower, but Quark is doing it. proof to follow.

 

Having 32k of Flash, and 2K of SRAM means that more elaborate games can be made!

 

As for the 64 colors, due to the way Atmel layed out the ports, you cannot use all 8 bits of any port if you have an external clock, or want PWM!

That's ok, 64 colors is plenty, and the palette divides nicely into RR-GG-BB.

 

I will have a simple Demo soon, but will start a new thread called Quark-328.

 

Cheers!

Brad

 

 

 

 

 

 

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

Last Edited: Mon. Dec 28, 2015 - 03:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sweet.

 

I must admit I look forward more to Quark-85 than I do to Quark-328.  Many of the things you mention above have been done already (e.g. LFT's Craft), and the really mind-bending part of Q-85 (for me) is the pin sharing.  Not just the A/V multiplexing, but the use of ADC0 without RSTDISBL.  I understand how each of these works, and there is no 'magic', but the cumulative effect of all of these techniques on an 8-bit/pin/KB device is what blows the mind ;-)

 

Looking forward to all of it.

 

Enjoy the Jose Cuervo!

"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."

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

 

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

joeymorin wrote:

Sweet.

 

I must admit I look forward more to Quark-85 than I do to Quark-328.  Many of the things you mention above have been done already (e.g. LFT's Craft), and the really mind-bending part of Q-85 (for me) is the pin sharing.  Not just the A/V multiplexing, but the use of ADC0 without RSTDISBL.  I understand how each of these works, and there is no 'magic', but the cumulative effect of all of these techniques on an 8-bit/pin/KB device is what blows the mind ;-)

 

Looking forward to all of it.

 

Enjoy the Jose Cuervo!

 

Yeah, the more from less factor is higher on the Tiny version for sure.

But the real magic is actually something that ole' Jack pointed out when he called this project fake.

The fact that there is not enough memory to swing out a full screen of color pixels at that resolution if trying to bitmap. (My old version).

Nor is there nearly enough time after the active line to try to chase the beam and fill a line buffer. (LFT Craft / VCS Style).

In the amazing work of art "Craft", Linus does all the FX on the fly, so something like a screen full of Sprites would be impossible.

 

Think in Jack's terms of impossibility. Looking at the timing for the Interrupt...

 

// [36 MHZ HORIZONTAL CLOCK TIMING FOR VGA @ 640 X 480]
// HSP : 135 FROM 0000 TO 0134
// HBP : 067 FROM 0135 TO 0201
// HPX : 920 FROM 0202 TO 1121
// HFP : 022 FROM 1122 TO 1143
// TOT : 1144

The only "free time" available is before the Horizontal Pixel Rendering segment (HPX).

Take away thee Sync Logic, and housekeeping, and that leaves at best 100 Cycles.

Now stuff in a Dual Channel Sound routines and Joystick control, and what would that leave for time?

Imagine having perhaps 20 free Cycles, and in that time, you must jam 184 full bytes worth of data to a buffer!

Even if it somehow came from SRAM, this would be at least 4 cycles per byte, or 736 required cycles!

 

To Jack's credit, his math did prove that this would be impossible if one approached the task from a "normal" standpoint.

 

I am indeed doing something completely unique in this driver!

It can bitmap the entire screen, and overlay several sprites with included alpha pixels.

 

For me, this is the magic in the Quark Driver, and look forward to revealing what is behind the curtain soon enough!

Moving it up to 64 colors and with proper sound (no 60Hz buzz) was worth it.

Perhaps one day, I will find a way to clean the sound up in the little guy as well!

 

Ok, next post will be in a new thread.

I have a giant 64x64 Amiga Boing Ball spinning over a 64 color bitmap to show soon.

The new demo will include music playing as well.

 

Brad

 

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

Last Edited: Mon. Dec 28, 2015 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

ATmega-328 can do just above 40MHz, but ATMega-88 can to 45MHz.

Makes sense, as all else equal, a larger memory array is a little slower than a smaller one.

 

AtomicZombie wrote:

I am only running at 5v, to keep my parts simple.

With something like a 7805,  you can add a small resistor to the centre leg, to elevate the Vo fractions of 1v

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

Quark now comes in to versions... Quark-85 (this one), and Quark-328.

Since I recently messed up my only 328, I am back on this one for a while.

It's more fun to bounce back and forth on projects, anyhow.

 

I made some nice improvements on the overall code the last time I worked on it.

Many shaved cycles in the Driver, and now only using a single Timer.

Instead of using my de-Jitter code, I have a routine in the Driver that knows when the Main Loop is done.

Once the end of User Code is detected, the Driver puts the system to sleep until the next Interrupt.

This is working perfectly, and I may try using the other timer for PWM sound.

 

Video has also been improved, and is now putting out 204x240 with 8 colors.

I tried 204x160 for a more "standard" aspect (using this on the other one), but it costs too many cycles to divide the line.

This is just an ATTiny with 8K of Flash, so I am going to keep it simple.

Claiming 204x240 VGA out of an ATTiny is also part of the cool factor!

 

So now the only unsolved mystery is how to get decent Sound out of one of the used 4 IO Pins.

What I had in the schematics shown above worked "ok", but suffered low volume level and buzzing.

Depending on the pattern of colors on the screen, the audio would sometimes buzz with certain frequencies.

 

I am thinking that I could free up a PWM Pin for sound if I can get one of the Color Pins to combine with the Sync Pin.

By exploiting Hi,Lo, and Z states, it should be possible using perhaps a Zener.

 

The Color Lines on the monitor are pulled low by an internal 75Ohm resistor, so the color Pin only needs to drive.

I am trying to figure a way to pull Sync up slightly so that I can use the following Pin states...

 

Lo - Drive Sync Low (Sync On / Color Off).

HI - Drive Color Hi (Color On / Sync Off).

Z - Default state (Color off / Sync Off).

 

A transistor could probably swing this, but I really want a passive solution.

The total part count for this one is now only 4 Resistors and 1 Capacitor!

Will be trying with a Zener when I can find one, and perhaps exploiting the Pin pullups somehow as well.

 

The Video looks so damn good at 204x240 with 8 Colors, that I just can't sacrifice a bit and go back to 4 Colors.

But on the flip side, what is a Demo without music???!

 

Cheers!

Brad

 

 

 

 

 

 

 

 

 

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

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

Brad this project is absolutely fantastic, I love the three state multiplex layout. There is so much here that's motivated me to learn and practice and elevate my own meager skills a bit, I simply must thank you for that. 

 

I also love the idea of getting the most out of the tiny chips and while I have yet to extract anywhere near the nectar as you it is indeed fun to play. I was thinking that a bootloader like bluebie's micronucleus  https://github.com/micronucleus might solve your extra I/O pin problem. It might also be a possibility to simplify the bootloader by dropping USB and using serial, just guessing.

In any case I have been using the reset pin for some I/O with this bootloader and at least thought I should mention it.

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

Hi Brad!

 

AtomicZombie wrote:

I made some nice improvements on the overall code the last time I worked on it.

Many shaved cycles in the Driver, and now only using a single Timer.

Once the end of User Code is detected, the Driver puts the system to sleep until the next Interrupt.

 

 

Very nice, personally the attiny85 is more interesting for me than the mega version ;) I've been also playing with attiny5 and VGA lately and this is actually the solution I use with it as it only has single timer :)

 

AtomicZombie wrote:

I am thinking that I could free up a PWM Pin for sound if I can get one of the Color Pins to combine with the Sync Pin.

By exploiting Hi,Lo, and Z states, it should be possible using perhaps a Zener.

 

The Color Lines on the monitor are pulled low by an internal 75Ohm resistor, so the color Pin only needs to drive.

I am trying to figure a way to pull Sync up slightly so that I can use the following Pin states...

 

Lo - Drive Sync Low (Sync On / Color Off).

HI - Drive Color Hi (Color On / Sync Off).

Z - Default state (Color off / Sync Off).

 

A transistor could probably swing this, but I really want a passive solution.

The total part count for this one is now only 4 Resistors and 1 Capacitor!

Will be trying with a Zener when I can find one, and perhaps exploiting the Pin pullups somehow as well.

 

Cheers!

Brad

 

 

Ohh, I also thought about getting one color and sync pulses out of single pin, but to be honest, I still haven't gotten any good results. I'm even willing to try up transistor, if it helps, but as I said I'm n00b with electronics still :D

 

Cheers,

 

//Jartza
Jari Tulilahti

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

I also thought I should point out the nice HVSP fuse reset arduino project I use to reset the fuses on tinys with RSTDISBL set.

 

https://sites.google.com/site/wa...

 

With this simple 6 resistor single transistor + arduino solution you can use reset pin as I/O without any concern.

 

I'm a certified 6581 chip tune lover so I also want you to have audio that reflects the amazing accomplishments you are achieving in this device. in any case I hope there are some sparks in these interesting projects that can help you reach your final goals. Put another way, anything I can do to get a good look at that source ;)

 

Brian

Last Edited: Tue. Jan 5, 2016 - 07:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the comments and ideas!

 

I did look at the USB bootloaders, but since I am using one Pin for the clock input, moving away from the simplicity of AVRStudio + AVRISP was not worth gaining the reset pin, which is still able to work as an input.

I do have another project that will make use of this, and did start an assembly only USB Tiny bootloader that I will detail one day. It is much smaller than the ones posted around the web, which are 2k or more.

 

After some zener experimenting, I managed to get the sound / RGB sharing to work a "bit" better, but know for sure now that the way to go will be to dedicate a pin for sound only, and then try to share sync with one of the RGB Pins. No matter what scheme I try, there is always noise on the sound output due to the voltage changes of the RGB lines. If I share sound with Blue, and only have a blue screen, then it's decent, but if the shared Pin is actively changing colors, then this is interpreted as sound as there is always a small amount of leakage.

 

By sharing Sync with Color, there will be no noticeable effects from a small "error window".

As long as Sync is held above 2.5v during its "off" state, all monitors are happy.

RGB cannot be sent at any other time than during the active line though, or older monitors complain.

 

I have a few more tricks to try, but will resort to a transistor if needed, as this project has come so far, and MUST have sound!

 

Had the chance to test the output on a bunch of monitors at work, and have not found any monitor (new or old) that does not work perfectly.

I was originally worried that some monitors may not like composite sync, but not one of the 20+ I tested had an issue.

So although some monitors don't even list "composite" sync as a feature, I am convinced that HS and VS are simply mixed this way internally.

 

Will report back when my project is banging out some retro music to accompany that rotating ball!

 

Cheers,

Brad

 

 

 

 

 

 

 

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

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

AtomicZombie wrote:

By sharing Sync with Color, there will be no noticeable effects from a small "error window".

As long as Sync is held above 2.5v during its "off" state, all monitors are happy.

RGB cannot be sent at any other time than during the active line though, or older monitors complain.

 

I have a few more tricks to try, but will resort to a transistor if needed, as this project has come so far, and MUST have sound!

 

Had the chance to test the output on a bunch of monitors at work, and have not found any monitor (new or old) that does not work perfectly.

I was originally worried that some monitors may not like composite sync, but not one of the 20+ I tested had an issue.

So although some monitors don't even list "composite" sync as a feature, I am convinced that HS and VS are simply mixed this way internally.

 

Will report back when my project is banging out some retro music to accompany that rotating ball!

 

Cheers,

Brad

 

Hi Brad!

 

Yeah, I would definately want to try the pin sharing between sync and color, but with my diode testing I couldn't get my monitor to sync, I need to check with oscilloscope how the signal looks like - my problem being that I only have limited collection of diodes (1n4148, 3.3V and 5.1V zeners and then some very generic ones). 

 

I've been playing with Attiny5 now just for the kicks (you know, this 6-pin sot23-6 chip, 32 bytes of ram and 512 bytes of flash) and this is what my basic engine now does (with 3 pins): 

 

https://www.youtube.com/watch?v=...

 

Getting the 3rd color bit would be amazing :)

 

Cheers,

//Jartza
Jari Tulilahti

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

Crazy thought of the day....

 

Instead of the typical USB bootloader, why don't I write a custom bootloader that makes the AVRISP think it is connected to a PDI device?

 

Why do this?....

 

Because after the AVRISP programs the ATTiny, I can then recapture the reset pin.

In other words, I would be fixing Atmel's "hardware gotcha" with a software only solution.

 

Please tell me why this can't possibly work before I convince myself that it might!!

 

 

Whoever came up with a programming method that snuffs out 1/6th of the usable pins on a 6 pin device should be skewered!

How difficult would it have been to work around this massive limitation with an extra 2 hours of forward thinking in the design phase???!

ATTiny is REALLY a 5 Pin chip, not a 6 Pin chip because of this. If you need a clock, it's a 4 Pin chip, and only a 3 pin if you use an XTal!

 

 

Ps... nice work on your project, Jartza!

 

 

Brad

 

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

Last Edited: Tue. Jan 5, 2016 - 05:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

Crazy thought of the day....

 

Instead of the typical USB bootloader, why don't I write a custom bootloader that makes the AVRISP think it is connected to a PDI device?

 

Why do this?....

 

Because after the AVRISP programs the ATTiny, I can then recapture the reset pin.

In other words, I would be fixing Atmel's "hardware gotcha" with a software only solution.

 

Please tell me why this can't possibly work before I convince myself that it might!!

 

 

Whoever came up with a programming method that snuffs out 1/6th of the usable pins on a 6 pin device should be skewered!

How difficult would it have been to work around this massive limitation with an extra 2 hours of forward thinking in the design phase???!

ATTiny is REALLY a 5 Pin chip, not a 6 Pin chip because of this. If you need a clock, it's a 4 Pin chip, and only a 3 pin if you use an XTal!

 

 

Ps... nice work on your project, Jartza!

 

 

Brad

 

 

Hi Brad! 

 

And thanks :) The OctaPentaVeega is mostly done now, all there is missing is the blog post - that's why I moved on to smaller chip :)

 

You know what. I've been thinking exactly the same that why can't TPI work on bigger tinys too? Except TPI has also "high voltage" programming mode, where reset is kept at 12V during programming, but honestly, that reset could be simulated with software by using other pin than reset. I've been thinking something similar, but instead I actually made bootloader that works with audio and single pin - just play MP3 to your AVR and it can update the firmware :D

 

Not sure if you've seen this post somewhere here, but anyway:

 

http://labs.rakettitiede.com/12k...

 

Anyhow, still fighting getting single pin shared for one color and sync, maybe I should try out the transistor?

 

Cheers,

 

//Jartza
Jari Tulilahti

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

Cool... we did many of the same hacks!
On my Logic based game, I tested an audio to Flash system, using one channel as clock, and the other as data.

It work ok, actually.

Even tried the "hold it to the screen" idea with a pair of photo transistors, but like you found out.... it's brutally slow!

 

PDI is easier to use and needs less pins than TPI, that's why I was thinking I could just trick my AVRISP to see the ATTiny as an XMega.

Once AVRISP thinks all is well, just feed it the ATTiny HEX file, and let the bootloader sort it all out!

 

Yes, you can share sync and color with a 2N3904 or similar transistor.

I will post a schematic of this soon, as it looks like this is my fallback mode.

 

I may also try a "Tiny Cartridge", using a 2 wire SPI flash to load the ATTiny.

Might even be able to keep it "live" after, knowing that no RGB Pin is ever high while Sync is low (free usable state)!

 

Brad

 

 

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

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

AtomicZombie wrote:

Instead of the typical USB bootloader, why don't I write a custom bootloader that makes the AVRISP think it is connected to a PDI device?

 

Why do this?....

 

Because after the AVRISP programs the ATTiny, I can then recapture the reset pin.

In other words, I would be fixing Atmel's "hardware gotcha" with a software only solution.

 

Please tell me why this can't possibly work before I convince myself that it might!!

 

The reason RESET is a key pivot on Programming, is you need to have a known starting point.

It's probably easier to use a device like ST662A, that can deliver 12V for HV over-ride ?

 

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

Who-me wrote:

The reason RESET is a key pivot on Programming, is you need to have a known starting point.

It's probably easier to use a device like ST662A, that can deliver 12V for HV over-ride ?

 

 

Hi,

 

Of course, but if you write your own bootloader, you can actually just "simulate" that reset with some other pin which might as well be the disabled reset pin ;)

 

Cheers,

//Jartza
Jari Tulilahti

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

AtomicZombie wrote:

Cool... we did many of the same hacks!
On my Logic based game, I tested an audio to Flash system, using one channel as clock, and the other as data.

It work ok, actually.

Even tried the "hold it to the screen" idea with a pair of photo transistors, but like you found out.... it's brutally slow!

 

Hah, very cool! I've also done UART over audio, but that protocol I implemented (the article I linked previous) has the nifty thing of needing only single pin and it synchronizes itself to the receiver clock because of the sync pulses and the speed is very adjustable (basically between 4-12 kbps) and auto-adapting. The coolest part in my opinion is that it also works over FM radio.

 

AtomicZombie wrote:

Yes, you can share sync and color with a 2N3904 or similar transistor.

I will post a schematic of this soon, as it looks like this is my fallback mode.

 

Brad

 

That would be very cool and useful and another learning experience for me (like this whole project of yours has been :)

 

Cheers,

 

//Jartza
Jari Tulilahti

Last Edited: Tue. Jan 5, 2016 - 09:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In one last attempt from the "passive only" drawing board, it seems as though I have working sound!

 

It's rather complex (in code), but here is the short version...

 

- Sync is now running in 3 states - HSync On = Pin Lo / HSync Off = Pin Z / VSync On = Pin Hi/Lo

- Since no color is ever send during HSync, I pulse it there, and a diode basically connects the two.

- The resulting pulse of small current is fed through a 100k resistor to ground, and out to the amp.

 

The sound appears clean this time, but I am only using a Piezo, directly driven by the output.

Kind of cool to have sound with no amp, so I may even include the Piezo in the final design... one less jack!

 

I will need to do more tests on this when I am home, but it's looking promising.

 

Brad

 

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

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

Jartza wrote:

Of course, but if you write your own bootloader, you can actually just "simulate" that reset with some other pin which might as well be the disabled reset pin ;)

Notice the word 'simulated' there - you assume that your code is running 'as expected'.

Something a little more concrete is needed, for production programming and updates.

That is why the HV mode exists.

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

Who-me wrote:

Notice the word 'simulated' there - you assume that your code is running 'as expected'.

Something a little more concrete is needed, for production programming and updates.

That is why the HV mode exists.

 

Hi, sure I understand the need for HV programming if everything goes haywire and it's true with any bootloader, if it doesn't work as expected then you need to look into more powerful methods.

 

The point here was disabling the reset and still being able to program the attiny85 without HV-programmer, if I understood correctly.

 

Cheers,

//Jartza
Jari Tulilahti

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

AtomicZombie wrote:

Yes, you can share sync and color with a 2N3904 or similar transistor.

I will post a schematic of this soon, as it looks like this is my fallback mode.

 

Brad

 

Oops.... whaddayaknow! https://www.youtube.com/watch?v=... :)

 

Cheers,

 

 

//Jartza
Jari Tulilahti

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

Jartza wrote:

The point here was disabling the reset and still being able to program the attiny85 without HV-programmer, if I understood correctly.

Yes, tho not so much 'the point' as 'the hope' - Atmel cannot ship chips based on hope.

The point is that is why they provide HV mode. Hobbyists can use hope, but even have have limited patience.

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

OK, I hooked up the unit in my lab, and tried to connect the output junction where the Piezo is picking up sound to the speaker input instead.... nothing!

It appears that the sound is being generated DUE to the effects of the Piezo.

I know these things work like capacitors, so it seems that there is a charging and shorting effect through the 1 meg resistor.

Funny... the sound is crisp, clean, and loud enough to be decent, using the dime sized Piezo element!

 

I will see what passive component can take its place. So far a .01uF cap has not worked.

Worst case scenario... Quark-84 has built in sound with no amplifier necessary!

It does lack the "thumping" of the low frequencies though.

 

Oh well, at least I have sound now...

ATTiny-85 doing 8 color VGA at 204x160 with stereo sound!

 

Brad

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

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

Last night, while I was trying to sleep (best time for new ideas), I thought of a way to solve the lost IO Pin issue on the ATTiny.

 

This soon to be tested solution would offer the following...

 

- Programming any ATTiny using AVRISP and Atmel Studio.

- Ability to use all IO Pins without restrictions (including the reset Pin).

- No bulky bootloader code needed on the target device.

- Rapid turnaround from compile to chip programming.

- No wonky software like arduino or usb drivers needed.

- No freakin' command line garbage or unix jargon.

 

In other words, if you own an AVRISP and like working in Atmel Studio, that's all that is required.

This will free up the restricted Reset Pin for use as a sound output.

 

I will post results as soon as I have time to test this out.

 

Cheers!

Brad

 

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

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

Preliminary testing shows that my "Quark Loader" idea should work.

The goal is to be able to blow the reset fuse on an ATTiny and still use ONLY an AVRISP and Studio to program the part.

To me, this is a HUGE deal, as it increases the IO on the ATTiny from 4 to 5 Pins.

 

I hit a roadblock with AS7 again though! It is now unable to change decices and screaming that it can't fing the GCC toolchain!

Ack!... I spend more time fussing with AS7 than I do coding.

 

Brad

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

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

Are you using assembler only? If so you could experiment with an Atmel Assembler project/solution in AS7 and see if it fits your needs, so far so good here.

 

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

Your work has inspired a desire to start learning assembly language for the avr. 

Im am currently counting clocks in the AS7 simulator with C' compiled code

in hopes to get a usable serial terminal monitor using ntsc into an old tv. Vertical and Horizontal are syncing fine

but i now understand that there is probably timing jitter even though for my application this may be acceptable. 

~William

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

vertamps wrote:

Your work has inspired a desire to start learning assembly language for the avr. 

Im am currently counting clocks in the AS7 simulator with C' compiled code

in hopes to get a usable serial terminal monitor using ntsc into an old tv. Vertical and Horizontal are syncing fine

but i now understand that there is probably timing jitter even though for my application this may be acceptable. 

 

Thanks, glad to have planted a spark!

 

I often mix C and Assembly these days, and GCC - GAS is definitely way way to go.

Even this ATTiny project can be coded in C (the main loop) thanks to the easy integration of C and ASM.

 

At 28.636MHz, which is doable on just about any AVR, you can even bit bang the chroma signal.

A tight loop, adjusting the phase of a PWM (CLK/8) pin can manage 4 base colors.

Set a port with a DAC at the start of the line, and you can have as many shades of each color as you like.

XMega can pump out 16 colors & 16 shades of NTSC doing this, for 256 colors.

 

I highly recommend you experiment with mixing C and Assembly (not inline).

Learn some Assembly, and then the Application Gateway rules, and you are all set...

... save regs r2-r17 & r28,r29, and set r1 to zero and that's all there is to it!

 

Don't let anyone convince you that the C compiler will probably do better than you, this is banal!

Even in my early days, I could kick the compiler's ass every time without much effort.

Once you get your Video Core in assembly, you will unleash the true power of the Dark Side!

 

Brad

 

 

 

 

 

 

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

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

Let me tell you I'm amazed by what you guys are achieving with the Tiny85. When I go back to my blinking leds and LCDs, I have the feeling it's not the same IC :-)

 

Anyway, FWIW, I recently had to find the smallest font possible and I came across a full ASCII character set in 4x6 (3x5 usable) pixels.

It's surprising the human eye can tell apart the characters M - H - N - W in a 3-pixel wide matrix but it works.

 

Font and details here : http://robey.lag.net/2010/01/23/...

 

Best regards,

 

Vicne

Last Edited: Sat. Jan 9, 2016 - 04:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!

The people who make the AVR hardware deserve all the credit though!

Nothing wrong with blinking LEDs... an LCD monitor is just a panel 3,686,400 blinking LEDs, it just takes a bit more timing!

 

That font is great, thanks for sharing. I will give it a whirl and post the results soon.

Being 4 pixels wide, that will give Quark-85 a 46 column display.

Right now, I am getting 30 columns with my 5x5 font.

 

I never did show any text yet, so here is a quick video...

 

https://youtu.be/miefLPwZgOg

 

This quick demo tests a few things in the Video Engine...

 

- Alpha Channels (notice 3 layers of graphics).

- Sinewave generator (optional Routine).

- Text Generator (optional Routine).

 

Alpha Pixels are pixels that are not rendered, which is how the Ball seems to be under the text, yet over the rainbow.

This is how Sprites can overlap without ugly square edges. Quark-85 takes care of all of this in real-time.

Text is just another Sprite really, so it can be any color and size, even multi-color per character.

 

Tomorrow I am putting the new "Quark Loader" to the test, and this has me all hyped up!

I am 90% sure that this will work, allowing the locked out reset Pin to function as a full IO Pin.

This means I will be able to program the ATTiny right from AS7 using only an AVRISP, yet get all 6 pins as IO.

From my searching, I don't think this has been done yet, so that is also adding to the cool factor.

 

Later!

Brad

 

 

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

Last Edited: Sat. Jan 9, 2016 - 10:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a small side question.

This is coming up because of an other tiny85 thread.

 

Which version of tiny85 do you use (the letter at the under side A,B,B1,B2,C perhaps more) ?

 

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

The Atomic Zombie generally uses whatever part you think could not possibly do the job. This part then does the job well.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

On the 2 I have running now, they are marked "B".

I will check the others when I have the chance.

 

Brad

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

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

Brad, can you post the top- and bottom-side text verbatim?

Relevant thread:

https://www.avrfreaks.net/forum/difference-between-1323-and-1404-variants-attiny85

(perhaps start at post #8)

"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."

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

 

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

Hi Brad,

 

This project was one of the reason me to continue on some of my projects.

Really cool.

 

So for your reset pin idea:

Am I right that you are writing some kind of "self-flashing" code that handles the pins as your AVRISP is using them?

 

Ciao,

  Uli

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

Thanks!

 

I don't want to spill the beans on "Quark-Loader" just yet, as I am so close to making it work!

This is going to be a huge deal for me... one more IO pin.

 

What I will offer is this...

 

All that is needed is an AVRISP-II and AVR Studio (any version).

There is no other software needed, and coding is done as usual... code, compile, flash.

The target ATTiny will have all IO pins available though.... this is the magic!

A little black "magic plug" fits between the AVRISP port and the breadboard, that's all!

 

I wouldn't call this a "boot-loader" though, as it does not require any in-between external software.

No bizzare linix command line jargon, no unpronounceable-duino stuff, no 1980's serial crap, just AVRISP and Studio!

I will show a video when I have it all working the way I want. It's 90% ready.

 

Funny, Quark-Loader was simply a response to a lack of IO, but I think it may be a great stand-alone project.

It will also work on all ATTiny versions.

 

Cheers!

Brad

 

tinybear wrote:

Hi Brad,

 

This project was one of the reason me to continue on some of my projects.

Really cool.

 

So for your reset pin idea:

Am I right that you are writing some kind of "self-flashing" code that handles the pins as your AVRISP is using them?

 

Ciao,

  Uli

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

Last Edited: Tue. Jan 12, 2016 - 10:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was just guessing and thought how I would do it if I had to:

 

The reset pin can be IO when the code is able to handle the pull down

as expected. Cool would be if the code could set the fuse to enable the

reset pin again, but that is not possible, as far as I know.

 

So then just stop other pins doing their normal things: configure the

USI to be used and wait for the commands to arrive.

Hmm, But this interpreter will need flash and might be large, so even

if this might work, you would loose too much I expect.

So my second guess:

As you talk about a magic plug, I think it could be a second chip,

doing the things as I wrote before, handling the "complex" things

of the protocol and forwarding the things to the device to be

programmed, with a real dump loader programmed there.

 

Hmm... Third guess: Nothing in the final chip:

The magic plug is using a charge pump to create 12V, so a few steps

and it can reset the fuse as required. Then you don't need a boot loader

in your device and you can execute the programming almost as normal.

(Edit: Of course there is still an interpreter running on a chip in the magic

plug to forward the things to the final chip)

That sounds good, but then: This can't be your way, if you are right with "all attiny".

As I understand, I need "parallel programming" for some chips: Not something

I want to connect on a bread board.

I expect I'm not the only one waiting how you did it.

 

PS:

I don't use "AVRISP and Studio" (yet at least, never say never).

Don't you agree sometimes the "1980's serial crap" is just fine?

There are more serial terminals today than ever. Almost every silly

router has one internally.

But it always depends what you have on your desk and what you

want to achieve.

 

 

 

Last Edited: Tue. Jan 12, 2016 - 11:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some good guesses / ideas in there!

 

I actually tried the charge pump driven HV thing, and it did kind of work. I was going to have it "spy" on the AVRISP output, and "rescue" the fuse right before programming, but later realized that this scheme would require complex hardware as the VCC pin is also controlled. At one point, I actually had it "almost working", but then came up with the idea I am using now, which is much "sneakier", and requires simple hardware.

 

In my scheme, a programmer would not even be aware that anything was being "hacked".

In Studio, it looks just like an ATTiny85 being programmed, and everything works as normal.

The device is selected as ATTiny85p, and the AVRISP programmer does its normal job, writing the Flash memory.

 

The key point in Quark-Loader is that it does not require a "software wedge" to stream the HEX/ELF file to the target.

All programming / debugging is done right in Studio, and using only the standard ISP like AVRISP or one of the clones.

 

I am trying to solve one last issue in my code, and will then post some details.

 

Brad

 

 

 

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

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

Progress... Quark-Loader now works!

Had to switch back to AVRASM over GCC-GAS to get the control I needed.

 

I will start a new thread detailing this sub-project soon, as others may want to free that pesky Reset Pin.

 

Here is a hint on what I did to make this one fly...

 

call it a.... "Self Replicating Boot Unloader"!

 

Thanks to everyone for always offering great advice.

I know that I ask for crazy things, and am eccentric.

 

Ps...

Can I edit the title of this thread without breaking the internet?

Now that it is pushing 184x240, it would be nice to change it.

 

Cheers!

Brad

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

Last Edited: Wed. Jan 13, 2016 - 04:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can I edit the title of this thread without breaking the internet?

Now that it is pushing 184x240, it would be nice to change it.

Just change #1 there you can change the title. 

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

sparrow2 wrote:

Can I edit the title of this thread without breaking the internet?

Now that it is pushing 184x240, it would be nice to change it.

Just change #1 there you can change the title. 

 

Thanks, but will it break links to this thread?

Hackaday had it linked and a few other sites.

 

Brad

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

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

I tried to rename one of my threads, and the addr. change so I guess it's a problem.

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

I tried to rename one of my threads, and the addr. change so I guess it's a problem.

The address changes, yes, but I believe the old address will still work.  IIRC, Michael mentioned this somewhere in the Site Feedback forum.

"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."

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

 

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

Well, let's see what happens!

... yep, external links are still good.

 

Brad

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

Last Edited: Wed. Jan 13, 2016 - 06:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I solved my extra IO Pin problem, and can now continue on development of this project.

I made something I call "Self Replicating Boot UnLoader", and can now use the tools I like to move forward.

 

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

 

Development of the Sound Generator will now begin!

 

Cheers!

Brad

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

Last Edited: Sun. Jan 17, 2016 - 06:54 PM

Pages