Avr or 6502 for 8bit gaming

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

I recently made a simple 2d shooting game that the Arduino can output on a vga monitor (640×480 @60Hz).

Have a look at the pong code in this website
http://www.gammon.com.au/forum/?id=11608. Now i tried Alot but couldn't make the pixel any smaller. Can someone plz suggest an improvement for the code that could output the array data faster on portd of the Arduino uno

The video data is a 30×40 char array. It just has 2 colours pure white (1) and pure black (0). At first i wasn't sure whether the atmega328 could do this or not but turns out it can!! But 1 pixel is approx 1cm×1cm on my display (measured using a scale). Retro consoles like the NES used 1Mhz 6502 whereas the atmega can go upto 20Mhz so it looks like the avr is much more powerful. So my question is: what is the smallest pixel the avr can output? And which chip has the maximum ram for storing the video data. My next goal is to run space invaders. In the image attached below that small square is the smallest pixel. How can i make single pixel even more smaller.

I don't want to use gameduino

Attachment(s): 

This topic has a solution.
Last Edited: Thu. Feb 11, 2021 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 

I presume you already know about Brad Graham ("AtomicZombie" on Freaks) and his Lucid Science?

 

http://www.lucidscience.com/pro-...

 

 

While I guess it's vaguely possible that others have been able to push an AVR beyond this limit I think most folks accept that brad gets at least as much out of AVR video as anyone ever has.

 

Of course when I was involved in home computers in the 80's (I worked for Amstrad in CPC464/664/6128) which had graphics such as:

 

 

The CPU itself was fairly "lowly" (4MHz Z80 in our case - with contention on the video RAM extending cycles to a multiple of 4 T-states so a bit under 4MHz on that particular 16K) but the design was helped by a 6845 video controller (also in the BBC Micro I think?) so the "leg work" was handed off from the CPU to some other support chip. Dunno what the modern equivalent of a 6845 (if there even is one?) might be? Anyway SNES and so on did the same - they had video generators that were silicon separate to the CPU.

 

One could envisage an AVR design where the video bit was done on separate silicon and the AVR just has some kind of "set pixel x,y to color xxx" dialog with it but the video generator just relentlessly pumps the Hsyncs and Vsyncs to generate the image.

 

In fact I'm pretty sure there was a product that did just that - actually done by someone who used to be a regular on Freaks. I thought it was called "AVR-TV" but cannot find it now.

 

BTW a quick Google also leads to:

 

https://www.avrfreaks.net/projec...

 

though clearly that is not in Brad's league.

 

EDIT: Wikipedia says https://en.wikipedia.org/wiki/Ni... that the NES had a chip made by Ricoh called PPU - Picture Processing Unit. More about it here: https://ultimatepopculture.fando...

Last Edited: Tue. Feb 9, 2021 - 10:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

If you opt for NTSC or PAL instead of VGA your life will be easier.   The old TV standards have half the H-Sync rate of VGA so you have much longer per pixel.

 

If you are keen to do retro game things on an AVR then check out the Uzebox.

 

As far as semi modern equivalents of a MC6845 - Maybe the http://www.vlsi.fi/en/products/v... might/would fit.

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

My first PC (cga video card) also used a 6845. :)

 

Total resolution also depends of how many colours you want. 

And how big a part of the time can spend on the video creation. (Perhaps take a look at ZX80 and ZX81(fast mode))

 

If just BW max output is (using SPI) is 1/2 clk speed, with a 16MHz thats 8MHz the same as a C64.

 

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

Some LCD monitors will accept 15.75kHz, which will allow you to display twice the video resolution.

http://15khz.wikidot.com/

 

Another option is a LCD TV, as they almost all have Component Y/Pr/Pb inputs that will sync to a 15.75kHz horizontal scan signal.

 

If you stick with standard VGA with a 31.5kHz horizontal scan rate, using SPI at 1/2 the MCU clock rate will give you 256 horizontal pixels if you clock the avr at 20Mhz.

 

p.s. you can actually get better resolution out of a t85 or t84 with USI, since it's possible to clock data at the same frequency as the MCU.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

Last Edited: Tue. Feb 9, 2021 - 05:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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

Here is an amazing video of some 3D graphics & sound done on an AVR

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

 

https://www.linusakesson.net/sce...

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

