Hackaday Prize Entry: Dodo 6502 Game System

If you are a gamer of A Certain Age, it’s probable that you retain a soft spot for 8-bit computers and consoles of your youth. For a time when addictive gameplay came through the most minimal of graphics, and when gaming audio was the harshest of square waves rather than immersive soundscapes.

Does the previous paragraph sound familiar? Then we may just have the device for you. The Dodo is a handheld console that harks back to that era with a 6502 processor and a 128×64 pixel OLED screen. Games are loaded from plug-in EEPROM cartridges, and sounds are suitably period-digital square wave tones. It’s the brainchild of [Peter Noyes], and he says he will consider it complete when it sports a game fun enough to entertain his 4-year-old.

The prototype Dodo is a handheld form-factor made from two stacked PCBs. The upper one has the display and buttons while the lower has the classic 6502 and associated chipset in through-hole DIP format. A Game Boy Micro it ain’t, but miniaturization is not the name of the game with these consoles. Best of all though, all the console’s resources are available in a GitHub repository, so you can all have a play too.

The 6502 has featured in a huge number of projects here on Hackaday over the years. Now it’s turned up in the Hackaday Prize.

13 thoughts on “Hackaday Prize Entry: Dodo 6502 Game System

  1. It’s neat but…

    It would only seem to satisfy nostalgia in the same manner as if your parents bought you a Commodore 16 back in the day and you only ever got to play the 2 games that were bundled with it… my buddy had that problem… everyone else had C64s or timex2000, even the kids with the older Vic20 weren’t so badly off for software…. sure fifty titles theoretically existed, but were they carrying them at local stores? Nope.

    I’ve seen at least 25 of these types of projects now, 8 bit retro machines that are going to be lucky to a get one or two semi polished games on, but aren’t compatible enough with anything old or new school to make ports easy… and this isn’t counting all the arduino mini consoles etc, but at least the AVR is “current” and people might be more interested in programming it to learn how to do so.

    If I was gonna do new 8 bit retro hardware, I think I’d build an MSX compatible or something, since that was kind of a standard for multi companies.

      1. Oh here we go, semantics argument about the difference between “a” standard and “the” standard.

        Compare and discuss; Betamax was a video recording standard in the 1980s, VHS was the video recording standard of the 1980s…

    1. Quote: “It would only seem to satisfy nostalgia in the same manner as if your parents bought you a Commodore 16 back in the day and you only ever got to play the 2 games that were bundled with it..”

      Well that depends on what “nostalgia”. or some it’s play the old 8-bit games. For others it’s programming the old 8-bit Complex Instruction Set Computing type CPU’s they are nothing like an ARM (Reduced Instruction Set Computing) to program. CISC was fun, RISC is boring boring boring.

      1. Correction: Well that depends on what “nostalgia”. or some
        Should be: Well that depends on what “nostalgia” means for you. For some

        My cat likes to edit for me, you should see what happens if I leave my email client open!

  2. I wonder why he chose a monochrome display.

    Is is easier to interface to a monochrome graphics display than a color one?

    That seems to be the greatest difference between these retro computers, that is how they solve the display problem.

    There are options like the Propeller and the Gameduino but these don’t really fit with the retro theme. Then there are old chips like the 6845 but they aren’t any good for higher resolutions and are limited to composite display frequencies.

    VGA can be done in one simple 5 Volt tolerant CPLD and SRAM, better than some other solutions but still limited.

    1. The display in this is connected in “6800 8-bit bus mode”, so presumably 8 bits of data at a time and some signalling pins to tell it when to accept data. This is important with a relatively slow, by modern standards,. CPUs. Other home-made computers will often use I2C or the like, a serial connection, but it requires a fast serial bus. You could, I suppose, use some chip between the CPU and display to convert the 6502’s commands to serial, but why bother?

      Monochrome has a few advantages. A big one being memory size, he says his screen is stored in a 1K buffer in RAM (the main 32K RAM I presume). Colour would use, logically, 4 bits per pixel, so 4x the RAM size. That’s not too much, but brings with it 4x the processing, 4x as much data to process and send round the machine. Drawing a line or copying a sprite would take 4x as long. In 8-bit computers of the 1980s, if they had a 4-bit bitmapped display it was rarely used in games, because it was too slow. Often the 4-bit mode used the same RAM as 2-bit colour mode, but with half the horizontal resolution (and a quarter of the monochrome resolution).

      There’s ways, like tile-mapping and hardware sprites, to do full-colour in small RAM, but that would require custom hardware. This machine is pretty simple, and quite true to early 1980s design. Simple circuits using the simple chips available then. The OLED obviously isn’t 1980s tech but the way it interfaces is. If they had OLEDs back then, this is how they’d have done it.

      Another good reason to have small screen RAM is for scrolling. If the OLED’s hardware doesn’t support it built-in, it means each pixel needs copying, one at a time, to scroll. The 6502 was a bit short on the bit-shifting operations that software scrolling uses. So, more RAM to scroll, more jerky and slow the scrolling is.

      So, TL;DR, colour = more screen RAM, and more screen RAM = more CPU cycles needed to do animate it. Both of which are in short supply here.

      Besides tile-mapping, there’s all sorts of interesting ways you can generate a screen with little RAM. The Atari 2600 was genius, particularly on the part of the programmers who wrote the later games with graphics that were right on the edge of the possible. Later Atari machines had a display list processor, ran it’s own small set of instructions to generate the TV picture in real-time. Allowed mixing resolutions, special interrupts, all sorts.

      The NES had a fairly simple, but clever, graphics setup. Tile-mapped, but with 2 sets of ROM chips in the game cartridge. One set of ROMs connected directly to the video chip, so it could read that ROM in real-time, again, as it generated the TV picture. The advantage was that you didn’t need expensive RAM for the screen, you could generate it most from stuff in the cart’s ROM on the fly. There was of course some screen RAM but it was effectively pointers, to the actual graphics in the CHR (graphics data) ROM.

      Later NES carts went even further, with “mapper” chips. Originally designed just for paging in ROMs to allow bigger games than the machine’s address limit. Later ones issued interrupts and control signals, and could swap out different parts of the CHR ROM. This meant you could change which sprite data the cart returns to the console, say, every half second. That gives you sprite animation, for free!

      There was also, another improvement, CHR RAM. So the cart could use RAM on-board that the console could draw in. Allowing even more versatile and sophisticated graphics.

      There was an option for an interrupt at certain places on the scanline. Swapping graphics around then meant you could split the playfield into 2 separate areas, again, effectively free, or at least cheap, to the machine’s CPU.

      The SNES, after, also had quite a few clever tricks, quite a bit more advanced than it’s progenitor system though, just a few years later.

      The Atari and NES systems both did it. Extra, clever chips in the cartridge (including RAM in Atari carts too), took limited hardware and allowed huge improvements to what was possible. Just a small hack in the right place, opens up new roads.

      Hope that answers your question!

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