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

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!

"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

sparrow2 wrote:

so the HW are different from the link in #26 or ? because it had sound.

If there are room for two versions of that bird sprite, you should be able to get more colours if   it's made interlaced. (just move a pointer for odd and even pictures), or if you can make a 1/2 line delay you could get 480 lines with a "real" interlaced picture, as long it moves that fast no one will notice it.  

 

Yes, this is a complete redo from the original.

The project was sitting there, and I was bored. I said... "Hell, yeah I could do better... much better"!

I will reveal everything as soon as the next Demo is ready.

 

This version is actually capable of 316x480 resolution, but due to the limited storage, sprites would be just too small!

I am using many of the tricks you already mentioned, plus a few more "under the hood".

 

Programming is fairly easy as well, as the Video Driver does all of the heavy lifting.

I actually had the main loop in C on the first test, but decided this one should be bare metal all the way instead.

 

Brad

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

Last Edited: Wed. Dec 9, 2015 - 06:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:

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

 

 

Yeah, it's a prototype! I do that on IO at the beginning so I can see which pins do what.

That's why I ain't posting the code until it is fully optimized and commented.

 

Now, if you can find a way to reduce this segment, I will carve your name into my workbench!...

 

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

Simple enough... load a value from SRAM, spit it out, then store another value there before incrementing.

I do this 184 times, fully unrolled. Lighting a roach using a magnifying glass... can't get much cheaper than that!

 

Brad

 

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

Last Edited: Wed. Dec 9, 2015 - 06:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This make me think back on the ZX80, (made the same video as fast on ZX81), and that was also only made with "normal chips", but the z80 had 40 pins.

The ZX 80 had only 4K of ROM, but the huge amount of 1K of RAM :)

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

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?

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

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?

 

Indeed!

OK, let me reveal a bit more.

This is the Horizontal Line Rendering Loop.

As you can see from the timings shown in my Handy-Dandy VGA calculator, I can squeeze 920 pixels out at 36MHz.

Of course, this is bogus over 640x480, and AVR can't do that kind of IO bandwidth, so I divide.

I am in fact running the ATiny at 36MHz, so if I divide the Active Pixel Time (920) by 5, I can push out 184 Pixels.

 

 

The reason that I am reading, sending, and then writing to the 184 bytes of SRAM being used as a Line Buffer is to auto clear it on each line.

If the main loop had to deal with screen clearing, this would eat no less than 368x240=88,320 cycles! (ST Y+,r17 unrolled 184 times x 240 lines).

 

So my Video Engine draws a line of pixels, and then auto-erases them to some background color stored in the register.

The main loop now has a clean slate on which to render the next frame of images. This is a HUGE speed improvement.

If I ditch the auto-clear, I can send out 316 pixels, but this is just too silly for an ATiny.

 

The ADC joystick tricking the reset pin to be in input is interleaved in the horizontal line, so it takes no main loop time away from the game.

Oddly enough, I also have a 4 Voice simple Sound Engine hiding in the Horizontal Sync time, and it is fully operational, but has no free IO!

I am looking at ways to either trick some noise out of a pin, or to somehow multiplex one of the RGB pins to perform both functions.

The rules strictly forbid any other components besides passives like resistors and caps, so I will have to get creative in bizarre ways here.

 

For the record, yes... I am blasting the ATiny at 36MHz, and can get 18MHz IO bandwidth easily!!

I was originally running it at 40MHz for months, but decided to take it down as a safety margin.

40MHz testing was done on multiple ATinys, and always filled SRAM and Program memory to 100%.

EEPROM will not work at speeds much over 25MHz on any AVR. Everything else is perfect.

Hey... all the cool Kids overclock their AVRs!

 

There are other tricks used in the Video Engine that I will explain with real code and some cool demos soon!

 

Cheers!

Brad

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

Last Edited: Wed. Dec 9, 2015 - 07:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

"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

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

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

 

Last Edited: Wed. Dec 9, 2015 - 07:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

I don't want to reduce the resolution at this time, and the entire Video Engine only takes up 1.5k.

Besides figuring out sound, I am plenty satisfied with this one!

 

Brad

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

Last Edited: Wed. Dec 9, 2015 - 07:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

 

Last Edited: Fri. Dec 11, 2015 - 01:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

 

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

 

 

Not on an ATiny.

Since I need to count to 1146, and have only 8 bit precision, I prescale by 8.

Now that leaves my timer with 8 bit precision when entering the interrupt.

To de-jitter, you need full precision, so I have another counter wraping in sync with a common divisor.

I read the second counter, which now gives my 16 bit resolution back!

 

.... oh the hoops we must jump through!

 

