Pacman Proves Due Is More Than Uno

If you’re wondering what the difference is between the good ol’ Arduino Uno and one of the new-school Arduinos like the Arduino Due, here’s a very graphic example: [DrNCX] has written a stunning Pacman clone for the Due that seems to play just like the arcade. (Video embedded below the break.)

001The comparison between the Uno and Due isn’t quite fair. The Due runs on an 84 MHz, 32 bit ARM Cortex-M3 processor. It’s in a different league from the Uno. Still, we view this as an example of the extended possibilities from stepping up into a significantly faster micro. For instance, the video is output to both an ILI9341 TFT screen and external 8-bit VGA at once.

Besides using some very nice (standard) libraries for the parts, it doesn’t look like [DrNCX] had to resort to any particular trickery — just a lot of gamer-logic coding. All the code is up on GitHub for you to check out.

Can the old Arduinos do this? For comparison, the best Pacman we’ve seen on an AVR platform is the ATmega328-based RetroWiz, although it is clocked twice as fast as a stock Uno. And then there’s Hackaday Editor [Mike Szczys]’s 1-Pixel Pacman, but that’s cheating because it uses a Teensy 3.1, which is another fast ARM chip. People always ask where the boundary between an 8-bit and 32-bit project lies. Is a decent Pacman the litmus test?

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

28 thoughts on “Pacman Proves Due Is More Than Uno

          1. Possibly the same people that want to look at a video game about a yellow disc with a mouth being chased by ghosts.

            Maybe the same people that write filters for NES emulators so they can have scanlines and dot-crawl on their 2700×1440 pixel s-ips LCD screens.

            Maybe the people that just want to have the fun that is the challenge of writing a video game on the same processor as in an Auduino but has not video generation hardware. You know the fun of being creative.

          2. @[cunningfellow]

            I do all of these thing *without* NTSC.

            I do have one old retro computer that I use a PAL baseband modulator for but everything else id some form of VGA. Even this is going to be converted to VGA.

            Baseband modulation, weather it be NTSC or PAL is good for monochrome only. They have issues with color as the dot clock is to close to the color burst frequency for the resolution of computer displays.

            In any case PAL is far superior to NTSC. Pal is *usable* for color baseband, NTSC is trash.

    1. The first PCB I had to design was for this ATSAM3X8E. Make sure you read all the application notes thrice:-) The 144 pin beast is of a completely different league than the 328P

  1. between the due and any 328p based arduino, performance on these serial displays are night and day. i was scanning out a 3 frames a second on the latter. the same demo on the due (though to be fair with a different graphics library that used dma) was a blur.

  2. I remember playing the official port of PacMan on my old Franklin Ace 1000 back in the day. Definitely 8 bit, and just a hair over 1MHz. Yes, it had a separate chip chucking bits at the display for it, but I also played the Atari 2600 port and that machine was very much lime today’s microcontroller video hack.

  3. The original game was 3MHz and 4 cycles per instruction – about 0.75 MIPs.

    The ATmega328 is about 20 MIPs so in theory this game should run on the 328.

    I don’t think it’s a *fair* test because this is probably only just out of reach for the 328 if you are using sketch. You could probably do it with C and you could definitely do it with ASM if there was a cross assembler.

      1. The boards where huge because the common garden variety chips only had 4 gates in them (by average) so it took lots an lots of them even to do simple things.

        Generating video was the most complex task and a big proportion of the chips were for that.

        With a 20 MIPs chip you should be able to bit bang the video and still have enough MIPs left to run a 0.75 MIP program with ASM and C or a cross assembler but it would still be a lot of work to port it over.

        1. The Pac-Man hardware could push out 224*288 pixels at 60 FPS purely in hardware, with the software only updating sprite positions and the tilemap. That works out at about 4 million pixels/second, giving you about 5 clock cycles per pixel to do everything including sprite rendering and pushing the pixels out (and remember, not every instruction is single-cycle – jumps and branches that’re taken are two cycles)

          1. Not sure if saying nah or telling how?

            OK, If a start with PAL cos I know PAL and it would be close enough.

            The lines are 64uS wide including sync. Of that about 60uS (or less) is active screen area.

            The screen was vertical so the 60uS has to fit the larger pixels – 288 and that gives us a dot clock of about 4.8MHz.

            There is noting to say that we can’t use other (external) chips so add in 4 of Parallel Input Serial Output Shift Registers to take advantage of the fact that the Micro-controller has an 8 bit data width and everything on the screen is arranged onto 8 bit units. Now we have a 4 register loads at 600KHz and that is much easier to do with a regular interrupt without wasting so much set up time. We could even add a big SRAM chip so that the micro just does the timing.

            There are other alternatives as well. We could use a VGA screen that has a lower resolution and dot clock. Generally you can use an *actual* dot clock that is half or quarter of the specified dot clock for a particular standard.

            Video generation is a fairly *dumb* process that can be given to *dumb* parts that work fast. The timing then can be handled a lot easier my the *smart* component.

  4. The Gameduino or Gameduino 2 shields do precisely that. The original Gameduino uses an FPGA to generate video and audio. The V2 uses an embedded video processor. The point about the Duo is that it has enough grunt to do without external assistance.

    1. I bought a GameDuino (1) over a year ago and still haven’t used it.

      The main ‘cheat sheet’ is larger than normal printer paper and an American paper size so I can’t print it with a normal printer and I cant take it to a print house because of the paper size. The ‘cheat sheet’ is available on their website but they only post to America.

      I even tried to fit it onto several normal pages but the PDF that it is in wont let me do that.

      Yet another project completely destroyed by poor documentation or if you *NOT* American – missing documentation.

  5. Instead of a custom controller, how about a NES controller plus a 74595 to decode the serial data back into 8 button parallel data. Or better yet, add NES library and you’d need just a few lines rather than 8 lines for controller.

Leave a Reply to RÖBCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.