So it is the end of the year, which means at last there are some holidays, a bit of contiguous time away from work to have some rest, and well, a chance to go through some quite involving experimenting and hacking. The result, an OSS game console prototype based on the ATmega1284, contrary to the Uzebox, with no overclocking.

Insane Contraption 0 prototype
Insane Contraption 0 prototype
Power is on, smoke is still in, good enough!

But why not an ARM???

Today, almost in 2020, this is likely the question most people would ask. There is a very good reason I don't go for ARM, and will never do for this sort of project.

Why? Because now, at last, we even have some RISC-V! (GigaDevice released one in August, more on this below if you are interested)

But aside from that, the actual reson for sticking with the 8 bitter is primarily emulation. That is, to keep the system possible to be emulated like any retro system (such as the C64), which is a pretty tight constraint. By the CUzeBox project, I know exactly how difficult is to get such a performace from an interpreting emulator which is capable to run fairly well even when compiled to JavaScript, to run in a web browser (UI by Nickolas Andersen from the Uzebox project). Or to be potentially added to big emulator projects such as a LibRetro core (which has Uzebox emulation, although with the older emulator).

The aim for a bit-banged RGB output requires fast clock, bit-banged RGB output producing NTSC like timing is a very nice and unique thing, permitting to build your own graphics solutions, producing output matching those of actual retro machines (which all produced progressive scan NTSC / PAL).

It is just impossible to do an interpreting emulator for a 32 bit instruction set with flags at the performance the 8 bit emulator is capable to deliver (DMA is also out of question by the way). This is where the RISC-V could step in, as it is an architecture without flags, for which I already did some experimental emulation code. It can be wickedly fast! But the ARM, never.

Otherwise there are nice ARM based projects out there, such as the Pokitto or the BitBox Console, there is just no need to add another, as there is nothing really new to add compared to those (given that interpreting emulation is completely out of question).

So about these are why it is not ARM. Why not 32 bits? Well, I guess some time later I will pick up a RISC-V kit to build something similar around it! But still, 8 bits is just 8 bits, fits better with the retro theme, and the AVR is a remarkable architecture, it is just quite rewarding to hack it at low level.

Anyway, what this little system is then?

This one, which I call "Insane Contraption" for a reason, which is actually not its hardware, is a game console pretty similar to Uzebox. Actually, this build, the Insane Contraption Zero is almost an E-Uzebox (Uzebox with Scart output), with a few changes, most notably the ATmega1284, and that it only runs at 18MHz.

Insane Contraption 0 prototype side
Insane Contraption 0 prototype side
And not to forget this notable mess of wiring

The insanity comes with the software, a crazy thing only possible using the ATmega1284, if it has a bootloader supporting it (which will also be quite some adventure to design). There are some higher resolution modes which can be achieved by some rather creative exploit of the indirect jump instruction and the fact that this is a 8 bitter, where the 16 bit Program Memory address is composed of two halves. The end of the story is that you have a video mode which has 256 blocks of code, at the top of every 512 byte (256 program word) stretch of ROM. Now, that's something insane to code a game around!

It is not necessary to use this that way, there is a nice selection of possible video modes without using such an exploit, for example the ZX Spectrum's 256x192 video can be recreated nicely, with the addition of horizontal and vertical scrolling, and selecting any color out of 256 for foreground or background for each 8x8 tile.

And why zero?

Insane Contraption 32K

The prototype I built is called "zero" as it is the low end of a range of systems I envisioned. The next one I will be building will have 32K of SRAM, which can be utilized for "accelerating" graphics by working as a palette unit during display (otherwise it is a normal SRAM which you can use for additional data). This allows "high" resolution video modes without the crazy trick mentioned above, so is much easier to program for. The design can also accommodate a 128K or a 512K SRAM chip.

These machines would all be upwards compatible, so a game designed for Insane Contraption Zero would work fine on either of the bigger systems. The way this, and that you can use the SRAM as storage is realized with appropriate application of latches and bus transceivers by which you can connect parts of the system the way you need (for interacting with the SRAM, to set address high bits, or to connect the SRAMs output to the Video DAC to make it act as a palette unit), so in overall it would be a nice little board with quite a few DIP chips on it to make it look interesting, like if it was indeed some old retro console with various distinct hardware units.

Language support

The entire project will be done in assembler (it is cool!), however, of course, with providing C interface. This means once this is completed, you can use any language you prefer (and is available for the 8 bit AVR of course) to get started with it, be it Assembly, C or C++, or maybe something else which follows the same ABI which C uses.

The benefit of using assembly for the kernel is, well, it is kind of necessary to provide a kernel to use with those aforementioned "insane" graphics modes, but otherwise it is also nice if one wanted to get his hands dirty with good old assembly coding for a game, to make use of every single byte and bit to be found in this microcontroller. If one gave a C++ interface, then that tosses such people over the fence, and also those who would rather want to stick with C. While if you gave an assembly kernel capable to provide a C(++) interface, then everyone could be satisfied, while the kernel itself would also be pretty dependable. Like no chance of it being miscompiled due to some obscure combination of compiler features, which of course shouldn't happen ever as it is all designed to high standards, MISRA compliant to its last source file hidden in the deepest depths, but somehow in the real world with real projects, somehow at some point it will inevitably just happen anyway.

How it compares to Uzebox? Uzebox + SPI RAM?

In short, a lot more flexible (even Insane Contraption Zero), but slower.

That it is slower has some significant drawbacks in the video department, making some things possible on the Uzebox impossible on this system. This includes the most commonly used Video Mode 3 of Uzebox, for which although I will likely be able to design an alternative of similar resolution, it will have some limitations, although in other regards, it may be more flexible.

