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

Go To Last Post
438 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Greets Freaks!

It has been a long time since I had a free weekend to hack away on my favorite uC, but today I took out a small breadboard, a few resistors, a VGA connector and decided to see where things would go.

The original plan was to just bit bang some mono VGA and do up a Pong or Tetris game, but things went MUCH MUCH further than I ever thought possible, so over the next few weeks I will detail this fun project here. I call it The QUARK-85 VGA DEMO System.

So what can one do with an ATTINY-85 and no other external components, an 8 pin package that leaves ONLY 4 IO lines after you feed it a clock??

How about 4 color rock solid VGA with stereo sound!!!

I kid you not, with only 4 IO pins, this little AVR pulls it off. Now if you consider the fact that you need a minimum of 4 IO pins just to make any amount of color VGA (H-Sync, V-Sync, Red, Green), it baffles the mind as to how it can also do stereo sound, since the pin count would now be at 6 IO lines.

Oh, and my constraints were to use NO other external components besides the clock oscillator, and a few passives such as resistors and diodes.

This project is probably my favorite of all my video hacks, since it seems to do the impossible. The VGA signal is following the 640x480 standard exactly, and there is no jitter at all.

I also did the video core in assembly, but do all of the fun stuff in C, so it is really easy to make demos on this little hack by just calling the routines. The programmer does not have to worry about interrupts or any kind of odd timing at all.

Currently, the system supports 3 video modes, with various features and resolutions. Since there are only 512 bytes (yes bytes!) available in the T85, a lot of trickery went into the assembly routines in order to display color bit-mapped graphics, text, lines, circles, etc.

Sound is pretty basic, just a right and left channel that can play a note with a frequency between 0 and 10KHz, but it's enough to play music.

I am going to clean up the routines and make a few cool demos in C before I release the project here, and will add to this thread each time I make a little more progress.

Anyone want to venture a guess as to how an ATTiny85 with 4 free IO pins does rock solid 4 color VGA and stereo sound without any other components besides 2 diodes and 6 resistors?

Cheers!
Brad

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

Last Edited: Sat. Jul 30, 2016 - 08:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With some overclocking for starters :)

Tiny85 Maximum Clock Frequency: 20 MHz
VGA 640x480 : 25.175 MHz

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

Who-me wrote:
With some overclocking for starters :)

Tiny85 Maximum Clock Frequency: 20 MHz
VGA 640x480 : 25.175 MHz

Yes and no. Yes, I am running the T85 at 25.175Mhz, but it can do the same thing at 20MHz. In fact, the original version was running at 20MHz, but I thought it would add to the coolness to push it up a little! Both the 20 and 25.175MHz version report 640x480@60Hz on any VGA monitor.

I forgot to mention, that this system is not a "chasing-the-beam" type of system, each video mode is bit-mapped to the internal SRAM in a sneaky kind of way.

In one mode, I get an effective resolution of 192x120 pixels and can draw text, shapes, and even 4 color sprites at 60 frames per second flicker free. The colors it can generate are black, green, cyan, and purple (all onscreen at once).

Sampled sound is also possible, but it eats so much progmem, that I took out the routines.

Brad

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

Last Edited: Mon. Sep 9, 2013 - 12:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

Waiting excitedly for details.

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

Sweet Jeebuz!

AtomicZombie wrote:
Anyone want to venture a guess as to how an ATTiny85 with 4 free IO pins does rock solid 4 color VGA and stereo sound without any other components besides 2 diodes and 6 resistors?
You mean you're using an external crystal? Or an external clock...

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

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

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

Really looking forward to following this project!

JJ

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

"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: Mon. Sep 9, 2013 - 04:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Each output is tri-state: low, float, high (and pull-up, but it's a weak one so probably not enough current for anything useful without an external amplifier). With two diodes (and two resistors), you can split one output pin into two channels:

out     left    right
---------------------
low     low     low
float   high    low
high    high    high

This leaves three output pins for VGA. You'd use sync-on-green, so these can do RGB and I believe need no sync lines. I think the sync pulse is negative, so you might float the VGA output's ground so that you can output the negative pulse.

I imagine that you took a different approach, though, since there are probably lots of ways of going about it, and I'm not very familiar with the AVR series yet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
out     left    right
---------------------
low     low     low
float   high    low
high    high    high

And what about left@low and right@high?

Quote:
You'd use sync-on-green
Not part of the VGA specs (I believe), but a good idea. I have a couple of monitors capable of SOG kicking around.

These would fall under:

Quote:
clever use of DDRB
... and are good ideas in their own right, but I would sooner apply them to the two colour outputs to achieve 8 or 9 colours instead of just 4. Since PORTB and DDRB are separate I/O registers, timing would be a biatch...

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

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

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

JJ

"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

Everyone is on the right track here. Before I reveal the secret, here are the constraints...

- After applying a clock input from the external clock module, the Tiny has only 4 inputs available, not 5. You could theoretically have 5 IO, but that would mean the loss of programming ability unless you have some strange beast called an HV programmer. So I am working with 4 free IO pins.

- I am driving H-sync, V-sync, Red, Green, Audio-L, and Audio-R, so there are 6 outputs being used to the monitor and speaker system.

- Sync pulses sometimes overlap (when V-sync is active), and audio signals happen on every single line, at 31.5Khz. The red and green color signals occur during the active frame time at a rate of up to 5Mhz, and must be off during the blanking periods.

So, a LOT of magic must happen to satisfy all 6 outputs using only 4 AVR IO lines!

Getting 192x120 color VGA out of a 512 byte uC without resorting to line chasing was also a chore, but I managed to do it so that the main loop (done in C) can just call all of the assembly routines without the need to understand VGA timing, interrupts, or any strange memory sharing.

Commands like this are available...

DrawLine(x1,y1,x2,y2,color);
PrintText("AVRFreaks!",x,y);

The system also supports flicker free animation by including an auto syncing routine that locks to the refresh rate of the video driver.

Will post the schematic next.

brad

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

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

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

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

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

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

Too many kind words for my hacks!

Here is the schematic. This should give away the secret of 4 pins acting like 6...

Code and demo videos to follow.

Brad

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

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