The AVR or main CPU does not form the pixels.  The display controller IC does.  In the case of your game using VGA, then the AVR CPU on the Arduino is acting as the display controller IC.  PCs that used VGA would write video pixel data to a display IC on a video card that was mounted into one of the PC's expansion slots.

 

I recommend to not use the AVR or 6502 for running a display.  The "Blue Pill" development board looks like an Arduino Nano and costs about the same price.  It has a 32-bit STM32F104 ARM Cortex M3 processor that runs many times faster than the AVR found on the Arduino and also has much more memory available for displaying on a VGA monitor.  The "Black Pill" contains a 100MHz ARM Cortex M4F CPU with 512kB Flash and 128kB of RAM.   It costs about $5 USB and programs using Arduino.

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

Wow this was extremely helpful. Thanks alot. Yes i do know about lucidscience but i guess he just displayed still images not sure though will recheck. Im still a high school student and i hv a decent knowledge about hardware and assembly. But programming is not my strength... It would be great if you could just provide me a reference or a short explanation how a 2d character array is pushed onto a digital pin? (Basically what happens inside the hardware)

I also found this video on YouTube https://youtu.be/OYIEQlPotIg he made a vga video card using Arduino nano and 8bit parallel in serial out shift register for his breadboard computer. code available on GitHub
https://www.github.com/slu4coder/ArduinoVGA/tree/master/Arduino_VGA_Terminal_v1.06.ino
Im still trying to understand how the code works.

Last Edited: Tue. Feb 9, 2021 - 08:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah ik but vga is what i have at home. Thanks for the suggestions will definitely consider this

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

Yes i tried spi but i could just get it to display the data that was stored in flash memory. Is there a way to display a video? I want something similar to space invaders.
Current the problem i am facing is that the smallest size for 1 pxl is 1cm×1cm as in the image i attached in the main question. How can i make that pixel smaller?

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

Dhruv wadhwa wrote:
Retro consoles like the NES used 1Mhz 6502 whereas the atmega can go upto 20Mhz so it looks like the avr is much more powerful.
28.6 MHz for mega644P (Uzebox); a follow-on would be AVR128DB.