Brad

 

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

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

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:

 

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

 

Last Edited: Wed. Dec 9, 2015 - 08:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fabulous!

Cannot wait to see the code for this!

 

SpiderKenny
@spiderelectron
www.spider-e.com

 

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

joeymorin wrote:

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.

 

 

Awesome, thanks for the spark!

I will have to see if this is possible.

That's why I like this community... so many creative ideas, and out of the box thinking!

 

When I get to the Audio puzzle, I am going to have to reach WAY outside of the box!

Some of the crazy ideas in my sketch pad so far...

 

- Use a floating IO for Sync, that outputs for high sync, floats for no sync, but shorts to a resistor to make sound (pickup the switching noise).

- Try running low sync slightly above 0 volts for a small window where sound can be picked up.

- Some kind of charge pump that allows a color bit to toggle right after sync to make a 1 bit click at some frequency.

- Reserve color White (3 bits hi) as a sound value, and pump that to a zener to clamp RGB output, yet toggle sound.

- Allow myself a transistor, and amplify the hell out of the ADC, using switching noise to create a frequency.

- Exploit some other internal noise that can be controlled, and simply amplify the damn VCC pin!

 

I WILL make sound without sacrificing my vibrant, rich 3 bits of color!

 

Brad

 

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

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

Add this one to the sketch pad:

http://spritesmods.com/?art=avrfmtx&page=1

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

Add this one to the sketch pad:

http://spritesmods.com/?art=avrfmtx&page=1

 

Nice! Done it on a pic 16F84 way back in my evil days!

I had a tank circuit to get a few feet of range.

 

In my TODO list of "crazy AVR projects", I have one called "TinyCaster, and it is something along these lines as well.

It will transmit by tweaking the PLL, and programmatically generate retro music.

Another exploit I found that worked was to load the clock oscillator through a capacitor on an IO pin.

This effectively FM modulates the clock, and a 2 inch wire gives a decent amount of range.

To really hit the FM band, a 100MHz canned clock work great, and you just use the AVR internal clock.

Leave the output of the 100MHz clock free, and load down the clock VCC with an IO pin to make slight FM.

 

No doubt, there are many other ways to be revealed by AVR Freaks!

 

These are the kind of projects I want to have on AVRCade.com when  I finally get it up and going.

I will reach out to SpritesMods for sure! Thanks for the link.

 

Brad

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

Last Edited: Wed. Dec 9, 2015 - 09:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I get to the Audio puzzle, I am going to have to reach WAY outside of the box!

As with other responders, I admire that you can make a silk purse out of a sow's ear.

 