Why not run the chip from the intern clk :)
You should be able to run it at a bit higher than 20MHz (datasheet say max speed for PLL is 85MHz, and the chip can run at 1/4 of that

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

The Tiny PLL will allow 16MHz max. Even worse is the incredible amount of jitter present when using the int. osc. It is so bad that VGA will fail to lock and on my NTSC tests, the image was very badly line shifted.

The XMega on the other hand has an amazing PLL

Brad

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

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

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

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

Ok thanks for the info. But I'm surprised it's that bad since it's a 64 MHz div with 4.
When you say max 16MHz is that because the CPU don't work with a PLL of 80MHz, or the PLL don't lock at that freq ?

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

Amazing!

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

        R   G   B
-----------------
Black   0   0   0
Green   0   1   0
Magenta 1   0   1
White   1   1   1

Where does cyan come from?

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

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

JJ

"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

I believe the VESA standard states that the analog lines are 75 ohm terminated at both ends. I have tested this project on 4 monitors of various age / brand and the video looks the same on all of the so far.

Brad

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

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

Yes indeed, some sneaky twiddling of DDRB is the key to doubling up the color and sync lines.

There are 4 states available; high drive, low drive, Z pull and Z floating. When the video driver interrupt begins, I drive low to initiate the sync pulses. During the sync phase, all of the frame calculation and memory management happens as well as the right and left audio mixer. Audio pins are driven either high or low, so that part is easy.

When sync ends, I set those pins to Z with pullups initiated so that a single OUT can be used to determine the 2 bits of color. I do a little AND and OR logic before the active video line to determine the state of the entire PORT, so that the audio is not effected (each audio pin may be high or low at this time).

To send color data, DDRB is set, and since the PORT reg has 1s written to the color PINS, this either drives them high or back to Z, so sync is not affected thanks to the diodes.

There is some other magic in this fun project, which I look forward to sharing as well... interrupt latency removal using 2 8 bit timers.

Here is a preview...

I set my interrupts in C like so...

/////////////////////////////////////////////////////////////////////
////////// SETUP TIMER 0 - VIDEO INTERRUPT TO 800 / 8 = 200
/////////////////////////////////////////////////////////////////////

OCR0A = 99;
TCCR0A = 2;
TCCR0B = 2;
TIMSK = 16;




/////////////////////////////////////////////////////////////////////
////////// SETUP TIMER 1 - ANTI JITTER SYSTEM
/////////////////////////////////////////////////////////////////////

PLLCSR = 0;
TCCR1 = 129;
GTCCR = 0;
OCR1A = 0;
OCR1B = 0;
OCR1C = 4;

Now since a 640x480 VGA line requires 800 clock pulses, I have to prescale since the Tiny does not have 16 bit timers. So I divide by 8 and set it to 200.

This is all good, but to make a working video system you CANNOT have even 1 cycle of jitter throughout an entire frame of 420,000 cycles. Yes, that's 420k cycles (800 x 525) with not a single missing or extra cycle! And since the AVR interrupt system is not predicable beyond 4 cycles, something has to be done.

In my large projects, I just made a simple routine to check the timer value and delay based on the interrupt entry in order to equalize the latency, but with a divided clock, this is not possible since the resolution is 1/8 of the real value.

So to combat this, I setup a second timer to run in phase with the prescaled timer, but at 1 cycle resolution, wrapping at some divisor of the main timer. Now I can use the reference timer to simply adjust plus or minus 4-5 cycles on the interrupt entry in order to remove all jitter...

// VIDEO INTERRUPT ENTRY POINT (4)
.global TIM0_COMPA_vect
TIM0_COMPA_vect: ;4

// SAVE STATUS REGISTER (3)
push r16 ;1
in r16,SREG ;1
push r16 ;1

// ATOMICZOMBIE JITTER FIXER (11/16)
in r16,TCNT1 ;1
cpi r16,0 ;1
brlo FIX0 ;1/2
FIX0:
cpi r16,1 ;1
brlo FIX1 ;1/2
FIX1:
cpi r16,2 ;1
brlo FIX2 ;1/2
FIX2:
cpi r16,3 ;1
brlo FIX3 ;1/2
FIX3:
cpi r16,4 ;1
brlo FIX4 ;1/2
FIX4:

Works perfectly!

But this leaves no more timers, so I had to bit bang the 2 audio channels in coded during HSync.

I will be posting the entire system and code with a line by line explanation of how the assembly coded video engine works and how to use the C graphics routines to make cool demos.

Quark85 is certainly no power system, but it can do some cool stuff on screen and play polyphonic music. It will be a fun project to learn to code on, and I hope to do up some spiffy tutorials on using GCC and assembly together, something that I have found to merge the best of both worlds.

Just have to finish up a 5x5 character set, make a few more C routines for musical notes, lines, sprites, and special effects. Next rainy day, I will start adding some real code.

Cheers!
Brad

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

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

You're mad! Stark raving mad!

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

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

Shame you can't read the prescaler register.

Four legs good, two legs bad, three legs stable.

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

Sanity is highly overrated!

Yes, if we could read the prescaler counter, then when dealing with timing critical interrupts, one could deduce the cycle count by adding back to the timer value. Now that would indeed be a useful thing. It would be almost as good as just having a 16 bit counter to start with.

Brad

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

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

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

Four legs good, two legs bad, three legs stable.

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

Yes, that works well, but then forces the "C side" to become aware of timing in the "ASM side". It would require drawing all graphics during hblank and then hitting sleep before the start of the interrupt. I did add a C routine that can wait and sync with a certain vertical line (000-524), but this was done so that sheering could be eliminated on moving graphics if the main loop just happened to extend beyond a single refresh rate.

Hmmm... sounds complex, but in reality the programmer only has to issue graphics commands and my vid engine takes care of the rest.

Brad

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

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

AtomicZombie wrote:
I believe the VESA standard states that the analog lines are 75 ohm terminated at both ends.
[facepalm]... right!

AtomicZombie wrote:
To send color data, DDRB is set, and since the PORT reg has 1s written to the color PINS, this either drives them high or back to Z,
[facepalm]... I imagined it backwards. I thought you would use Z and Z with pull-up (which might have worked with high-value pull-downs) ... because I'd forgotten about the 75 ohm termination to ground...

Genius!

JJ

"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

any hope to get the example code ?

 

 

thanks

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

Greets again Freaks!

I often put my projects on the shelf while life keeps me busy, but nothing is EVER really finished.

In this case, I had a few hours to spare, and decided to work on my ATiny VGA system for a bit.

To be honest, this one is probably my favorite of all time, right next to my latest giant breadboard project.

 

Anyhow, I made the ATiny do something that even I would have claimed to be impossible!

With only 512 bytes of SRAM and 4 usable IO pins, I made the ATiny do this...

 

8 Color Bit-mapped VGA at 170x240 resolution!!!!!

 

I know... absolutely impossible! I would say the same thing.

How can a processor with only 512 bytes  crank out an image that would require over 40Kilobyes of SRAM?

 

Not only is it doing this, it can move multiple hi-resolution sprites around the screen and display a perfect signal.

This is not a tile engine, as sprites and graphics are able to be any size, and even overlap.

 

I look forward to finishing this up and making some demos to show.

 

The old version was also bitmpaped, but only managed to crank out a 72x48 image with 4 colors...

 

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

 

The new version is now doing 170x240 with twice as many colors!

 

Ok, back to my yard chores!

Talk at y'all soon (with proof of this claim!)

 

Brad

 

 

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

Last Edited: Sun. Dec 6, 2015 - 07:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

32 MHz.

 

Brain.  Hurts.

"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

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

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

AtomicZombie wrote:

How can a processor with only 512 bytes  crank out an image that would require over 40Kilobyes of SRAM?

 

Very impressive!

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

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

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

Thanks freaks!

 

Works on any monitor. VGA standard is held perfectly (640x480 60Hz Spec).

 

You will require a HUGE bill of materials...

 

1 - ATTiny-85

1 - 32MHz Osc

3 - Resistors

 

That's all so far!

I will probably add an ADC Joystick as well to make some games. This will add 1 more resistor and a POT.

 

I will post more when I get  break.

 

Cheers!

Brad

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

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

Kartman wrote:
Impossible? https://mitpress.mit.edu/books/r...

 

One of the many retro books in my library, and a good one to read!

 

Stella had some advantages over the ATiny, though.

Perhaps I will try to knock-off some of the VCS games on this thing!

 

Brad

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

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

I've not read it myself. With the Atari the stupid blinking was a tradeoff. Along with the blocky graphics what was good at the time, then as technology progressed it was seen to be bad, now when its 'retro' its good again!

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

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

Ross McKenzie ValuSoft Melbourne Australia

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

Thanks for the comments!

 

As promised, here is proof of my incomprehensible claim of 170x240 Color VGA spewing out of a 512 Byte ATiny...

 

https://youtu.be/rmx-2fTxsns

 

Sorry for the boring demo, I didn't have time to do anything cool just yet.

The "Sprite" is 100x80 with 8 colors!

Multiple Sprites can be drawn, complete with overlapping and alpha pixels.

 

Video is 100% solid at 60 frames per second, and the monitor locks to 640x480.

I also plan to add sound and a joystick... seriously!

 

Not bad for a 512 Byte ATiny with only 4 IO pins.

 

Out of all of my AVR projects, this one moves my insanity up a level.

Although programming a demo / game is easy, the Video Driver was something else.

Line syncing, dual on-the-fly buffering, realtime mixing, dual timer jitter fixer, etc.

 

I think this one is now my favorite.

Will do up a few demos to really show what this little banger can do soon.

 

Parrot image swiped from here... https://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes

 

Cheers Freaks!

Brad

 

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

Last Edited: Mon. Dec 7, 2015 - 08:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

Kartman wrote:
Impossible? https://mitpress.mit.edu/books/r...

 

One of the many retro books in my library, and a good one to read!

 

Stella had some advantages over the ATiny, though.

Perhaps I will try to knock-off some of the VCS games on this thing!

 

Brad

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

 

Four legs good, two legs bad, three legs stable.

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

I will assume that the sprite are placed in flash (3k), and not compressed in 512 byte of RAM or ?

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

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

"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

I will never measure up around here! ;-)

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

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I must make a correction to my claim, as I don't like misleading anyone.

I had originally claimed that I could do 170x240, but after a few "tweaks", I realize that this number is not correct.

 

Yeah...., it's blasting out 216x240 now!!

 

This is now the highest resolution color image I have ever made out of an AVR without needed external SRAM and supporting hardware.

Funny that it would be a 4 IO ATiny with 512 bytes of SRAM!

 

Can't wait to do something to show off the graphics capabilities of this Microscopic Retro Powerhouse.

Just have to figure out the best way to make sound now, as all IO Pins are in use...

 

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

 

Pin B.5 is actually not a "real" IO, as it is taken up by the reset function.

I found that I could "trick" the ADC to use this pin by holding it above 2.5 volts.

 

For sound, I may try some "way out of the box" trickery, like amplifying the noise from the ADC pin as I switch internal modes or something wonky like that.

 

I like this project so much, that I may fabricate a microscopic replica of an Atari 2600 cabinet to put it in.

 

Anyhow, will post something more interesting to look at soon.

 

Cheers!

Radical Brad

 

 

 

 

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

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

We are unworthy.

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

Agreed. Amazing what he can do with an AVR.

yes

 

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

I can't wait to try it.....  sounds like a Wozniak award for sure.

 

David

 

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

Have you pushed the limits of text display?

 

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

It may be a while before I can post the demo I started.

I upgraded Studio and my computer imploded.

Trying desperately to fix it now.

 

Spent the day killing my laptop...

https://www.avrfreaks.net/forum/atmel-studio7-problems-help-viewer#comment-1733436

 

When I do manage to get the AVRISP to work again someday...

 

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

This will be a fusion between Pong and the Amiga Boing demo.

Yeah... spinning checkered balls with joystick control on an ATiny!

 

Brad

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

Last Edited: Tue. Dec 8, 2015 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pick it
Pack it
Come along
And take a hit from the BONG!

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

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

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

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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

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

Torby wrote:

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

 

My AS7 went well the first time as well, but apparently it was a Beta, and had no option to get assembler help files downloaded.

I am still running the Beta in my Lab, afraid to go through that hell again.

I printed the assembly cycle counts on paper instead!

Kind of funny, I have them all memorized now anyhow, just couldn't remember the XMega use of LD and it's cycle cost.

 

On my Quark-85 Project, I now have the Amiga Boing Ball spinning on the screen!

It's crazy to see an ATiny pulling this off. The Sprites are 44x60 in size with 8 colors!

 

Will be adding the Joystick soon, and then trying to extract sound from it somehow.

With all 4 IO in use, this should be fun. I will not quit until I have it working.

I don't care if I have to wrap a coil around the chip and amplify the EMF to make sound, I WILL DO IT!

 

Brad

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

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

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.  

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

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

This is fascinating, but far beyond my experience.

Just throw in...

The ADC is itself a crude timer - if 1/13 (?) of it's pre-scaler is any use. I know not.

The ADC works fine in my experience with a 1Mhz clock. Even unto 10bit, although that is with a clean external reference.

With 2 signals in the Mhz, you could obtain audio with a crude ring modulator (diodes) if you can create a difference frequency in the audio range. Both signals the same should be silence?

 

 

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

sparrow2 wrote:

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

 

Make that 319 Bytes.

The Video Driver is using 192 bytes of the available 512 bytes.

 

But it can be done!