Dhruv wadhwa wrote:
And which chip has the maximum ram for storing the video data.
XMEGA384C3 (Cliff's first post) though XMEGA128A1U has EBI (XMEGA have 16MB address spaces); fyi, most XMEGA have DMA.

Dhruv wadhwa wrote:
Also plz tell me which is 6502 a better choice for this purpose?
Consider 65C816 as an alternative.

Dhruv wadhwa wrote:
If yes then why?
FPGA (attach a display controller to the CPU via an arbitrated bus, FIFO, dual-port RAM, pseudo dual-port RAM, etc)

 


Project Pages | Uzebox Wiki

What are the AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128 ?? | AVR Freaks

Migration from the megaAVR® to AVR® Dx Microcontroller Families

 

W65C816S 8/16-bit MPU | The Western Design Center, Inc.

...

  • Valid Data Address (VDA) and Valid Program Address (VPA) for cycle steal DMA implementation

...

 

FPGA Microcontrollers | The Western Design Center, Inc.

Alorium Technology | FPGA Development Boards | Arduino Compatible

 

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

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

likewise by Vancouver Design Center - Home (Epson)

 

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

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

Simonetta wrote:
I recommend to not use the AVR or 6502 for running a display.
Some PIC24 and PIC32 contain a graphics LCD controller.

Embedded Graphics that Dazzle Your Customers | Microchip Technology

 

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

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

Dhruv wadhwa wrote:
It would be great if you could just provide me a reference or a short explanation how a 2d character array is pushed onto a digital pin? (Basically what happens inside the hardware)
Googling around this looks like a pretty good explanation:

 

http://www.cs.ucr.edu/~jtarango/...

 

But I'm not sure it's really much different to the details at the link in your first post?

 

Displaying stuff (VGA probably) is basically a two stage process. First something creates a RAM buffer that is 640x480 with maybe 3 bytes per pixel (which is a lot of RAM for an AVR!!) and each of the pixels is set to some RGB value to make up the picture.

 

The second stage is that there is then an unstoppable process that simply scans all the data from that buffer and outputs the values at exactly the right moment to create the picture, In addition to analog wires for R, G and B there are two other important signals for Horizontal Sync and Vertical Sync. The "new picture" (as far as the VGA display device is concerned) is when there is a pulse on Vsync to basically say "starting from the top". As you will probably want to display 50Hz or 60Hz then that is the frequency of Vsync. The picture itself is then made up of lines (probably 480) so the Hsync is a pulse that says "start at the left to display a new line". After that the RAM is scanned for the data that makes up that line and, dividing the time between one Hsync pulse and the next into the 640 horizontal resolution the different values of R, G and B that make up the pixels on that line are output. The RGB are analog so the 0..255 held for each of R, G and B needs to map to an RGB pin voltage of 0.0V .. 0.7V. The "simple" case is to do "mono" (so R, G and B are all the same for each pixel location) and they are not a varying value but simply 0V or 0.7V - basically an IO line through a voltage divider to bring 0..3.3V or 0..5V down to 0..0.7V

 

Things are further complicated as the H/V scan is not as simple as H then pump the pixels. There is a delay after Hsync ("back porch") and then 640 lots of data then another delay ("front porch") at the end of the line - these are effectively the "borders" around the picture. The same goes for vertical borders after Vsync so there's also vertical back porch and vertical front porch.

 

Actually that first link of yours is a really good explanation of all this.

 

The ultimate limit is "how fast can the AVR go to drive a wire between 0 and 0.7V". IF you do it digital (mono) rather than analog (colour) then it's basically how fast can an IO line toggle. As shown the fastest way to do this is to use the SPI peripheral as you can put in 8 pixel values then leave it to it to pump them out while your code does the jobs of getting more data and working out where it is in the display sequence and where Vsync or Hsync are due to be pulsed in the near future.

 

As I say, home computer and consoles of the 80's and 90's had "helpers" for this. They only had to create a sea of 0's and 1's in the RAM buffer then all the "scanning stuff" was done by a separate piece of silicon like a 6845 or the NES/Ricoh PPU or sometimes an FPGA/ULA/gate array. When Amstrad upgraded CPC464, 664, 6128 to CPC464+/CPC6128+ we actually designed an ASIC that contained an exact simulation of the existing 6845 (for backward compatibility modes) but we added extra modes with more colour/pixel resolution and things like hardware sprites as gate technology was a few years advanced beyond something like 6845 so things could go faster (and faster means "more pixels" / "more colours").

 

I still think if one wanted "proper video" with an AVR as the "game engine" the way to do this would be to use some other timing pulse generator/DMA controller to automate the Hsync/Vsync/R/G/B signal generation. In fact you could use something "fast" like a Beagle or Blue Pill or ESP8266 or ESP32 or Teensy 4 that might well have things like DACs (you need these to convert RGB values to 0 .. 0.7V voltages quickly) to basically act as a "souped up 6845"

 

BTW not for VGA but for LCD panels quite a few ARM based SoC's have an LCD video generating DMA engine in them that does all the H, V, porches, etc with no CPu intervention once the display process has started. The chances are you have one of these in your pocket right now !

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Dhruv wadhwa wrote:
Yes i tried spi but i could just get it to display the data that was stored in flash memory. Is there a way to display a video? I want something similar to space invaders. Current the problem i am facing is that the smallest size for 1 pxl is 1cm×1cm as in the image i attached in the main question. How can i make that pixel smaller?

 

Read up on video game programming with "tiles" and "sprites".  The aliens in space invades could be drawn with an 8x8 bitmap that you read from flash and write to the VGA output using SPI.  So for example:

00011000      XX

00111100     XXXX

01111110    XXXXXX

11011011   XX XX XX

11111111   XXXXXXXX

01011010    X XX X

10000001   X      X

 

As I said above, you can get 256 pixels per line, which is enough for 16 aliens on the screen with 8 pixels between them.  I'd double-up the scan lines to make the full screen resolution 256x240.

With SPI running at half the AVR clock rate, you'll have 16 cycles to between reloads of SPDR.  In that time you could read a tile index from SRAM (ld rd, X+) in 2 cycles, 1 or 2 cycles to add the index to a base pointer for the tile stored in Z, 3 cycles to load from flash (lpm), 1 cycle to write to SPDR, 2 cycles to branch at the end of the loop, and 6 cycles left to do loop control.

 

"Racing the beam" would be a good book for you to read.  Here's a video that should help you too:

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

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Moved to general programming

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

An excellent explanation to the concepts by Ben Eater is here: https://www.youtube.com/watch?v=... (though I would take exception to some of his methods!) It's the first in a series which leads into the subject gradually and will give you enough to follow on with more colours or more pixels.

 

One thing he doesn't mention is that with a 6502 you can interleave processor access and display access to the display memory with full speed running from both. The 6502 only access memory on a particular phase of the system clock and so one can read the memory to display it without interference by timing on the opposite phase - which is what all the 6502-based micros did.

 

Neil

 

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

If monochrome is not your thing (using SPI and 1/2 MCU clock) you can still use an 3:3:2 DAC and use OUT instructions to drive an 8 bit port at 3 clocks per pixel with 8 bit wide tiles.

 

You can only change the colour once per scanline though.

 

If you use TV frequency (15Khz) display you will get 480 pixels across the screen.

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

A post I wrote ten years ago still works for PAL, NTSC with a bit of playing - with a 16MHz clock. https://www.avrfreaks.net/forum/...

 

For VGA, basically everything happens twice as fast, so either twice the clock speed, or half the characters in a line. (There are differences in the way the output works, but the basic generation is very similar).

 

Neil

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

barnacle wrote:

A post I wrote ten years ago still works for PAL, NTSC with a bit of playing - with a 16MHz clock. https://www.avrfreaks.net/forum/...

 

For VGA, basically everything happens twice as fast, so either twice the clock speed, or half the characters in a line. (There are differences in the way the output works, but the basic generation is very similar).

 

Neil

Nice tutorial.  I never noticed it before.

You seem to imply that it's possible to output the video signal with one AVR pin, but don't go into details.  I think it would work with a resistor divider between VCC and GND to give 0.3V for black level, then output low would be sync, input (hiZ) would be black, and output high would be white.

 

I'm also pretty sure you can output SPI back-to-back with an assembler loop that writes to SPDR every 16 cycles.  Another option if you are using something like a m328 is the UART in SPI mode.

 

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

With the chip I was using, it was impossible, even with much manipulation of machine code, to get back to back SPI without that extra pixel. It wasn't a timing issue with the code; it was the SPI unit itself. It was a long time ago, but I seem to recollect that if you reloaded the SPI output register before it finished, it garbaged the byte being transmitted.

 

That code was based on the assumption of an RGBS output - to a SCART connector, I think - so independent RGB (a resistor bridge on the output pin with the junction going to RGB) and another to the sync line. Composite output just needs resistors in the right place to raise the output to 0.3v (probably 0.6v, unterminated, but accounting for the 75 ohm termination in the input).

 

I think something similar might be possible on the generic ARM chip but I'd have to look at the thing in more detail.

 

Neil

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

Use SPI in master mode and provide CLK from a timer channel.

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

Thanks alot this answered my question completely. Becoz i want to keep the retro vibe i have decided that i will design a vga video card using esp32 or discreet logic gates similar to what ben eater did. (Ben eater is a YouTuber who builds and explains his 8bit breadboard comp. And graphics card)

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

Thanks for the thorough explanation i guess this will work just perfect, will definitely try this!

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

That post was amazing!!! Helped alot, thanks.

Last Edited: Thu. Feb 11, 2021 - 10:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think this can be done on atmega328. It just has 2kb of ram, it can't hold 256×240 pixels. I'll have to go for xmega, am i right?

 

what i have currently done is bit shifted the pixel data towards right by 4 so that it is duplicated 4 times. if i dont duplicate the data then i can get a pretty good resolution but then my PXL_DATA array is restricted to 40x30 due to limited ram. please let me know if im wrong and if its possible for the atmega328 in particular to output a better resolution. i have also attached my code below. PS: i did not use spi. here is my code:

 

 

#define nop __asm__("nop \n")

#define SCREEN_W 40
#define SCREEN_H 30

 

char PXL_DATA [SCREEN_H][SCREEN_W]; 
int  lineCounter;
char skipLine;
char PXL_OUT;
char dy;
char enemyX;
char enemyY;

float score;

ISR(TIMER1_OVF_vect)
  {lineCounter = 0;}

ISR(TIMER2_OVF_vect)
  {
    sei();
    __asm__("sleep \n");
  }

ISR(TIMER2_COMPB_vect)
{
  register char  columnCounter;
  register char* rowPtr;

  switch (PXL_OUT){
    case 1:
    rowPtr = &(PXL_DATA[(lineCounter - 35)>>4][0]);
    columnCounter = SCREEN_W;

    while(columnCounter--){
      PORTD = (*(rowPtr++)<<PD2);
      nop;
    }
    nop;
    nop;
    nop;
    PORTD = 0;
    break;
  }

  lineCounter++;
  skipLine = !skipLine;

  if ( skipLine && (lineCounter >= 35) && (lineCounter < 515) ){
    PXL_OUT = 1;
  }
  else{
    PXL_OUT = 0;
  }
}

void setup() {
  cli();                   //DISABLE INTERRUPTS
  PORTD = 0;
  pinMode(10,OUTPUT);    
  pinMode(3,OUTPUT);
  pinMode(2,OUTPUT);
  
  pinMode(A0,INPUT);
  pinMode(12, INPUT);
 
  TCCR1A = 0b00100011;     //PIN D10 OUTPUT, FAST PWM MODE 
  TCCR1B = 0b00011101;     //FAST PWM, PRESCALER OF 1024
  TIMSK1 = 0b00000001;     //OVERFLOW INTERRUPT ENABLE
  TIFR1  = 0b00000001;     //CLEAR OVERFLOW FLAG
  //TCNT1  = 0;            //rst t1
  TCCR2A = 0b00100011;     //PIN D3 OUTPUT, FAST PWM MODE
  TCCR2B = 0b00001010;     //FAST PWM, PRESCALER OF 8
  TIMSK2 = 0b00000101;     //OVERFLOW INTERRUPT ENABLE
  TIFR2  = 0b00000101;     //CLEAR OVERFLOW FLAG
  //TCNT2  = 0;            //rst t2 
  OCR1A  = 259;            //SET FREQ OF T1
  OCR1B  = 0;              //VSYNC PULSE DURATION
  OCR2A  = 63;             //SET FREQ OF T2
  OCR2B  = 7;              //HSYNC PULSE DURATUIN
  SMCR = bit(SE);
  memset(PXL_DATA, 0, sizeof(PXL_DATA));
  lineCounter = 0;
  enemyX =random(1,36);
  enemyY =random(3,25);
  score=1;
  sei();
}

void gameCode(){  
}

void loop() {
  char col = (analogRead(A0)/29);
  bool shoot = digitalRead(12);
  bool bulletFired;
  char bulletX;
  char bulletY;

  
  
  if (shoot == 1){
    bulletFired = 1;
    dy = 0.0;  
    bulletX = col;
  }
  if ((bulletFired==1)&&(dy<=27)){
    bulletY = 27-dy;
    dy = dy + 1;
  } 
  if ( (bulletY<=0)&&(dy>=27) ){
    bulletFired = 0;
    bulletY=31;
  }
  if ( (bulletX==(enemyX-1))&&(bulletY==enemyY) ){
    enemyX=random(1,36);
    enemyY=random(3,25);
    bulletFired = 0;
    dy = 27;
    score = score + 4;
    if (score>=37){
      score=0;
    }
  }
  

  char r, c;

  
  for (r = 0; r < SCREEN_H; r++) {
    for (c = 0; c < SCREEN_W; c++) {
      if ((r >= 28) &&
        (r < 28 + 1) &&
        (c >= col) &&
        (c < col + 3)) {
        PXL_DATA[r][c] = 0;
      }
      else if ((r >= 27) &&
        (r < 27 + 1) &&
        (c >= col+1) &&
        (c < col + 2)) {
        PXL_DATA[r][c] = 0;
      }
      else if ((bulletFired==1)&&(r >= bulletY) &&
        (r < bulletY + 1) &&
        (c >= bulletX+1) &&
        (c < bulletX + 2)) {
        PXL_DATA[r][c] = 0;
      }
      else if ((r >= enemyY) &&
        (r < enemyY + 1) &&
        (c >= enemyX) &&
        (c < enemyX + 1)) {
        PXL_DATA[r][c] = 0;
      }
      else if ((r >= 0) &&
        (r < 0 + 1) &&
        (c >= 0) &&
        (c < 0 + score)) {
        PXL_DATA[r][c] = 0;
      }
      else {
        PXL_DATA[r][c] = 1;
      }      
    }
  } 
}

Attachment(s): 

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

As said before (#4) take a look at ZX81, it had 1K RAM ! (and some of the games for it)

 

You build your things on the fly (only remember a pointer of where it is), there are not RAM for a real screen "picture"

 

A video picture is only on for about 40% of the time!

(A ZX81 in slow mode, only run code between frames as I remember it's about 25% of the time)

 

Add: before any one kill me most games needs 16KRAM added. (both program and video had to be in RAM, not like on an AVR)

or for the timex that had 2k RAM

Last Edited: Fri. Feb 12, 2021 - 10:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ohhh okay i will check that out too

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

Dhruv wadhwa wrote:
It just has 2kb of ram, it can't hold 256×240 pixels. I'll have to go for xmega, am i right?
If you are holding a mono (1 bit per pixel) image then I calculate that 256x240 would require 7,680 bytes. It's true that before you get to Xmega there aren't that many AVR that could hold that. (even if they had 8K there's virtually nothing left over for doing much else) but the good news is the ATmega1284P. It's a "traditional" mega AVR but very unusually it has 16KB of RAM.

 

Of course the other thing Xmega brings to the party is breaking the 16/20MHz upper speed limit. Early tiny/mega are limited to 16MHz and later ones (like 328P and 1284P) have an upper limit of 20MHz (though you can "over-clock" a little). But if you switch to Xmega the upper limit is 32MHz. What's more Brad at Lucid Science has over-clocked them to close to 64MHz.

 

As speed = more pixels/more colour then you basically want the fastest micro you can get.

 

(of course there are chips beyond even AVR/Xmega if you want some real speed! I use a 600MHz one for $20 that runs the SPI at 60MHz for example)

 

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

Which is that 600Mhz one you are talking about?

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


Dhruv wadhwa wrote:
Which is that 600Mhz one you are talking about?

 

https://www.pjrc.com/teensy/#:~:...

 

Teensy 4 or 4.1 have a 600MHz (actually it can be clocked to 1GHz)  IMXRT1062  CPU though it doesn't really matter what the CPU is as you generally program them with a special version of Arduin (Teensyduino) so for most things you are not dealing direct with the CPU. 

 

Even for video gen you may be able to work with the Arduino library code but, failing that you can look at how they drive the SPI in the core/library support.

 

Having said that did you know that this $4 board was launched in the last month: 

 

https://www.raspberrypi.org/blog...

 

That is two 133MHz ARM M0+ cores for four bucks. Incredible. What's more there's a VGA "carrier" board for it:

 

 

The github link leads to:

 

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

Yes i do know about this board. Someone even emulated NES and ran mario on this https://www.hackster.io/news/ben-stragnell-gets-super-mario-bros-running-on-the-raspberry-pi-pico-in-a-custom-nes-emulator-6dfcc3533ee7

Its great for my future project but for the current one i want to use avr at its full potential

Last Edited: Fri. Feb 12, 2021 - 10:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dhruv - my AVR example in the tutorial got by with 48 * 16 = 768 bytes of ram, because it was a text only output: any particular line indexed into a lookup character table which provided the bit pattern for that line, and that pattern was output through the SPI. So the screen has a resolution of 384 horizontal pixels by 192 vertical (which is reasonable for a PAL display) but doesn't allow individual pixels to be driven.

 

Neil

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

Dhruv wadhwa wrote:
I'll have to go for xmega, am i right?
No as there's SPI-attached display controllers with internal frame RAM; otherwise, yes.

ZX81 ULA arbitrates the the video frame DRAM between the Z80 and video controller.

XMEGA128A1U has a SDRAM controller; RAS and CAS from the XMEGA can signal for a pseudo dual-port RAM.

Dual-port RAM are disappearing as FPGA is common.

Inexpensive are SDRAM and cPLD/FPGA; 16-bit SDRAM is very common in IP routers.

The HDL for this on a cPLD or FPGA would be relatively simple; somewhat more complex HDL for video.

 

ATxmega128A1U - 8-bit AVR Microcontrollers

Icestorm | AVR Freaks

Radical Brad Hacks – Vulcan-74 Page 1 | AtomicZombie DIY Plans

[after second picture]

Today, I would just purchase a five dollar FPGA, and spend 2 hours coding in the extremely easy to use Verilog language to complete this entire design, but no such technology existed in the time I am stuck living in.

cPLD/FPGA design entry software usually has schematic capture if the design won't be by an HDL.

 

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

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

clawson wrote:
... but the good news is the ATmega1284P. It's a "traditional" mega AVR but very unusually it has 16KB of RAM.
and its follow-on in AVR128Dx.

Clock Sources | Migration from the megaAVR® to AVR® Dx Microcontroller Families

Part Number: EV35L43A - AVR128DB48 Curiosity Nano Evaluation kit | Welcome to Microchip Technology | Microchip Technology Inc.

 

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

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

Dhruv wadhwa wrote:

I don't think this can be done on atmega328. It just has 2kb of ram, it can't hold 256×240 pixels. I'll have to go for xmega, am i right?

 

No as Barncle pointed out you don't need that much RAM unless you want individually addressable pixels.  If you do the game as fonts/tiles then you will only need <800 bytes of RAM for the whole screen.  The actual Pixel data will be in ROM.

 

Even if you want individually addressable pixels you can have you font/tiles in RAM and just accept that 70% of the screen has to be black (black like space that is being invaded)

 

Look at this video Tornado 2000.  That game is done on a ATMega644 that has only 4K of RAM.  The graphics mode is 256x224 pixels at 2BPP.  That would be 14K of RAM if it was a flat bitmap.

 

There is 800 or so bytes of RAM for the "text" of the screen.  Each block/cell can be filled with one of 128 "font tiles".  Each font tile takes 16 bytes so 128*16=2048 bytes.  The whole screen takes 2.8 kilobytes of the 4 total in the Mega644

 

Or look at the 3117 demo here.  It uses up only 1024 bytes of RAM for that filled polygon spaceship spinning around.

 

So the the 328P COULD be used to do something simple like space invaders no problems at all.  You just have to decide if you want a challenge or if you just want to play around making games.

 

If you just want to play around and do it on a PC then look at One Lone Coders game engine or pico-8.  If you want real hardware look at Uzebox or one of the many Arduino based games things.

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

Consider space invaders alien sprite (8×8 monochrome) i can put that in rom and output that on vga which i was successful in doing. But then when i add some code for the game then everything on the display gets crazy even when im skipping every alternate line... according to me i think it isn't getting muchh time for processing the game code

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

BTW I was watching YouTube and it mentioned...
.
https://youtu.be/RmPWcsvGSyk
.
(using Pi Pico to generate VGA). Quite impressive.

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

Again look at zx80 and zx81 if you want to play you have to run your game between frames, (still make H sync and V sync). As I remember it's about 25% of the time, the rest of the time it's mostly doing video.

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

ZX81 yes, ZX80 no. The improvement the 81 had over the 80 was that execution interleaving. With ZX80 (the one I built from one of the first kits) the display just went to snow while "calculating". It was only when it was idling, waiting for input, that the video generation ran. I used to dream of getting ZX81 but my next Sinclair was a 48K Spectrum. I think there was an upgrade ROM later for ZX80.

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

both the ZX80 and ZX81 in fast mode could be programmed (in ASM) , so the video was fine!

ZX81 in slow mode the HW handled it (or perhaps it's just SW, but the main thing is that you don't need to think about it.)

I only had(have if I can find it) a clone sold cheap (when they gave up selling them), and there I made games running in fast mode.

(It had an EPROM not a ROM it was valued more than the hole computer)

Add:

As I remember you can read or even interrupt on a line counter. (Perhaps I mix it up with a C64 where you for sure can get an interrupt on the line counter that's the way you get more than 8 sprits )

Last Edited: Sat. Feb 13, 2021 - 03:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

You could always push an ATTiny to output VGA.

More fun when you only have 512 bytes!

 

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

 

Brad

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

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

I have done on Arduino Uno or atmega328 design a VGA generator up to 8 colors with tiles (look at https://github.com/akund/APL for details including source code).

Additionally to this lib is tone output and a PS/2 keyboard interface.

 

The highest resolution I got was 172 by 160 pixels or 29 by 20 chars. The video rendering power is limited for a 8-bit MCU, but still the challenge can be interesting.