But consider what you can do with a "capable" Tiny -- Tiny1634 is still a Tiny.  [Will it like being run at your overclock speed like the '85?  Dunno.]

 

I don't know what your rules are, so the lack of DIP package may be a killer?  If not, then you have a lordly 1KB of SRAM, and timers and USI and USARTs, and etc.  Three ports, A/B/C.  Usable are four port B bits (perfect for your current method), three port C bits (a fourth if you use /RESET), and the full eight of port A.  And if you only need one ADC input for your joystick, then it could run auto-trigger and takes no cycles--just grab the result.

 

No, it isn't less than a buck qty. 100 like the '85.  But it isn't much more than a buck, either.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

1146 clk on a 8 bit timer. (there is a note about the extra 4 bit from USI so perhaps it's the best way).

 

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

 

I remember that I once spend at least 200 clk in a timer ISR that had to run at full speed, so about the end of the ISR I added (sub.) 128 to the timer (as I remember you need to write 6 clk different ), so the 

ISR ran every 384 clk (precisely) .

Last Edited: Wed. Dec 9, 2015 - 10:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

No, it isn't less than a buck qty. 100 like the '85.  But it isn't much more than a buck, either.

 

If the target is sub $1, I cannot help wonder how this nifty project would re-code into a different 8 bit device ?

 

ATTINY85   0.71775 @ qty 2,000  SO-8  6 io  8KF 512R  20MHz

EFM8BB3   

  0.59994 @ qty 2,000 QFN24    20io 16KF 2.25KR  50MHz

  0.65448 @ qty 2,000 QSOP24  21 io

  0.76356 @ qty 2,000 QFP32    28 io

No DIP, but the QSOP24 and QFP32 are hand-solderable

 

 

 

 

Has A/D 12x12b, D/A 2x12b so can do Audio nicely (no tricks) and more pins would allow 8bit colour.

 

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

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.

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

 

Last Edited: Thu. Dec 10, 2015 - 04:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

or simply don't run any main code between lines (perhaps buffer some data, as I remember a C64 took 3 clk of each line to read data for the HW sprites), only in the vertical pulse time.

 

 

 

Add:

perhaps it's time to make a full 80x25 vt52 terminal out of a mega128 :)

Last Edited: Wed. Dec 9, 2015 - 11:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I took a few minutes to add a few things to my basic Video Test.

Put the pallet in the background, and made the ball move under 2 of the bars to prove that this ain't just a tile engine!

Notice the perfect 60FPS animations and "alpha" pixels of the sprite (no square edges).

Not bad for a 4 IO ATiny with 512 Bytes of RAM!

AVR Rawks!

 

Will do something much more interesting when I have the time.

 

Video...

https://youtu.be/6Y_5X8HbdK8

 

Later!

Brad

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

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

AtomicZombie wrote:

I took a few minutes to add a few things to my basic Video Test.

Put the pallet in the background, and made the ball move under 2 of the bars to prove that this ain't just a tile engine!

Notice the perfect 60FPS animations and "alpha" pixels of the sprite (no square edges).

 

Very impressive....

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

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.

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

 

Last Edited: Thu. Dec 10, 2015 - 04:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May I ask how big a % tiny85's can run 36MHz, I guess that it's a big help that it get's a good stable clk., and what are the best voltage ? (and are there week/year revision that are the best). I have about 250 dip, produced mid 2013.

 

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

Last Edited: Thu. Dec 10, 2015 - 11:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

about sound. Do you have a line sync? (or was it something that it could be done on the green line I can't remember).

 

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

 

 

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.

 

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

Last Edited: Thu. Dec 10, 2015 - 12:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote     AVR Rawks!     /Quote   yes

 

Very nice YT https://youtu.be/6Y_5X8HbdK8  and very smooth movement of the ball.

I just follow this in awe

 

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

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

 

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.

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

 

Last Edited: Thu. Dec 10, 2015 - 02:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 It won't be possible (never say never?) to use /RESET as an output without programming that fuse

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

 

About the R and B level outside the picture. I don't think it matter but could be wrong. (and yes I was thinking of something like that, but with some serial resistors and the joystick having Vcc on one end.)

 

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

 

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)

 

Perhaps a way to make sound could be the input clk :) if it's possible to enable the internal pullup or something like that, or program the DDR bit the load on the clk may change a tad.

 

 

 

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

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 CPIN).

 

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.

 

 

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

 

Last Edited: Thu. Dec 10, 2015 - 02:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

I know that, but if you flip the bits that should do it, can you see anything "weak" spike on the pin.

 

 

About internal PLL:

Depending of how warm it gets, I would guess that at something like 5.5 to 6.5 V would be the best, if it stays cold.

 

 

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

 

 

Last Edited: Thu. Dec 10, 2015 - 02:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Only if VS/H is different than VRESET.  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 VS/H, and would persist as long as the MUX is ADC0, rather than the single spike generated at the moment the MUX is switched.

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

..  My tests did not include the characterisation of jitter, neither for the RC directly, nor for the hf PLL clock.

 

I think that is the killer - other threads have shown relatively poor jitter on AVRs RC Osc, and getting worse with newer releases, as Atmel push things smaller.

With displays getting many more pixels, best to stick with a proper clock source that is known stable.

A Clock Gen part like the Si5351A is cheap and allows any frequency to be generated, but would not fit a 8 pin target.

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

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.

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

 

Last Edited: Thu. Dec 10, 2015 - 10:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greets! Been traveling lately, and just wanted to chime in.

 

No, the PINB.5 cannot output at all. Even highly amplified, there is no signal.

I have not tried switching nose exploits yet, but will soon.

 

The internal PLL is not stable enough for video, and the internal clock will reach 33MHz if you crank op OSCCAL.

The data sheet claims it must be done in steps, but I just jam it right to full... no issues doing that!

 

I have worked up a plan to get sound (untested).

It involves the negative sync zeroing the color bits through a diode (after the resistors).

I then feed a 3 bit DAC right from the pins. This keeps color from being sent during HSYNC, where the sound routine lives.

Just have to work out how I am going to stop the 60Hz VSync from buzzing in there.

If this works, sound will even have 8 volume levels and simple waveforms!

 

Will post results if I have time to play this weekend.

 

Brad

 

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

Last Edited: Fri. Dec 11, 2015 - 04:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

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

 

Last Edited: Fri. Dec 11, 2015 - 04:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The internal PLL is not stable enough for video, and the internal clock will reach 33MHz if you crank op OSCCAL.

The data sheet claims it must be done in steps, but I just jam it right to full... no issues doing that!

If you use the same board for internal PLL as in the video's then I will not blame the tiny85 if it has jitter, on the clk. (sitting on a "real" board with a better power would help a lot).

 