That Alien game I made on the old version only had 75 bytes for the main loop, and it was done in C!

This just makes it all the more fun.

 

Brad

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

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

While I was doing some plumbing, it occurred to me how I could get rid of that ugly transistor and keep the design to only a few passives!

A water line and tap actually has 3 states...

 

1) Tap On with water flowing.

2) Tap Off with no water flowing.

3) No pressure in the line.

 

So I did this with my RGB bits!

 

Instead of sending color bits as ones or zeros, I now alter the data Direction Registers in the pixel rendering loop.

RGB are on pins B.0, B.1, and B.3, so I just write the value of 7 to set all bit high before the loop.

In the loop, I send data to DDRB, and this does the same thing as sending ones or zeros.

 

But this also allows me a 3rd state (zero while pin enabled), which I use to drive the sound.

 

Hardware is MUCH simpler....

 

From the color pin, I have a diode forward feeding the resistor that drives the color pin on the monitor.

A second diode is then reversed to the audio output, which is pulled up by a 1 meg resistor.

 

Sound is actually better than the transistor job, and now I can have REAL stereo and 4 voices again!

 

I was not happy with the transistor, as it kind of polluted the idea of a single chip system.

Things are looking good again!

 

Now my last choice will be between making this a Game System or Demo Station.

 

As a demo system, there is no joystick port, just a single button for "press any key" kind of control. Simpler hardware.

As a game system, another connector and some hardware will be required, but then games can be made.

 

What do you freaks think?

If I was to publish this one, and possible put a few board out there,  which one would be more popular?

 

Brad

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

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

Don't have any 85s on hand, but I've been wondering if I could take an xMega32E8 and go through this thread.... Oh, just what I need, something else to do

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

Torby wrote:

Don't have any 85s on hand, but I've been wondering if I could take an xMega32E8 and go through this thread.... Oh, just what I need, something else to do

 

Funny you should ask!

Although only partially complete, the XMega version of this Video Engine pushes 432x240 with 256 colors!

It's so fast that the Main Game Loop is programmed in C. Also works on any XMega.

 

It's on my TODO list, but not until Quark-85 is done!

 

Brad

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

Last Edited: Mon. Dec 14, 2015 - 02:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hi there fellow freaks!

 

Absolutely amazing stuff, AtomicZombie! Hats off.

 

This is actually my first post on AVRFreaks, but caught my attention as I have Attiny85 VGA project of my own too. I started it this July and sort of finalized the code about a week ago...

 

I didn't know anything about VGA signal timings before I started this project and I'm still considering myself n00b what comes to electronics - been programming for decades, also for embedded, but only started creating electronics "more seriously" early last year.  What I couldn't quite figure out was the trickery of driving RGB and HSYNC + VSYNC with 4 pins, I'm very interested of hearing more about that!

 

When I saw this post my first impression was that "Wowzee, my VGA implementation is pure crap", but thinking a bit more I thought to share insights about my implementation with you too, as the goal of my implementation seems to be quite different from this VGA.

 

Originally the whole idea started as a challenge from a colleague to get ANY kind of VGA out from Attiny85... that proved to be not too hard, so I did set myself a goal to make usable text-mode VGA with external input (to be used for example with other microcontroller, arduino etc...) with UART. The original goal was 16 x 8 characters on screen. Also one important aspect of the goal was NOT to overclock the Attiny and NOT disable the reset-pin :)

 

The current implementation now has 32x14 characters on screen (448 characters!), it listens to UART @9600 bps and parses (small subset of) ANSI-escape codes (cursor move, clear screen, change color, scroll row left, scroll whole screen left, enable/disable wrap...). The font is 6x8 pixels and the nominal resolution is 192 x 112 pixels. "Of course", my single Attiny85 only does B/W because I'm already memory-deprived because I wanted so many characters on screen - 448 bytes of RAM is used for screen textbuffer, the rest 64 bytes is used by two 32-byte buffers: horizontal line currently being drawn and next horizontal line being precalculated so I don't get any gaps on screen.

 

After a while I started to think of getting also color-output and did it the easy way: I wired together 3 attinys, each one drawing it's own color :D They all run in sync and in true-parallel mode, the clock is daisy-chained from attiny to another.

 

I'm hoping not to "hijack" this thread, but just wanted to show what I'm working on, maybe someone would be interested in the implementation details too.

 

My plan was to write a blog-post about VGA in general and the implementation, the source code and schematics are already public in https://github.com/Jartza/octapentaveega

 

My OctaPentaVeega, running simple ansitester

Scrolling full screen left.

 

Picture of the board I designed for it: https://drive.google.com/file/d/...

 

//Jartza
Jari Tulilahti

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

Welcome to AVRFreaks Jari.

 

Cheers,

 

Ross

Ross McKenzie ValuSoft Melbourne Australia

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

Pleased to meet you, Jari. Sounds like a cool project.

 

The Atomic Zombie regularly boggles the whole bunch of us.

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

Welcome to this amazing AVR community!

You have a great project going there. I looked at your source, and it is nicely done!
 

I often thought about parallel AVRs, but didn't try as I figured there would be syncing issues.

If you drive from a single external OSC, do all AVRs truly sync, or is there a random nanosecond shift?

Since you did this, perhaps you could offer insight into the results of parallel AVR processing (clock shift)...

 

1) Is the slight shift stable between AVRs? If so, you may see a slight banding on the edge of a pixel as each AVR outputs the color data. It would be very slight.

 

2) Is the shift random? If so, there would be a slight color jitter, much like an interrupt that is not "jitter fixed".

 

Anyhow, great to see another ATiny standing tall and doing the implausible!

 

Cheers.

Brad

 

 

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

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

Hi Brad!

 

You have a great project going there. I looked at your source, and it is nicely done!

Thanks :)

 

> I often thought about parallel AVRs, but didn't try as I figured there would be syncing issues.

> If you drive from a single external OSC, do all AVRs truly sync, or is there a random nanosecond shift?

> Since you did this, perhaps you could offer insight into the results of parallel AVR processing (clock shift)...

> 1) Is the slight shift stable between AVRs? If so, you may see a slight banding on the edge of a pixel as each AVR outputs the color data. It would be very slight.

 

You are absolutely right, there is slight shift when daisy-chaining the clock through AVR. The banding is visible on bigger monitors, but with 17-19" displays it's barely visible. Still good enough for me :)

 

> 2) Is the shift random? If so, there would be a slight color jitter, much like an interrupt that is not "jitter fixed".

 

Fortunately no, it's very uniform so it doesn't really bother that much as jitter would.

 

To the technical point, if I had more memory (heh) left I could also try driving at least 4 colors from single attiny, but that would basically require me to push less characters on screen (as I'm using the whole 512 bytes of RAM for buffers, CPU registers + one GPIOR for variables) to store the color-information of characters (at least 2 extra bits per character).

 

If you noticed, I found out that USI can be used nicely to draw the pixels and the characters can be drawn side-by-side unlike many atmega-project I saw.

 

I was going to post my OctaPentaVeega to Hackaday when the blog post is done, but now finding this I'm a bit hesitant... or maybe there's place for two different-goal-VGA implementations there? :D

 

Cheers,

//Jartza
Jari Tulilahti

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

Jartza wrote:

> 1) Is the slight shift stable between AVRs? If so, you may see a slight banding on the edge of a pixel as each AVR outputs the color data. It would be very slight.

 

You are absolutely right, there is slight shift when daisy-chaining the clock through AVR. The banding is visible on bigger monitors, but with 17-19" displays it's barely visible. Still good enough for me :)

 

> 2) Is the shift random? If so, there would be a slight color jitter, much like an interrupt that is not "jitter fixed".

 

Fortunately no, it's very uniform so it doesn't really bother that much as jitter would.

I would expect the delay to be jitter free, but where I'd expect possible issues is around Reset release.

 

You drive one AVR from a External Osc and then use OscOut to drive 2 more, right ?

That means they all exit reset, and some delay, would have the slaves simply wait for their clock.

 

Did you measure the phase difference between master and 2 slaves ?

 

An alternative would be to use SYNC as a lock, and clock all the same, but that would hope the sampling point was in a safe zone.

Last Edited: Mon. Dec 14, 2015 - 08:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

I would expect the delay to be jitter free, but where I'd expect possible issues is around Reset release.

 

You drive one AVR from a External Osc and then use OscOut to drive 2 more, right ?

That means they all exit reset, and some delay, would have the slaves simply wait for their clock.

 

Did you measure the phase difference between master and 2 slaves ?

 

An alternative would be to use SYNC as a lock, and clock all the same, but that would hope the sampling point was in a safe zone.

 

Hi,

 

I did measure the phase difference, but I can't remember exactly... somewhere < 10ns range anyway.

 

And yes, external oscillator is fed to CLKI and to next chip from CLKO. The "master" (RED) only drives the VSYNC & HSYNC, slaves (BLUE & GREEN) only draw pixels so I connected the VSYNCs together and the slaves listen to VSYNC to sync their timers.

 

Cheers,

//Jartza
Jari Tulilahti

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

Had a few minutes to test my new dual voice stereo sound routine, and it seems to be working great.

Tried the project on 5 various monitors, and it works across the board, showing 640x480@60Hz as the mode.

It's also nice to get that ugly transistor off the board and get back to the purity of only a few passive components.

Can't believe I was actually considering a transistor on a one chip project. I should be slapped with a PIC for that!

 

 

Video showing Sound and Joystick working...

https://youtu.be/AjL2fFsBR48

 

 

Sorry for the crudeness of my joystick test demo, it was a lunch-hour hack!!

Rainbow paddle is programmatically drawn in real-time because I was too lazy to draw a Sprite!

 

That horrific sound is the X and Y values of the Ball being sent to the Right and Left channel to test Stereo.

 

I think this Engine is just about ready now, so I will start on a real game.