It is however a wholly different system, the 16K RAM of the ATmega1284 is so significant that it makes a very substantial difference. Notably on Uzebox, most of the graphics have to be sourced from the AVR's limited ROM directly, which can not be helped even by the SPI RAM. It is not only that the ROM is limited, it is also that it is not possible to do any transformation on that graphics, as it has to be output from the ROM as-is. In contrast, on this system, also due to its slower clock, most viable graphics modes would operate from data in the RAM. So graphics can be depacked, tiles rearranged, loaded from the SD card, or whatever other transformation could be applied on it, only bounded by the creativity of the designer.

The designs with SRAM would also provide a much faster random access memory than the Uzebox with SPI RAM.

Of course the Uzebox itself is an excellent fun little system, without which this one wouldn't have been possible (as I mentioned, I wired up IC Zero using an E-Uzebox schematics as guide even), just that for me it always felt like its bounds, especially the RAM constraint restrained it from gaining any wider popularity, and these days even the forum seems rather desolate. As if all the ideas were tried, nothing left which wouldn't require some ridiculous effort to implement to get some new and unique game running. I hope this one could eventually bring a bit of retro-revival 8 bit fun back.

When it will be ready?

I think it would take a couple of months or more. It is not a simple thing to do, and there is a lot to do, including porting CUzeBox or adding support in it to emulate these as well, since without proper emulation, it is just a lot more difficult to do anything with it, and it is also much less intriguing for other people who don't have the board, or are just not that interested in the hardware itself.

Likely I will also design PCB at some point for it, most likely the 32K system as I think in overall that would be the most fun to play around with. Pretty limited with 48K combined RAM, but about matching high-end 8 bit microcomputers and consoles of the late 80s, of course being faster at 18MHz (and with the AVR's advanced instruction set), but lot of it goes to realizing a soft GPU and audio. So basically a system built using contemporary components, which is fairly flexible and interesting for those who like the aesthetic and challenges of the 8 bit era.

What about license?

I think I would move away from GPL used for the Uzebox, to rather provide a more permissive license. There are cool projects out there, and it is pretty neat that for some systems, real cartridges can be still purchased with new, freshly developed games. It may be debated that this could work with GPL as well, the game could be GPLed and still be sold (as people who actually buy, let's say, a new Mattel Intellivision title buy it for owning the actual material, cartridge and manual in a nice box), but I just don't think there is any reason to restrain someone who wanted to do that.

GPL in my opinion does very well for protecting work from being utilized in proprietary environment without contributing back or even being outright hostile towards the open movement, however tools and designs for a 8 bit system are not really things any more on which someone could make big money with that attitude. So I think it is fine to open it for anyone, to do whatever he wants, well, if the end result is that someone made big money using 8 bit ATmegas, then at least they contribute keeping the 8 bit ATmegas alive, so at least there would be some benefit in that, even! :)

Some words on the RISC-V

So when I would make something 32 bits then, if you are interested in that sort of thing.

I am really considering to do it some time in the future, probably even as just swapping out the ATmega1284 in the Insane Contraption 32K idea to a RISC-V microcontroller. The same idea, the same concept, just with the modern 32 bit micro, which is open (at least the RISC-V itself), and is a breeze to emulate (of course staying at 18MHz or something alike, depending on what sort of graphics can be contrived by creative RISC-V assembly).

There is another thing I am considering to do with a fast 32 bitter, which even the Uzebox itself could benefit from. This is creating some LCD driver for 320x240 panels, which could take the digital input of these systems (Uzebox, this Insane Contraption, and probably anything else created to produce RGB NTSC through a DAC), and scale it on the fly to produce output for the panel. Maybe a job for one of those shiny new ARMs from NXP, that ridiculous clock rate would allow it to be an efficient horizontal scaler, and those are very cheap (cheaper than any of the AVRs on these 8 bit designs) to put in some handheld. Maybe I could even get one emulating an ATmega1284? (now that would be pretty insane :) - who needs an actual AVR if we can do cycle-perfect AVR on a cheaper ARM, which doesn't even have the Flash wear problem as the stuff is in RAM).

Anyway, so maybe in a couple of years, I might do some 32 bits stuff after all for such open-source things. If for nothing else, then just to get an 8-bit AVR running as accurately as it would if it was a real AVR!

And, of course, happy new year everyone, keep on hacking!

Referred artworks

  • Insane Contraption 0 prototype
  • Insane Contraption 0 prototype side



  • Created: 20 Mar 2020, 6:47pm

bernz: Thank you, actually I didn't even post a second iteration of this hardware, with an extra parallel RAM serving as both more room and as a crude "GPU", or at least something which can give a substantial boost to the graphics capabilities of the thing. Currently I am working on the emulator, it is just an arduous task while being severely exhausted by my current job, so progress is at the pace of a snail on Doxepin.


  • Created: 2 Mar 2020, 1:18am

Cool stuff, my dude! The worst part about retro-console design is that the real fun is the design, and when it's done, and works -- it doesn't have much purpose without applications, but by that point, most of the fun has been had already. x-D That [Uzebox] dragon game you made was pretty good, though; maybe eventually, a remake on the new system? :-)

Make a comment


  1. Please be polite (Leave all your trolls in their respective caves).
  2. If #1 fails, don't feed 'em. They bite.
  3. No links allowed. It won't pass. Neither chains. Use '(dot)' notation.
  4. Spam reeks.
  5. Text is (some day will be) formatted with Markdown.
  6. Your mail address is only visible to me: I understand you also don't like #4.
  7. The mail address you provide is also used to fetch your Gravatar.
  8. Danger! High voltage! Right between your "Post Comment" button and ground.
  9. Still want to comment? Go ahead! :)