But I have never used the PLL on my tiny85's, but the clk seems to be fine (not like some old tiny13 that was really bad). 

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

Thanks for the comments!

 

A few answers...

 

No AVR can generate video from an internal clock. Not ATmega, Not ATiny, and not XMega. I have tried this extensively.

Well, you "can" push NTSC, but it looks like hell. Trust me, the internal clocks are not stable enough.

 

For the "multiplexing", it will be more of a tristate affair using a combination of the data direction register and some sneaky voltage divers.

I have decided that I will allow ONLY one single transistor to get sound if it comes down to having to loose a color bit. I will not give up all 3 bits of color.

Doing the entire project with only a few resistors, and perhaps a cap and diode is my main goal, though.

 

Brad
 

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

Last Edited: Fri. Dec 11, 2015 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are other insane people out there:

https://hackaday.io/project/4348-attiny85-does-ntsc-over-vhf

 

Another one for your sketch pad? ;-)

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

There are other insane people out there:

https://hackaday.io/project/4348-attiny85-does-ntsc-over-vhf

 

Another one for your sketch pad? ;-)

 

Nice one!! Hadn't seen that one before.

Thanks,

Brad

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

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

If I have to resort to a transistor, here is my idea to share sync with sound in a way that "should" multiplex and not allow either color during sync, or sync into sound.

Since the Sound Driver only sends sound while HSync is low, this might work (untested yet)...

 

 

Here is how I imagine this working...

 

For Sync Off (Hi Pin), I just set the pin to input (high impedance). I will probably add a pullup.

For Sync Low (Lo Pin), I set as output and to 0 volts.

 

In the Low state, the sync pin also drives the color bit to ground (thru diode), effectively killing any output during sync.

Color cannot be driven hi during sync or the monitor will open a wormhole and devour the entire universe.

 

Also during the Low Sync state, the transistor comes alive, with its base fed directly by the color IO.

Since there is a divider, some voltage can make it to the base and turn on or off the transistor.

The switching of the transistor is my sound. I can toggle or not toggle each line to make frequency.

During Sync Hi, the transistor is turned off and no 60Hz sync will invade my sound channel.

Changes in the Color Pin are also blocked from going to the Sync Pin by the diode.

 

For Stereo sound, I can add a second transistor to one of the other color bits.

 

 

I will test this in a few days hopefully.

 

Brad

 

 

 

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

Last Edited: Fri. Dec 11, 2015 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

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

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?

 

The levels are called out as TTL, but until I try it, I can't be sure.

If we are all still here by Sunday night, then it probably worked ok.

 

Brad

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

Last Edited: Fri. Dec 11, 2015 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

If I have to resort to a transistor, here is my idea to share sync with sound in a way that "should" multiplex and not allow either color during sync, or sync into sound.

 

That's getting to a lot of parts, why not use a HC4053 ? - or a P-FET ( or possibly PNP) as a series S&H ?

Last Edited: Fri. Dec 11, 2015 - 10:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

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?

Timing can maybe help a little there, the sample and hold action will be on the trailing edge of sync, so that time window is Audio, outside that, the DAC can drive black

Last Edited: Sat. Dec 12, 2015 - 02:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a few hours to hack around in my basement lab, and made progress on Quark-85.

 

Sound is working fine now using the transistor hacki-plexer. No loss of color.

I only needed a single 2N3905 and one resistor to make sound.

It is just a single square wave that can be set to any frequency.

 

I also created a different style of joystick and got that all working.

I have a variable resistor and 2 buttons, which will work well for most games.

The joystick hardware is very simple... 1 POT, 1 resistor, and 2 push buttons.

Games like Omega Race or Arkanoid will do well with this configuration.

 

I am cleaning up ASM, and will be doing a demo when I have the chance.

 

Cheers!

Brad

 

 

 

 

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

Last Edited: Sun. Dec 13, 2015 - 01:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1980's style video games on one $2 chip. Amazing.

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

Thanks!

It should certainly be able to pull off all of the VCS games and probably go a level higher.

 

I like this one because it pushes the hardware to the edge of sanity and beyond.

A small ARM would be in the same price range and have no problem doing even 256 colors and good resolution.

But this little AVR is only 8 bit, has extremely limited memory, and only 4 real IO pins, so it makes it much more fun!

 

Speaking of IO, I winder why more effort making B.5 (also Reset) usable.

I could think of many easy ways to allow it to become a real IO and still work with the programmer.

On a chip where IO is gold, a little more digging into design should have been done.

 

Brad

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

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

the biggest challenge for many of the games will the 512 bytes of RAM.

Pages