Perhaps a colorful version of Omega Race with a lot more action that the original?

 

So to Recap, here are the multiple external functions that an ATTiny with 512 Bytes of RAM and 4.5 IO Pins can handle...

 

1) Horizontal Sync Pulse

2) Vertical Sync Pulse

3) Analog Red Signal

4) Analog Green Signal

5) Analog Blue Signal

6) Analog Left Audio

7) Analog Right Audio

8) Analog Joystick POT

9) Digital Joystick Buttons

 

The part count is...

 

1 x ATTiny85

1 x 36MHz Can Clock

2 x Ceramic Caps

6 x Resistors

4 x Diodes

 

Did I mention that AVR kicks ass?

... yeah, I think I did!

 

Cheers!

Brad

 

 

 

 

 

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

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

Hi,

 

AtomicZombie wrote:

Had a few minutes to test my new dual voice stereo sound routine, and it seems to be working great.

Tried the project on 5 various monitors, and it works across the board, showing 640x480@60Hz as the mode.

It's also nice to get that ugly transistor off the board and get back to the purity of only a few passive components.

Can't believe I was actually considering a transistor on a one chip project. I should be slapped with a PIC for that!

 

Hehe. I can slap you with PIC32 if it helps? laugh

 

AtomicZombie wrote:

Video showing Sound and Joystick working...

https://youtu.be/AjL2fFsBR48

 

That's just very nice and smooth and amazing. You're the champ!

 

AtomicZombie wrote:

I think this Engine is just about ready now, so I will start on a real game.

 

I thought my engine was ready too, but now I feel it might need some more oomph :D

 

AtomicZombie wrote:

So to Recap, here are the multiple external functions that an ATTiny with 512 Bytes of RAM and 4.5 IO Pins can handle...

...

 

I still would like to see more detailed explanation how this all happens, like with schematic and small story... might be a learning experience!

 

AtomicZombie wrote:

Did I mention that AVR kicks ass?

... yeah, I think I did!

 

We can join you in that song wink

 

Cheers,

//Jartza
Jari Tulilahti

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

Pic32... with all those bits, no doubt it would hurt!

Not to get too far off topic, but I dabbled in moving to 32bit last year and found that Pic32 was more Friendly than AVR32 actually.

That thing called "FLIP"... I mean, what the hell???! You have a great IDE and then have to drop into DOS???? Yikes.

No doubt, you can probably program in AS7 and then write directly to the chip now, but at the time it was a REAL turn off.

Ok, back to the topic!

 

No Engine is EVER done... I hear you loud and clear on that one.

Every time I think I have stretched the fabric of reality to the point of tearing, I think of another way to pull it another inch.

This time, perhaps the ATTiny is pushing the limits, so I am going to "wrap it up" and publish.

I will post a schematic today so you can have a look. Joystick will be included later, as I am finalizing some tests.

 

The trick to getting all of these functions on such limited IO is to consider 3 states : Hi / Lo / Z

Since most of the functions on VGA with 1 bit color are digital, you can often run two from a single Pin.

Tie a line Hi, and you can use Lo to control it, and the Hi state of the IO Pin for something else.

A few carefully placed diodes allow you to control 2 digital functions from a single Pin.

 

Once again, thanks for all of the positive feedback dudes!

The hardware deserves all of the credit, as it does all the heavy lifting.

I was just the Freak that told it what to do!

 

Brad

 

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

Last Edited: Tue. Dec 15, 2015 - 01:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Brad!

 

AtomicZombie wrote:

No Engine is EVER done... I hear you loud and clear on that one.

Every time I think I have stretched the fabric of reality to the point of tearing, I think of another way to pull it another inch.

This time, perhaps the ATTiny is pushing the limits, so I am going to "wrap it up" and publish.

I will post a schematic today so you can have a look. Joystick will be included later, as I am finalizing some tests.

 

I hear that fabric being taut and strained and making squeaking noises while watching your video. Can't wait to see the schematics (and code, if you're releasing that too?)

 

AtomicZombie wrote:

The trick to getting all of these functions on such limited IO is to consider 3 states : Hi / Lo / Z

Since most of the functions on VGA with 1 bit color are digital, you can often run two from a single Pin.

Tie a line Hi, and you can use Lo to control it, and the Hi state of the IO Pin for something else.

A few carefully placed diodes allow you to control 2 digital functions from a single Pin.

 

Ahh. Thanks! I think I get it... wish I knew about that trick earlier... 

 

 

Cheers,

 

//Jartza
Jari Tulilahti

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

Here is the Schematic for Quark-85, showing how each IO Pin is able to handle more than one task...

 

 

 

The two Joystick Buttons are not yet shown.

Also note that internally, RED, GREEN, and BLUE are pulled down via 75ohm resistor.

 

Brad

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

Last Edited: Tue. Dec 15, 2015 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

Here is the Schematic for Quark-85, showing how each IO Pin is able to handle more than one task...

 

 

 

The two Joystick Buttons are not yet shown.

Also note that internally, RED, GREEN, and BLUE are pulled down via 75ohm resistor.

 

Brad

 

Hi Brad!

 

Thanks a lot. Figured out something like that playing with resistors and diodes to test that "three states" from single pin, but this helps! Neat trick!

 

What's with the Sync, there's only one sync-pin? How does that work? I've been living under impression that you always need Hsync and Vsync for VGA surprise

 

Cheers,

//Jartza
Jari Tulilahti

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

Jartza wrote:

What's with the Sync, there's only one sync-pin? How does that work? I've been living under impression that you always need Hsync and Vsync for VGA surprise

 

 

I used to think that as well until one day I found out by accident, that you only need one IO do do sync.

After noticing that one of my projects was still working after forgetting a wire, I looked into this more and found out...

 

- HSync and VSync is actually XORed internally by the monitor.

- All monitors support "Composite Sync", which is HS and VS mixed externally.

- Composite Sync is sent through the Horizontal Sync Pin. Leave VS unconnected.

 

This is why I am not using a timer to do Sync. Using PWM makes it impossible to mix properly.

In short, HS is inverted during VS, and I have not made this work with PWM successfully yet.

 

I have over a dozen monitors in my lab, some as old as 1990, and this works on all of them.

So, now you have an extra IO Pin... worth as much as gold on an ATTiny!

 

As for assembly logic, it is easy. Just use a "flag" to determine VS (inverted state), and set HS...

 

// HORIZONTAL SYNC ON (7)
lds r0,AVRC_HVS ;2
clr r16 ;1
sbrc r0,0 ;1/2
ldi r16,16 ;1
out PORTB,r16 ;2

If bit 0 of R0 is set, then sync is inverted. 5 Cycles to make Composite Sync!

 

Or if you need single bit control of the port...

 

// HORIZONTAL SYNC ON (7)
lds r0,AVRC_HVS ;2
sbrs r0,0 ;1/2
sbi PORTB,4 ;2
sbrc r0,0 ;1/2
cbi PORTB,4 ;2	

 

 

 

Brad

 

 

 

 

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

Last Edited: Tue. Dec 15, 2015 - 05:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

I used to think that as well until one day I found out by accident, that you only need one IO do do sync.

After noticing that one of my projects was still working after forgetting a wire, I looked into this more and found out...

 

- HSync and VSync is actually XORed internally by the monitor.

- All monitors support "Composite Sync", which is HS and VS mixed externally.

- Composite Sync is sent through the Horizontal Sync Pin. Leave VS unconnected.

 

This is why I am not using a timer to do Sync. Using PWM makes it impossible to mix properly.

In short, HS is inverted during VS, and I have not made this work with PWM successfully yet.

 

I have over a dozen monitors in my lab, some as old as 1990, and this works on all of them.

So, now you have an extra IO Pin... worth as much as gold on an ATTiny!

 

Wow!

 

Indeed, that finding IS worth of extra golden pin :) This has been very educative thread!

 

Cheers,

 

//Jartza
Jari Tulilahti

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

Here is a bit more reading.

A good diagram of the HS and VS being mixed (inverted)...

 

http://what-when-how.com/display-interfaces/standards-for-analog-video-part-ii-the-personal-computer-display-interfaces-part-2/

 

Cheers!

Brad

 

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

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

Hey Brad,

 

Quick question as I'm a bit baffled. The diodes are connected together on both ends? How does that give what we need :D I made a simple test-circuit on breadboard but can't really quite get what I want :(

 

What diodes and resistor values are you using? I seem to have 1n4148 and some generic schottkys (bat85 etc.)

 

Cheers,

//Jartza
Jari Tulilahti

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

Jartza wrote:

Quick question as I'm a bit baffled. The diodes are connected together on both ends?

 

That's just a circuit typo, that needs fixing.

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

Like I said, nothing is ever really complete, especially when it's just wrong!

Corrected...

 

 

Thanks for the QC.

 

Cheers!

Brad

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

Last Edited: Tue. Dec 15, 2015 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

Like I said, nothing is ever really complete, especially when it's just wrong!

Corrected...

 

Thanks for the QC.

 

Cheers!

Brad

 

Ohh! So it just wasn't my imagination when I thought that we now really have some kind of tearing in the cosmos. Phew.

 

Still, amazing stuff, thanks for all the information. Downside is, I now have too much ideas in my head for my own VGA.... darned :D

 

Cheers,

 

//Jartza
Jari Tulilahti

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

AtomicZombie wrote:

While I was doing some plumbing, it occurred to me how I could get rid of that ugly transistor and keep the design to only a few passives!

A water line and tap actually has 3 states...

 

Brad

Hey Ross!

What did you say about plumbing again? :D

Cheers,

//Jartza
Jari Tulilahti

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

Jartza wrote:
AtomicZombie wrote:

While I was doing some plumbing, it occurred to me how I could get rid of that ugly transistor and keep the design to only a few passives!

A water line and tap actually has 3 states...

 

Brad

Hey Ross! What did you say about plumbing again? :D Cheers,

 

cheeky Well who would have "thunk it"? For those not watching the hackvana irc, a couple of days ago I suggested that Jari join AVRFreaks and talk with Brad about his VGA efforts. Comparisons were made and I commented that Jari, a former plumber, was probably a better plumber than Brad. And now we learn that Brad does plumbing also!

Ross McKenzie ValuSoft Melbourne Australia

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

Ross you or I should not be talking about "plumbing", it makes my eyes teary.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

AtomicZombie wrote:

- HSync and VSync is actually XORed internally by the monitor.

- All monitors support "Composite Sync", which is HS and VS mixed externally.

- Composite Sync is sent through the Horizontal Sync Pin. Leave VS unconnected.

 

This is why I am not using a timer to do Sync. Using PWM makes it impossible to mix properly.

In short, HS is inverted during VS, and I have not made this work with PWM successfully yet.

 

...

 

Brad

 

Hi Brad,

 

Just a thought, looking at the link you provided and understanding composite sync, shouldn't it be possible to run that with PWM, just set PWM to reverse mode when VSYNC should be active and back to normal when VSYNC pulse has passed? This way HSYNC is still handled totally by PWM.

 

No, I haven't tried this yet but planning to give it a go.

 

Cheers,

//Jartza
Jari Tulilahti

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

Jartza wrote:

 

Hi Brad,

 

 

Just a thought, looking at the link you provided and understanding composite sync, shouldn't it be possible to run that with PWM, just set PWM to reverse mode when VSYNC should be active and back to normal when VSYNC pulse has passed? This way HSYNC is still handled totally by PWM.

 

No, I haven't tried this yet but planning to give it a go.

 

Cheers,

 

Yes, on your configuration, that would certainly work.

Not sure if it would fly on mine though, due to the way I have pins configured.

I think PWM forces a pin as an output? If so, that's a no-go on my system then.

 

I run all pins as inputs, pulled up.

When a pin needs to output a zero, I send a zero to the pin, and then set the data direction register.

 

This is necessary due to the way I run most pins as dual function, such as RED / Left Audio and BLUE / Right Audio.

Another reason for using DDRB as the output is so that I don't have to mask bits in my Active Pixel Loop.

Having the Sync Pin in high impedance state tied High means that I can spew any value to the Port without crashing the video driver.

 

Does that make any sense? It seems logical enough when I look at my code!

 

Having to worry about only setting Port Bits 0,1, and 2 for color would mean either careful Main Loop programming, or an ANDI in the Video Loop.

For optimal speed, a Pixel is an 8 bit value as well, rather than having to Read, Change, and Save Nibbles, which would be very slow.

 

Yeah... under the hood, my Audio / Video Driver is absolutely insane, but programming in the "Main Loop" is fairly easy.

Even the Interrupt is all over the place, calling different cycle-counted loops depending on the position of the "beam".

The driver even includes a "Visual" Free Cycle mode that overlays a transparent pattern directly on the live screen to show how many cycles are left for the programmer.

Funny... I have built some Video Systems with considerably "large" hardware, but all in all, Quark-85 is my most "complex" project yet.

Probably why it may also be may favorite, right next to the other one I am working on that now sports over 200 ICs on a breadboard I cannot begin to describe.

 

What a fun hobby though! Forget watching TV... more fun to build TV!

So, if you can make PWM work on a pin set as an input, then indeed... I would be very interested in trying this out.

 

Cheers!

Brad

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

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

AtomicZombie wrote:

Yes, on your configuration, that would certainly work.

Not sure if it would fly on mine though, due to the way I have pins configured.

I think PWM forces a pin as an output? If so, that's a no-go on my system then.

 

Well, I tried reversing the PWM, while doing that I noticed that Attiny85 also suffers from the same bug that errata mentions has been in Attiny45, COM1B0 and COM1B1 bits have no effect unless you also set COM1A0 and COM1A1 bits to the same mode sad

 

Unfortunately, reversing the PWM seems to only take action after timer reaches OCR1C and zeroes the calculation, which means losing two hsync pulses. Image as demonstration:

 

 

Gray is the "combined" sync with PWM inversing, brown is the original VSYNC pulse.... Not quite right.

 

 

 

AtomicZombie wrote:

Yeah... under the hood, my Audio / Video Driver is absolutely insane, but programming in the "Main Loop" is fairly easy.

Even the Interrupt is all over the place, calling different cycle-counted loops depending on the position of the "beam".

The driver even includes a "Visual" Free Cycle mode that overlays a transparent pattern directly on the live screen to show how many cycles are left for the programmer.

Funny... I have built some Video Systems with considerably "large" hardware, but all in all, Quark-85 is my most "complex" project yet.

Probably why it may also be may favorite, right next to the other one I am working on that now sports over 200 ICs on a breadboard I cannot begin to describe.

 

What a fun hobby though! Forget watching TV... more fun to build TV!

So, if you can make PWM work on a pin set as an input, then indeed... I would be very interested in trying this out.

 

Cheers!

Brad

 

I'm pretty sure the engine is insane, looking at the result :)

 

Cheers,

//Jartza
Jari Tulilahti

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

AtomicZombie wrote:

No Engine is EVER done... I hear you loud and clear on that one.

Every time I think I have stretched the fabric of reality to the point of tearing, I think of another way to pull it another inch.

 

Brad

 

Hi Brad,

 

Very true, I already started rethinking my code and I'm now trying to push it to 32x16 characters on screen (yes, using the ENTIRE 512 bytes to screen buffer) without overclocking... because I have an idea :D

 

Let's see how that goes.

 

Cheers,

//Jartza
Jari Tulilahti

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

If you don't overclock perhaps you can use the EEPROM for some rare changed variables.

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

sparrow2 wrote:

If you don't overclock perhaps you can use the EEPROM for some rare changed variables.

 

Heh, there's really no such thing as "rare changed variable" when doing VGA on Attiny85 :)

 

I actually had a plan to use EEPROM for "startup-screen", so you could take a snapshot of what's currently on screen with escape command and store the current screen to EEPROM and every time on boot that screen would be restored (or with other escape-command).

 

Cheers,

//Jartza
Jari Tulilahti

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

Hi Brad,

 

Seems this already got featured on Hackaday, but for some reason they seem to call you Lucas... cheeky

 

Also quite missing on the technical details...

 

http://hackaday.com/2015/12/17/a...

 

 

Cheers,

//Jartza
Jari Tulilahti

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

I was more thinking of sprites for a game!

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

sparrow2 wrote:

I was more thinking of sprites for a game!

 

Ahh, my VGA-implementation doesn't have sprites nor it's really meant to be a game-platform (unless "drawing chars"-games count), I'm trying just to push as much text on screen as I can :)

 

Cheers,

//Jartza
Jari Tulilahti

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

Jartza wrote:

Hi Brad,

 

Seems this already got featured on Hackaday, but for some reason they seem to call you Lucas... cheeky

 

Also quite missing on the technical details...

 

http://hackaday.com/2015/12/17/a...

 

 

Cheers,

 

Odd, I wonder how they found it? I only ever posted it here.

I corrected them on the Lucas bit... thanks, I would have never seen that post on Hackaday.

 

I think your full SRAM to SCREEN video will work.

Just a matter of utilizing all registers.

Use r16-r31 when you need compares, and use r0-r15 when you don't.

CLR and SER are your friend on the lower registers as well!

 

Good luck!

Brad aka Lucas?

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

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

AtomicZombie wrote:

I think your full SRAM to SCREEN video will work.

Just a matter of utilizing all registers.

Use r16-r31 when you need compares, and use r0-r15 when you don't.

CLR and SER are your friend on the lower registers as well!

 

Good luck!

Brad aka Lucas?

 

Hi Lucas ;)

 

I'm still very hesitant in overclocking the Attiny for this project, you know, you gotta keep up with your principles ;)

 

I've been already using registers for variables, because 448 bytes is used for character buffer and 64 bytes has been used for draw/predraw-buffer, so the only thing I'm now trying to get rid of is the draw-buffer and use the whole SRAM for character buffer.

 

Doing a quick test I can barely push out the 192 pixels needed for 32 characters on row:

 

That gray line is the HSYNC pulse, brown line is pixel output, in this capture I draw 32 characters worth of "full white" to see the timings... I'm barely within specs :D But I think it's doable.

 

The only downside is that in my 6x8 character font, the last of the 6 pixels is reaaaaallly wide, I'm not sure if that's a problem, because my normal font doesn't use that pixel, only those "line drawing" characters. Another downside is that currently I draw each horizontal line just 4 times (making the vertical pixels essentially 4 "VGA pixels" high) but I can't do that if I have 16 rows, so I need some kind of alternating pixel height, maybe 4,4,3,4,4,3,4,4 horizontal lines per character pixels...

 

Cheers,

 

//Jartza
Jari Tulilahti

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

You will find a way, no doubt about it!

 

I do have a 20MHz version that can do 170x240, but it does squeeze the main loop a bit too much.

Here is a VGA timing calc I made that might help you tweak the line a bit...

 

Screen capture...

 

Download the program here...

http://avrcade.com/temp/vga.exe

 

Just a quick way to see what timings will work, and the values needed to keep to the standards exactly.

The program is a quick hack, sorry.... I am improving this one soon as well!

 

Cheers!

Lucas.... I mean Brad.... damn, even I am doing it now!

 

 

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

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

So the Atomic Zombie is really Lucas in disguise

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

Yeah, that was odd.

The name Lucas isn't even in this thread.

Perhaps the Hackaday dude was thinking about StarWars when he was writing the entry!

 

It's too bad it was posted so soon. The Video Engine is so much better than what I have shown.

Oh well... it's not about fame for me, it's about making it work.

No more answering posts on Hackaday until Quark-85 is REALLY ready to show off!

 

I will let the Hackaday post stew now, as well as the guy that claims this must be fake.

That really made my day! Just wait until this latest game is done, then the disbelief will increase!

 

In an an effort to keep the argument "HOT", here is part of the Video Driver code...

 

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// AVRCADE.COM - QUARK-85 VGA GAME SYTSEM
////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// TARGET : ATTINY-85 @ 36 MHZ / VGA @ 640 X 480
////////// HARDWARE AND CODING BY RADICAL BRAD
////////// VERSION DATE : NOV 05 2015
////////////////////////////////////////////////////////////////////////////////////////////////////////

// [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

// [STANDARD VERTICAL LINE TIMING FOR VGA @ 640 X 480]
// VLN : 480 FROM 000 TO 479
// VFP : 011 FROM 480 TO 490
// VSP : 002 FROM 491 TO 492
// VBP : 032 FROM 493 TO 524
// TOT : 525

// [ATINY-85 PORT PINS]
// PORT B.0 / PIN 5 = RED COLOR / LEFT SOUND
// PORT B.1 / PIN 6 = GREEN COLOR
// PORT B.2 / PIN 7 = BLUE COLOR / RIGHT SOUND
// PORT B.4 / PIN 3 = COMPOSITE SYNC
// PORT B.5 / PIN 1 = JOYSTICK ADC INPUT

// [DEDICATED INTERNAL REGISTERS]
// R10: COMPOSITE SYNC FLAG
// R09: LINE COUNTER HI
// R08: LINE COUNTER LO
// R07: SOUND COUNTER 1
// R06: SOUND COUNTER 2

// [DEDICATED SHARED REGISTERS]
// R25 : HORIZONTAL LINE
// R15 : JOYSTICK POSITION
// R11 : JOYSTICK BUTTONS
// R14 : BACKGROUND COLOR
// R13 : RIGHT SOUND FREQUENCY
// R12 : LEFT SOUND FREQUENCY

// [DEFINE SHARED REGISTER NAMES]
#define HLINE R25
#define	JOYPOS R15
#define	JOYBUT R11
#define	BCOLOR R14
#define	SOUND1 R13
#define	SOUND2 R12

// [3 BIT COLOR PALLETTE]
// 0 = BLACK
// 1 = RED
// 2 = GREEN
// 3 = YELLOW
// 4 = BLUE
// 5 = MAGENTA
// 6 = CYAN
// 7 = WHITE

// [DEFINE COLOR NAMES]
#define	BLACK 0
#define	RED 1
#define	GREEN 2
#define	YELLOW 3
#define	BLUE 4
#define	MAGENTA 5
#define	CYAN 6
#define	WHITE 7

// [GCC APPLICATION BINARY INTERFACE RULES]
// ALWAYS SAVE : R1-R17, R28(YL) ,R29(YH)

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// QUARK-85 DRIVER INITIALIZATION ROUTINE
////////////////////////////////////////////////////////////////////////////////////////////////////////

// ATTINY-85 INCLUDES
#define __SFR_OFFSET 0
#include <avr/io.h>

// STARTUP ROUTINE
.global AVRC_RUN
AVRC_RUN:

// SETUP JOYSTICK ADC
ldi r18,31
out DIDR0,r18
ldi r18,0x20
out ADMUX,r18
ldi r18,229
out ADCSRA,r18
ldi r18,88
out ADCSRB,r18

// SETUP TIMER 0 : VIDEO INTERRUPT @ 1144 CYCLES / 8 = 143
ldi r18,143
out OCR0A,r18
ldi r18,2
out TCCR0A,r18
out TCCR0B,r18
ldi r18,16
out TIMSK,r18

// SETUP TIMER 1 : LATENCY EQUALIZER TIMER @ 4 CYCLES
ldi r18,129
out TCCR1,r18
ldi r18,3
out OCR1C,r18

// SYNCHRONIZE LATENCY TIMER
ldi r18,0
out TCNT0,r18
ldi r18,2
out TCNT1,r18

// INCLUDE USER CODE
#include "User_Code.s"

// ENABLE VIDEO DRIVER
STARTUP:
sei

// RUN LOGIC LOOP
rjmp AVRC_LOGIC

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// HORIZONTAL SYNC PULSE  = 135 CYCLES
////////////////////////////////////////////////////////////////////////////////////////////////////////

// VIDEO INTERRUPT ENTRY POINT (4)
.global TIM0_COMPA_vect
TIM0_COMPA_vect: ;4

// SAVE STATUS REGISTER (5)
push r16 ;2
in r16,SREG ;1
push r16 ;2

// LATENCY EQUALIZER (7/10)
in r16,TCNT1 ;1
cpi r16,1 ;1
brlo AVRC_FIX1 ;1/2
AVRC_FIX1:
cpi r16,2 ;1
brlo AVRC_FIX2 ;1/2
AVRC_FIX2:
cpi r16,3 ;1
brlo AVRC_FIX3 ;1/2
AVRC_FIX3:

// SAVE REGISTERS (12)
push r0 ;2
push r1 ;2
push r16 ;2
push r17 ;2
push YL ;2
push YH ;2

// HORIZONTAL SYNC ON (5)
 sbrs r0,0 ;1/2
clr r16 ;1
sbrc r10,0 ;1/2
ldi r16,16 ;1
out PORTB,r16 ;2

// LEFT CHANNEL SOUND GENERATOR (18)
cbi PORTB,0 ;2
mov r16,r6 ;1
mov r17,r12 ;1
cpi r17,0 ;1
breq AVRC_V11 ;1/2
inc r16 ;1
cp r16,r17 ;1
brne AVRC_V12 ;1/2
clr r16 ;1
AVRC_V12:
brne AVRC_V13 ;1/2
sbi DDRB,0 ;2
AVRC_V13:
breq AVRC_V14 ;1/2
nop ;1
nop ;1
AVRC_V14:
rjmp AVRC_V15 ;2
AVRC_V11:
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
AVRC_V15:
mov r6,r16 ;1

// RIGHT CHANNEL SOUND GENERATOR (18)
cbi PORTB,2 ;2
mov r16,r7 ;1
mov r17,r13 ;1
cpi r17,0 ;1
breq AVRC_V21 ;1/2
inc r16 ;1
cp r16,r17 ;1
brne AVRC_V22 ;1/2
clr r16 ;1
AVRC_V22:
brne AVRC_V23 ;1/2
sbi DDRB,2 ;2
AVRC_V23:
breq AVRC_V24 ;1/2
nop ;1
nop ;1
AVRC_V24:
rjmp AVRC_V25 ;2
AVRC_V21:
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
nop ;1
AVRC_V25:
mov r7,r16 ;1

// LINE COUNTER WRAP AT 525 (11)
movw YL,r8 ;1
adiw YL,1 ;2
ldi r16,hi8(525) ;1
cpi YL,lo8(525) ;1
cpc YH,r16 ;1
brne AVRC_LWL ;1/2
clr YL ;1
AVRC_LWL:
brne AVRC_LWH ;1/2
clr YH ;1
AVRC_LWH:
movw r8,YL ;1

// HORIZONTAL SYNC OFF (5)
 sbrs r0,0 ;1/2
clr r16 ;1
sbrs r10,0 ;1/2
ldi r16,16 ;1
out PORTB,r16 ;2

// VERTICAL SYNC ON AT 491 (5)
ldi r16,1 ;1
cpi YL,lo8(491) ;1
cpc YH,r16 ;1
brne AVRC_HSL1 ;1/2
mov r10,r16 ;1
AVRC_HSL1:

// VERTICAL SYNC OFF AT 493 (4)
cpi YL,lo8(493) ;1
cpc YH,r16 ;1
brne AVRC_HSH1 ;1/2
clr r10 ;1
AVRC_HSH1:

// SOUND BLANKING (2)
ldi r17,16 ;1
out DDRB,r17 ;1

// DELAY (38)
ldi r17,12 ;1
AVRC_HSD:
dec r17 ;1
brne AVRC_HSD ;1/2
nop ;1
nop ;1

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// HORIZONTAL BACK PORCH = 67 CYCLES
////////////////////////////////////////////////////////////////////////////////////////////////////////

// EXIT DURING VERTICAL BLANKING (4)
cpi YL,lo8(480) ;1
cpc YH,r16 ;1
brcs AVRC_ACT ;1/2
rjmp AVRC_EXIT ;2
AVRC_ACT:

// SET HORIZONTAL LINE VALUE = R25 (4)
mov r25,YL ;1
lsr r25 ;1
sbrc YH,0 ;1/2
subi r25,128 ;1

// READ JOYSTICK ADC = R24 (4)
mov r1,r15 ;1
in r17,ADCH ;1
com r17 ;1
clr r16 ;1

// CHECK LEFT BUTTON (3)
cpi r17,10 ;1
brsh AVRC_JB1 ;1/2
ldi r16,2 ;1
AVRC_JB1:

// CHECK RIGHT BUTTON (3)
cpi r17,0 ;1
brne AVRC_JB2 ;1/2
ldi r16,1 ;1
AVRC_JB2:

// SAVE JOYSTICK VALUES (7)
cpse r9,0 ;1
mov r11,r16 ;1
mov r15,r17 ;1
cpse r25,0 ;1
mov r15,r1 ;1
cpse r16,0 ;1/2
mov r15,r1 ;1

... and a whole lot more cycle counted code!!!

 

... ha ha ha... now watch the argument heat up when someone notices I did post some code.

Sure is a LOT of work to fake it... more effort than simply doing it. I must really need the attention!

 

The doubtful Frenchman has now even posted math trying to prove that this is impossible... too much!!!

Quote... "I added a comment above with the math. The math tell the truth."

 

I promise that the words "The math tell the truth" will be going on my website when I detail this project. Priceless!

Damn, if I was stuck in his shoes, I would never push the boundary and learn anything new.

 

The Amiga Boing Demo don't even push 10% of the Main Loop free cycle time.

Quark can also play music and digital sound effects. Even 4 note chords!

 

And no... I don't like indented code or feel the need to use a 20:1 comments to instructions ratio!

 

Anyhow, enough of this diversion, it's back to the breadboard and code, where my attention belongs.

Brad

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

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

Hah!

 

Here's some math to prove it!

 

42 / 7 = 6

 

wow! must be fake!

 

Cheers,

//Jartza
Jari Tulilahti

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

Jartza wrote:

42 / 7 = 6

 

wow! must be fake!

Cheers,

 

Indeed!

42/7 is actually 9.... in HEX!

Jack posts his "proof" in terms of uS rather than Cycles, which is where he flops.

But hey, we can all learn something, so hopefully he have that "aha" moment soon.

If I thought any differently, I would never improve my game either.

 

Brad

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

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

AtomicZombie wrote:

Indeed!

42/7 is actually 9.... in HEX!

Jack posts his "proof" in terms of uS rather than Cycles, which is where he flops.

But hey, we can all learn something, so hopefully he have that "aha" moment soon.

If I thought any differently, I would never improve my game either.

 

Brad

 

Yep, and 42/7 is 4, in octal :)

 

Any day one learns something new is a good day, and you're never too old to learn some new tricks. I don't believe what they say about old dogs.

 

Cheers,

 

//Jartza
Jari Tulilahti

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

Hiya,

 

 

Seems I can draw those pixels fine and dandy without any predrawing buffer. Even 32x20 lines of text, although the last 4 lines are just repeating the first 4 because all of the memory is used :)

 

Just a thought, how about using 2+2 rows from top and bottom to "static" data, which could be stored in EEPROM? :) Like some kind of statusbar or whatever :P

 

And one more thing, maybe I should create a totally new thread for my OctaPentaVeega instead of hijacking this one?

 

Cheers,

//Jartza
Jari Tulilahti

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

Nicely done... congrats!

What would the Frenchman say????

 

Funny you should mention EEPROM... I was using it to store a "pointer" and some characters on my lower speed systems.

In this one, reading EEPROM might not work at that speed.

I do however, read EEPROM to auto-calibrate the joystick ADC on startup, and then switch over to the external clock.

 

I think your project certainly deserves a full thread, but never worry about "HiJacking"... just a couple of hackers talking!

Quark-85 also uses the same size font. I made a few different ones (5x5 and 6x6). Feel free to try them out...

 

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// 5x5 CHARACTER SET BY RADICAL BRAD
////////////////////////////////////////////////////////////////////////////////////////////////////////

CHARSET:
.dc.b 0,0,0,0,0      ; ASCII: 32 / CHAR:  
.dc.b 4,4,4,0,4      ; ASCII: 33 / CHAR: !
.dc.b 10,10,0,0,0    ; ASCII: 34 / CHAR: "
.dc.b 10,31,10,31,10 ; ASCII: 35 / CHAR: #
.dc.b 31,5,31,20,31  ; ASCII: 36 / CHAR: $
.dc.b 17,8,4,2,17    ; ASCII: 37 / CHAR: %
.dc.b 6,1,22,9,22    ; ASCII: 38 / CHAR: &
.dc.b 4,4,0,0,0      ; ASCII: 39 / CHAR: '
.dc.b 8,4,4,4,8      ; ASCII: 40 / CHAR: (
.dc.b 2,4,4,4,2      ; ASCII: 41 / CHAR: )
.dc.b 2,7,2,0,0      ; ASCII: 42 / CHAR: *
.dc.b 4,4,31,4,4     ; ASCII: 43 / CHAR: +
.dc.b 0,0,4,4,0      ; ASCII: 44 / CHAR: ,
.dc.b 0,0,31,0,0     ; ASCII: 45 / CHAR: -
.dc.b 0,0,0,0,2      ; ASCII: 46 / CHAR: .
.dc.b 8,8,4,2,2      ; ASCII: 47 / CHAR: /
.dc.b 31,25,21,19,31 ; ASCII: 48 / CHAR: 0
.dc.b 4,6,4,4,14     ; ASCII: 49 / CHAR: 1
.dc.b 15,16,14,1,31  ; ASCII: 50 / CHAR: 2
.dc.b 31,16,14,16,31 ; ASCII: 51 / CHAR: 3
.dc.b 1,1,5,31,4     ; ASCII: 52 / CHAR: 4
.dc.b 31,1,15,16,15  ; ASCII: 53 / CHAR: 5
.dc.b 31,1,31,17,31  ; ASCII: 54 / CHAR: 6
.dc.b 31,16,8,4,4    ; ASCII: 55 / CHAR: 7
.dc.b 31,17,31,17,31 ; ASCII: 56 / CHAR: 8
.dc.b 31,17,31,16,31 ; ASCII: 57 / CHAR: 9
.dc.b 4,0,0,0,4      ; ASCII: 58 / CHAR: :
.dc.b 4,0,0,4,4      ; ASCII: 59 / CHAR: ;
.dc.b 8,4,2,4,8      ; ASCII: 60 / CHAR: <
.dc.b 0,31,0,31,0    ; ASCII: 61 / CHAR: =
.dc.b 2,4,8,4,2      ; ASCII: 62 / CHAR: >
.dc.b 6,9,4,0,4      ; ASCII: 63 / CHAR: ?
.dc.b 31,17,29,1,31  ; ASCII: 64 / CHAR: @
.dc.b 31,17,17,31,17 ; ASCII: 65 / CHAR: A
.dc.b 31,17,15,17,31 ; ASCII: 66 / CHAR: B
.dc.b 31,1,1,1,31    ; ASCII: 67 / CHAR: C
.dc.b 15,17,17,17,15 ; ASCII: 68 / CHAR: D
.dc.b 31,1,15,1,31   ; ASCII: 69 / CHAR: E
.dc.b 31,1,15,1,1    ; ASCII: 70 / CHAR: F
.dc.b 31,1,25,17,31  ; ASCII: 71 / CHAR: G
.dc.b 17,17,31,17,17 ; ASCII: 72 / CHAR: H
.dc.b 31,4,4,4,31    ; ASCII: 73 / CHAR: I
.dc.b 24,16,16,17,31 ; ASCII: 74 / CHAR: J
.dc.b 17,9,7,9,17    ; ASCII: 75 / CHAR: K
.dc.b 1,1,1,1,31     ; ASCII: 76 / CHAR: L
.dc.b 17,27,21,17,17 ; ASCII: 77 / CHAR: M
.dc.b 17,19,21,25,17 ; ASCII: 78 / CHAR: N
.dc.b 14,17,17,17,14 ; ASCII: 79 / CHAR: O
.dc.b 15,17,15,1,1   ; ASCII: 80 / CHAR: P
.dc.b 31,17,17,31,4  ; ASCII: 81 / CHAR: Q
.dc.b 15,17,15,17,17 ; ASCII: 82 / CHAR: R
.dc.b 31,1,31,16,31  ; ASCII: 83 / CHAR: S
.dc.b 31,4,4,4,4     ; ASCII: 84 / CHAR: T
.dc.b 17,17,17,17,31 ; ASCII: 85 / CHAR: U
.dc.b 17,17,10,10,4  ; ASCII: 86 / CHAR: V
.dc.b 17,17,21,21,10 ; ASCII: 87 / CHAR: W
.dc.b 17,10,4,10,17  ; ASCII: 88 / CHAR: X
.dc.b 17,17,10,4,4   ; ASCII: 89 / CHAR: Y
.dc.b 31,8,4,2,31    ; ASCII: 90 / CHAR: Z
.dc.b 6,2,2,2,6      ; ASCII: 91 / CHAR: [
.dc.b 2,2,4,8,8      ; ASCII: 92 / CHAR: \
.dc.b 6,4,4,4,6      ; ASCII: 93 / CHAR: ]
.dc.b 0,4,10,0,0     ; ASCII: 94 / CHAR: ^
.dc.b 0,0,0,0,31     ; ASCII: 95 / CHAR: _
.dc.b 0,2,4,0,0      ; ASCII: 96 / CHAR: `
.dc.b 31,31,31,31,31 ; ASCII: 97 / CHAR: a

 

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// 6x6 CHARACTER SET BY RADICAL BRAD
////////////////////////////////////////////////////////////////////////////////////////////////////////

CHARSET:
.dc.b 0,0,0,0,0,0 ; ASCII:32 / CHAR: 
.dc.b 0,6,47,6,0,0 ; ASCII:33 / CHAR:!
.dc.b 0,6,0,6,0,0 ; ASCII:34 / CHAR:"
.dc.b 20,62,20,62,20,0 ; ASCII:35 / CHAR:#
.dc.b 46,42,63,42,58,0 ; ASCII:36 / CHAR:$
.dc.b 38,22,8,52,50,0 ; ASCII:37 / CHAR:%
.dc.b 52,42,60,24,40,0 ; ASCII:38 / CHAR:&
.dc.b 0,6,0,0,0,0 ; ASCII:39 / CHAR:'
.dc.b 0,0,28,54,34,0 ; ASCII:40 / CHAR:(
.dc.b 34,54,28,0,0,0 ; ASCII:41 / CHAR:)
.dc.b 36,24,14,24,36,0 ; ASCII:42 / CHAR:*
.dc.b 8,8,62,8,8,0 ; ASCII:43 / CHAR:+
.dc.b 32,48,0,0,0,0 ; ASCII:44 / CHAR:,
.dc.b 8,8,8,8,8,0 ; ASCII:45 / CHAR:-
.dc.b 32,0,0,0,0,0 ; ASCII:46 / CHAR:.
.dc.b 48,24,12,6,0,0 ; ASCII:47 / CHAR:/
.dc.b 0,28,34,34,28,0 ; ASCII:48 / CHAR:0
.dc.b 0,36,62,32,0,0 ; ASCII:49 / CHAR:1
.dc.b 58,42,42,42,46,0 ; ASCII:50 / CHAR:2
.dc.b 34,42,42,42,62,0 ; ASCII:51 / CHAR:3
.dc.b 14,8,8,62,8,0 ; ASCII:52 / CHAR:4
.dc.b 46,42,42,42,58,0 ; ASCII:53 / CHAR:5
.dc.b 62,42,42,42,58,0 ; ASCII:54 / CHAR:6
.dc.b 34,18,10,6,2,0 ; ASCII:55 / CHAR:7
.dc.b 62,42,42,42,62,0 ; ASCII:56 / CHAR:8
.dc.b 0,46,42,42,62,0 ; ASCII:57 / CHAR:9
.dc.b 0,0,20,0,0,0 ; ASCII:58 / CHAR::
.dc.b 0,32,20,0,0,0 ; ASCII:59 / CHAR:;
.dc.b 0,0,8,20,34,0 ; ASCII:60 / CHAR:<
.dc.b 20,20,20,20,20,0 ; ASCII:61 / CHAR:=
.dc.b 34,20,8,0,0,0 ; ASCII:62 / CHAR:>
.dc.b 6,1,45,6,0,0 ; ASCII:63 / CHAR:?
.dc.b 30,35,25,53,62,0 ; ASCII:64 / CHAR:@
.dc.b 60,10,10,10,60,0 ; ASCII:65 / CHAR:A
.dc.b 62,42,42,42,28,0 ; ASCII:66 / CHAR:B
.dc.b 28,34,34,34,34,0 ; ASCII:67 / CHAR:C
.dc.b 62,34,34,34,28,0 ; ASCII:68 / CHAR:D
.dc.b 62,42,42,42,34,0 ; ASCII:69 / CHAR:E
.dc.b 62,10,10,10,2,0 ; ASCII:70 / CHAR:F
.dc.b 28,34,42,42,24,0 ; ASCII:71 / CHAR:G
.dc.b 62,8,8,8,62,0 ; ASCII:72 / CHAR:H
.dc.b 34,34,62,34,34,0 ; ASCII:73 / CHAR:I
.dc.b 16,34,34,30,2,0 ; ASCII:74 / CHAR:J
.dc.b 62,8,20,34,0,0 ; ASCII:75 / CHAR:K
.dc.b 0,62,32,32,32,0 ; ASCII:76 / CHAR:L
.dc.b 62,4,8,4,62,0 ; ASCII:77 / CHAR:M
.dc.b 60,2,2,2,60,0 ; ASCII:78 / CHAR:N
.dc.b 28,34,34,34,28,0 ; ASCII:79 / CHAR:O
.dc.b 62,10,10,4,0,0 ; ASCII:80 / CHAR:P
.dc.b 28,34,50,60,32,0 ; ASCII:81 / CHAR:Q
.dc.b 62,10,10,26,36,0 ; ASCII:82 / CHAR:R
.dc.b 36,42,42,42,18,0 ; ASCII:83 / CHAR:S
.dc.b 2,2,62,2,2,0 ; ASCII:84 / CHAR:T
.dc.b 30,32,32,32,30,0 ; ASCII:85 / CHAR:U
.dc.b 6,24,32,24,6,0 ; ASCII:86 / CHAR:V
.dc.b 14,48,24,48,14,0 ; ASCII:87 / CHAR:W
.dc.b 34,20,8,20,34,0 ; ASCII:88 / CHAR:X
.dc.b 2,4,56,4,2,0 ; ASCII:89 / CHAR:Y
.dc.b 34,50,42,38,34,0 ; ASCII:90 / CHAR:Z
.dc.b 0,0,0,62,34,0 ; ASCII:91 / CHAR:[
.dc.b 6,12,24,48,0,0 ; ASCII:92 / CHAR:\
.dc.b 34,62,0,0,0,0 ; ASCII:93 / CHAR:]
.dc.b 0,4,2,2,4,0 ; ASCII:94 / CHAR:^
.dc.b 32,32,32,32,32,0 ; ASCII:95 / CHAR:_
.dc.b 0,0,4,8,0,0 ; ASCII:96 / CHAR:`
.dc.b 24,36,20,56,0,0 ; ASCII:97 / CHAR:a
.dc.b 30,40,40,16,0,0 ; ASCII:98 / CHAR:b
.dc.b 24,36,36,0,0,0 ; ASCII:99 / CHAR:c
.dc.b 16,40,40,30,0,0 ; ASCII:100 / CHAR:d
.dc.b 24,44,44,8,0,0 ; ASCII:101 / CHAR:e
.dc.b 0,60,18,4,0,0 ; ASCII:102 / CHAR:f
.dc.b 36,42,30,0,0,0 ; ASCII:103 / CHAR:g
.dc.b 62,8,48,0,0,0 ; ASCII:104 / CHAR:h
.dc.b 0,58,0,0,0,0 ; ASCII:105 / CHAR:i
.dc.b 16,32,26,0,0,0 ; ASCII:106 / CHAR:j
.dc.b 62,16,44,32,0,0 ; ASCII:107 / CHAR:k
.dc.b 0,62,0,0,0,0 ; ASCII:108 / CHAR:l
.dc.b 56,8,24,8,48,0 ; ASCII:109 / CHAR:m
.dc.b 48,8,8,48,0,0 ; ASCII:110 / CHAR:n
.dc.b 16,40,40,16,0,0 ; ASCII:111 / CHAR:o
.dc.b 56,20,20,8,0,0 ; ASCII:112 / CHAR:p
.dc.b 8,20,20,56,0,0 ; ASCII:113 / CHAR:q
.dc.b 60,8,4,0,0,0 ; ASCII:114 / CHAR:r
.dc.b 44,52,0,0,0,0 ; ASCII:115 / CHAR:s
.dc.b 8,60,40,0,0,0 ; ASCII:116 / CHAR:t
.dc.b 24,32,32,24,0,0 ; ASCII:117 / CHAR:u
.dc.b 8,16,32,16,8,0 ; ASCII:118 / CHAR:v
.dc.b 24,32,16,32,24,0 ; ASCII:119 / CHAR:w
.dc.b 40,16,40,0,0,0 ; ASCII:120 / CHAR:x
.dc.b 44,48,28,0,0,0 ; ASCII:121 / CHAR:y
.dc.b 36,52,44,36,0,0 ; ASCII:122 / CHAR:z
.dc.b 0,0,8,62,34,0 ; ASCII:123 / CHAR:{
.dc.b 0,0,62,0,0,0 ; ASCII:124 / CHAR:|
.dc.b 34,62,8,0,0,0 ; ASCII:125 / CHAR:}
.dc.b 16,8,24,16,8,0 ; ASCII:126 / CHAR:~

 

The 5x5 set has only the minimal needed for things like game instructions and high scores.

This is what I used in Quarl-85 to keep memory use as low as possible.

 

Cheers!

Brad

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

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

AtomicZombie wrote:

Nicely done... congrats!

What would the Frenchman say????

 

I think your project certainly deserves a full thread, but never worry about "HiJacking"... just a couple of hackers talking!

Quark-85 also uses the same size font. I made a few different ones (5x5 and 6x6). Feel free to try them out...

 

The 5x5 set has only the minimal needed for things like game instructions and high scores.

This is what I used in Quarl-85 to keep memory use as low as possible.

 

Cheers!

Brad

 

Hi,

 

I've made nice python generating my fonts (can be found from OctaPentaVeega git too) and I was planning to make 6x10 pixel font for my VGA as it would make it nicely even with the screen resolution (each vertical pixel drawn 3 times = 16 * 3 * 10 = 480) :)

 

My biggest problem is now again clock deprivation because drawing pixels "live" is slower than precalculating and just pushing data through... and because I can't buffer UART I need to handle that "immediately" (not to mention the problem of sampling UART @ 9600 bps within 31.45kHz vertical refresh loop).... between drawing each horizontal line I seem to have ~127 clock cycles for UART sampling, ANSI parsing and screen scrolling.

 

UART and ANSI parsing works, but scrolling is the hardest part... still working on that

 

Cheers,

 

//Jartza
Jari Tulilahti

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

Jartza wrote:

The only downside is that in my 6x8 character font, the last of the 6 pixels is reaaaaallly wide, I'm not sure if that's a problem, because my normal font doesn't use that pixel, only those "line drawing" characters.

How wide exactly is " reaaaaallly wide " ?

eg if it is ~2 pixels, You can always use that 'last pixel' as a part of the font, just implicit background.

 

Jartza wrote:

 Even 32x20 lines of text, although the last 4 lines are just repeating the first 4 because all of the memory is used :)

 

Maybe it is time to bump to a larger part ? ;)

 

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

Who-me wrote:

How wide exactly is " reaaaaallly wide " ?

eg if it is ~2 pixels, You can always use that 'last pixel' as a part of the font, just implicit background.

 

Well, it's wide. But it's no problem for normal characters and special characters I can always redraw to take that in account...

 

Who-me wrote:

Maybe it is time to bump to a larger part ? ;)

 

 

What, bigger part? why on earth? :D

 

https://drive.google.com/file/d/...

//Jartza
Jari Tulilahti

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

Hiya!

 

It seems my 6x10 font needs still some fixing, but at least it's drawn correctly....

 

:)

 

https://drive.google.com/file/d/...

 

Cheers,

//Jartza
Jari Tulilahti

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

This is what I used in Quarl-85 to keep memory use as low as possible.

I think I like that name better.  Is the 'L' for 'Lucas'?  ;-)

"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

For the UART buffer, perhaps you have space in some registers, remember that they are memory mapped on a tiny 85.

 

Perhaps you can same some RAM bu only her 128 chars. (but perhaps it will be to slow)

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