The Famicube project (fictional)


Working within tight restrictions is much of the fun for many people into making games (or graphical mockups) for older systems. Our minds seem like a good puzzle, and being efficient with pixels and data be satisfying in that way. But, I do really believe that restrictions can benefit you as an artist, at least when it comes to staying consistent within a certain graphical style. Keeping color count down and having a uniform palette is often a good idea even when you do traditional art, so I think old hardware limitations can align with that. I think I mention it in my unfinished pixel art tutorial.

As a graphics guy I feel that there's something missing between the NES and SNES*. NES sprites feel like they really could use two more colors or so, while SNES sprites tend to use muddy gradients and needless anti-aliasing because it's so tempting to use all the colors. This project aims to conjure up a of missing link of sorts, a NES 1.5.

*The SEGA Master System had something going with the total 16 BG + 16 FG colors. 16 colors is perhaps more than I would use per sprite, but because the palettes are shared between all sprites I probably wouldn't use more than 4-10 colors per sprite. This is not a SMS project though, so maybe another time. The PC Engine is another interesting system.

Crafting the voluntary chains

There are many cheap game consoles and retro products out there such as the Ouya, Gamestick, Raspberry Pi, Gameduino, Uzebox and various XGameStation stuff. However, I feel that these have no tangible identity... they are just slow PCs. In comparison, a ZX Spectrum, C64 or NES game can be recognized almost instantly. In addition, for me the experience is not just about the game on the screen and its sounds, but the presence of the hardware, a unique controller in hand, and the churning of a floppy drive.

So, to create something different I must decide on a a set of pleasant and "lagom"* restrictions:

* Lagom is a Swedish word for striking the right balance (because of unmentioned considerations), not going overboard. Tekitou?

CPU speed and memory is a bit less important when it comes to creating identity so I went for specs which would make programming easier whilst not being overpowered and unrealistic. I did a quick and dirty game-logic benchmark test on my Arduino UNO which runs at 16Mhz, and found that it's probably quite enough for more advanced NES type games (especially with a side GPU). Compiled C code is not as fast as hand optimized ASM but the programmer can scale into using more advanced inline ASM later on and this lowers the entry threshold for beginners.

Of course, if it was actually Nintendo (or SEGA) who released something like this, the system and its restrictions would gain a certain... authority, attracting a lot more developers. "Something released by some guy" is a lot less interesting to develop for.

Case Design


Mark 1. I imagine that the Nintendo Famicube was released in 1988, featuring a fast processor, up to a Megabyte memory and a built in floppy drive. The later versions were fully expanded. These kind of square cases are more expensive to tool. Edges kind of need to be sloped like on the Mark 3 below (they're sloped on the NES if you look carefully). The NeXT cube was apparently difficult to tool, being made from many unique pieces.


Mark 2 (Sharp). With a Motorola inside, maybe the X68000 look would be appropriate. Disk-kun & logo needs to be gold?

Of course, I really like the SONY HitBit F1XD so let's add some of that! Maybe the case is modular so the drive front can be swapped out, along with other parts.

Hmm...maybe add some FC and NES colors? With relatively compact modern hardware inside, there's space to make things modular, sort of like a computer case. The IO stuff could go on separate boards. The drives should connect with ribbons. There might even be half-size rear brackets. This way, the cases can vary a bit in design, as long as they supply internal mounting... knobs.

Famicube concept by Arne

Mark 3. 2019 concept. I like this the best so far. The two sides can use the same mould. The buttons are curved, similar to those on the SFC.

Ataricube concept by Arne

Atari version styled version

Toploader, Box, Toploader, and there's another toploader on my EE/joy page.

Duo Pad by Arne

2020 joypad concept. Shoulder buttons are more useful than start select as they can be pressed simultaneously with B & A, and they're more spatially distinct than having 4 buttons under the thumb. A second D-pad offers something unique, and helps a lot in games like Robotron/SmashTV. Having too many face buttons confuses me and seems overkill for the Famicube. This joypad design only needs a single 8-bit shift register because the right D-pad is actually also B & A, L & R. The other two special buttons use the impossible directions on the left D-pad (might work because they're Pause/Menu and not action buttons like B & A). Possibly it's a bad idea to angle the buttons like this because retracting the thumb is more awkward than sideways (partial rolling) movement. The NES pad's button placement is actually pretty good I think. Schematics on EE/joy page.

Duo Pad by Arne

Rough internal layout... it's hard to imagine and puzzle the thing together in 3D. I was thinking of using a horizontal button bus at the back of the PCB, vertical on front. SMD components: 4x2 pullups at the sides, 4 diodes for the special buttons. A CD4021 would make it fully NES compatible (aside from some games freaking out over impossible directions, though in the Famicube a peripheral interface might neatly decode the special buttons and directions). A daughter PCB is needed for the shoulder buttons... unless using flex. Gets a bit tight near the shoulder buttons... one has to consider how it comes together and what's possible (cheaper) with injection moulding. The rubber pads can be flipped for L/R side. Plastic shrinks a bit so the ring walls around the D-pads might actually show on the face... not a problem on the NES where there's a face sticker, or the the SNES where they hid it with a ring indent... tricky stuff. Screw holes and creak mitigation is another thing to consider... 5 screws might work. Shrinkage of sockets should probably be hidden under the 4 corner marks.

Once upon a time...

This is written as a historical account of events in the parallel universe which plays host for my various hardware redesigns. I scrapped the CNES-88 idea (earlier iteration of this project) halfway through because I didn't like the bland case look and having to use an external MMU due to the 6502's 16-bit address bus. The current (final?) form is the Famicube seen above.


Several factors pressured Nintendo into updating the popular NES in the mid-late 80's. Initially they were going to release a simple "New NES" with a slight memory buff and a new shoulder button joystick, but the project took several unexpected twists and turns as it developed.

The success of the Commodore 64 in Europe (and the MSX in Japan) eventually made Nintendo eager to branch out and capture some of the home computer market. Also, the graphically superior Sega Master System had gained much popularity in Europe and South America and rumours circulated that SEGA were already working on an even more powerful system, perhaps using a fast Motorola processor and 3.5-inch floppy drive technology.

Nintendo's new system actually started out as a joint project between Nintendo and Commodore. However, management problems at Commodore caused the partnership to collapse and Nintendo were left to their own devices. In the summer of 1988 they finally released the Famicube. No images of the Commodore co-designed case has ever surfaced, but sources suggest it was beige and dark brown.

A mystery.

Update: This piece of parchment was found on the body of a mummified man in the alps. Could it be a drawing of the fabled Commodore NES? Who was this man? Carbon dating suggests he's over 23000 years old! He had 6 fingers and a mermaid tail! An elaborate hoax, or...?

CNES-88 concept by Arne

Mark 0. The Famicube saw many radical design changes before making it into production. Amongst the names used were: New NES, CNES-88, ファミコンド (or sometimes ファミコモド), and finally Famicube. "Do" here had a triple (English) meaning: getting things Done, Two and Famicom-CommoDOre. Seen here is an ad from the Technopolis / テクノポリス magazine. The case design depicted here is actually that of the much older New NES prototype. The Fat Floppy design was later abandoned due to drive head and manufacturing issues.

Famicube hardware

The CNES-88 was partially built on the foundations of the failed Commodore 128, using similar MOS Technology chips (e.g. an MMU addressing several 64KB memory banks). However, instead of the VDC&VICII the CNES-88 used an upgraded version of the Ricoh PPU which was used in the Famicom.

The development of the CNES-88 dragged on. By the time it was somewhat finished (slated for a xmas '87 release), the costly tile-focused PPU chip was already a bit dated. When Commodore wanted to develop a completely different, more powerful PPU and cause further delays with various changed directions, the partnership broke.

Rather than changing the PPU, Nintendo opted to just upgrade the processor & memory, figuring that it would promote "advanced play" (briefly used as a slogan for the system), and reduce mid-game loading. Fortunately this decision coincided with a freak drop in prices for processors and memory as new production technologies were suddenly introduced in the "Silicon Boom" of Jan '88.

PPU design

Byte: b7b6b5b4b3b2b1b0
Name Table: 8-bit Tile select (0-255)
Attr Table: 2-bit Table select
2-bit Palette select
(next entry)

Famicube Schematic

This rough schematic might not make sense at all. I'm learning as I go.

PPU card?

Video output is a difficult problem because composite is blurred quite awfully by modern flat screens. Perhaps I need to output SCART, or VGA, or even HDMI. It is possible that later versions of the console had more modern video out solutions.

Many have suggested using FPGA for this project (for a mockup at least), but I haven't introduced myself to hardware programming. An alternative is running an emulated version in a cheap and speedy modern processor, but it feels a bit like going against the spirit of the project, too. For now I'm going to pretend that this thing is all ASICs, and design it from that perspective just for consistency. It feels the most real and interesting. I quite like the idea of discrete components and an FPGA/emulation doesn't really offer that. I don't mind using modern components if they match the specs though (like surface mount resistors, more space efficient RAM chips and a nice switched PSU).

As a scalable solution, the Famicube could have a graphics card slot for the PPU board. Perhaps the PPUs were problematic and Nintendo used this solution for ease-of-repair reasons, or perhaps it had to be this way because things wouldn't fit on a single flat board. This way the card could be used for people's Arduino projects, etc. I would insist on keeping the character of the PPU, but it's so tempting to expand it a bit:

PPU dev page.


As I understand it: A VGA RAMDAC has RAM memory inside so it can store an internal 256 color palette using RGB components. Those are sent their separate ways to three DACs and finally the VGA's R,G,B wires as 0 - 0.7 volt analog. The palette entries can be changed at certain times, but the chip has become a bit of a legacy mess and nowadays you don't see anything running in indexed mode other than emulated.

Because I want a static palette and discrete components, I'm going to make up my own DAC for the hardware palettes that I've made. I think it'll need a cute rainbow print on top.

In the case of the Famicube I'd only connect six of the index pins because I have a 64 color palette. The rest of entries could be other useful palettes of mine, like the 16 color one, and my Workbench palette which is bit-plane collapsible. Ideally, the color entry layout should be so cleverly designed, that one can design a reasonable palette by swapping pin connections around (on a breadboard or whatever). Would be hard to cover all possible combinations though.

version 0, WIP

Here's an example to demonstrate the problem. In an idea scenario, the palettes should create a good 256 color palette together, but perhaps this would mean compromising the individual palettes which are more ultimately important. I the no-signal would be black as default, bot one could probably pull pins/bits high with some dummy signals.

I should probably arrange the palette so I have nice RGBCMY etc on the single pins for 1-bit color projects, but I suppose one could put a dummy signal on another pin and get a better selection. It becomes a lot more complicated once you combine pins, like pin 3, 7, 0 and a constant dummy signal on 2. Which 8 colors does that give? Preferably useful ones! Not every combination has to look good, but at least a few should, aside from my deliberate ones. I need to write a test program which connects pins and dummy pins randomly, spits out the resulting palettes, and if I don't like them I'll have to rearrange some indices.

This chip would be useful for Arduino projects where you might not have bandwidth to output separated R,G,B. 1-bit to 3-bit output seems to be pretty common, and people just hook the bits directly to the VGA's R,G,B pins and make terrible full-value palettes.

// ------------------------------------------------
// by Arne, 2015
// Disclaimer: I don't know Verilog and this code
// most likely won't run. Shows intent though?
// Function:
// Take in a byte value representing a color index,
// get 24-bit RGB, dispense bytes to separate DACs,
// and eventually a VGA screen.
// ------------------------------------------------
`include "disciplines.vams"

module PALDAC(
in_clock, in_vref,
out_analog_red, out_analog_green, out_analog_blue
// I don't think hsync and vsync needs to go thru here,
// unless they need to be delayed to match RGB out?

input	in_clock, in_vref;
input	[1:0] in_color_index; //2 bit for now, should be 8.
output	out_voltage_red, out_voltage_green, out_voltage_blue;

electrical in_vref;
electrical out_voltage_red, out_voltage_green, out_voltage_blue;
reg 	[7:0] red_byte, [7:0] green_byte[7:0], [7:0] blue_byte;

// Needs to be triggered by clock pulse, or does index work? 
always  @ (posedge in_clock)

	// CLUT should be 256 cases long
	// Three color channels sent to three DACs in parallel.
	case (in_color_index)
	case 0 : red_byte <= 10; green_byte <= 0; blue_byte <= 20;
	case 1 : red_byte <= 20; green_byte <= 30; blue_byte <= 60;
	case 2 : red_byte <= 120; green_byte <= 110; blue_byte <= 100;
	case 3 : red_byte <= 255; green_byte <= 255; blue_byte <= 240;

	// Resistor ladders? AMS? I know nothing.
	// 0.7 volt is max intensity for VGA signals, iirc. 3.3 volt vref?
	V(out_voltage_red) <= V(in_vref) * 0.2120 * (red_byte/255.0); 
	V(out_voltage_green) <= V(in_vref) * 0.2120 * (green_byte/255.0);
	V(out_voltage_blue) <= V(in_vref) * 0.2120 * (blue_byte/255.0);



Bus / memory controller thingy

This area of design is quite fuzzy to me. I know the Amiga had the Fat Agnus to direct traffic. If I recall correctly one can also set up bus lanes and use a chip select signal to notify a chip which then put the ear to the lanes.


I think the first step to realise this project is to write an emulator for the hardware as well as a simple operating system, a bit like the Amiga Kickstart. A unique OS is essential to giving the machine a strong identity. My design philosophy is to ignore legacy formats and conventions. So far I've done my own character table, file system, experimented with a tile based window manager, and also begun thinking about a built in programming language based on BASIC. I absolutely want to stay away from ASCII, FAT32, and Microsoft BASIC, and certainly Linux with its abstract command line.

My idea is that I'm doing a later (perhaps last) version of the FamiCube where they beefed up the "firmware" (as well as the memory and maybe CPU). In the current iteration, NintenDos goes on a socketed DIP-8 serial EEPROM (has to be loaded into RAM). The system first boots into a simple mode, similar to the HitBit boot screen. From there the user can load the built in software and inspect disks that are inserted, and also do hardware (memory) tests. If an error code byte is set to >0 by a program which crashes (if if certain keys or buttons are high), the machine will instead boot into "Guru Meditation" mode (perhaps including a simple memory & register inspector). I have some more ideas for built in software on my Acorn Pi page. These include a Graphics Editor, Music Tracker, and simple BASIC Compiler + IDE. A more advanced Compiler could be written for modern computers because this thing needs to generate efficient machine code.

NintenDos (fully loaded) is fairly simple, a bit like a tile based (text-mode) Amiga Workbench (or old MSDOS setup thingy, but pretty) with just the bare (but fun) necessities and fun stuff - directory exploration, appearance customisation, settings, and a few editors. It's a single user machine and there's no reason to get fancy with file rights paranoia. Multitasking + memory management could be kept minimal and may be outside of the scope completely.

PPU emulator

My emulator is not a full hardware emulator, but something which produces the same graphical result (tile storage, palettes and so forth) on a modern PC/Mac. I wouldn't know how to emulate an ASIC at gate level. I keep changing the storage format for the tiles around. Packed pixels (e.g. storing eight 3-bit pixels as 00011122 23334445 55666777) is nice in my software (easy to mask and shift out), but planar might be better on real hardware?

Hey, it's hard work to load all that data. The Diskun / Disk kun character serves as a loading icon. The original design looks a bit like as if it could have spaghetti arms bent in over the chest, so maybe my redesign isn't that different.


I've worked a bit on a PPU emulator and the built in characters (text, symbols and some GUI stuff). My emulator does the draw logic fairly quickly (tenth of a millisec), but I'm on a 3Ghz machine so I suspect it'll be too slow for a more simple chip. The pixmap (32-bit frame buffer) drawing slows things down, though I sped it up a bit by using pointer tricks. No idea how to output an actual video signal yet! I suppose sprites will have to be just "blitted" rather than working like scanline sprites.

Anyways: Implemented so far: Global 64 color palette (actually stored as 32-bit ints because they write faster to the pixmap this way). I can load and convert .bmp files into 1-bit and 3-bit tile table data, then into the appropriate VRAM region. The Name table and Attribute table are in their appropriate VRAM regions and the palettes work. Rendering the 1-bit and 3-bit tiles works, as does the flat color override special case. I have a routine for setting up zones of multiple screen, with bounded scrolling, and there's a simple tile editor.

I've also written a window manager (missing some button/"gadget" code still) reminiscent of Amiga Workbench. Finally, I wrote a (nearly operational) custom file system (FCFS) from scratch, but I have only dummy files stored in it so far. I didn't really know anything about file systems when writing it, but ended up with the same solutions as everyone else it seems (I got curious), including some patented solutions. Oh, software patents... I'm not even a good programmer and it took me minutes to figure these things out.

BIOS font and tiles

I never quite liked the ascii table so I decided to rearrange the characters with the hex range in the first 4 bits, and almost full all-caps writing within 6 bits. There are 4 bytes reserved for LF+CR, Tab, Escape character, and Variable length escape character.

One thing sorely missing from human writing is facial gesture glyphs, so I've added a bunch of mouths and eyes. I've also added drawing symbols to the table. The boot up screen can have this anthro diskette guy, and the facial gesture glyphs can also be used for diagnosis and crashes.

My brain is thinking some more

The idea with the Famicube boxes is that when put on a shelf, the figures on the sides form a nice lineup with everyone at scale and in the same style (there'd have to be a template for this which Seal of Quality applicants must follow). The maroon-red and beige-white can be swapped for equivalent NES grays.

Inside is the floppy disk (held by something the buyer isn't likely to discard) and a manual about the size of the box minus space for the box tab which shouldn't poke into the manual. The manual is a compliment to the game (lore and art for immersion), i.e. without the manual you don't have the entire game, and you can experience part of the game even when not playing (exploring the bestiary, clues, etc.).

Found the font used by the NES black boxes: It's Swiss 721 (Black Condensed, perhaps squished, kerned, maybe bolded further). Oh, I wrote FC² on the side. That is a flatland cube. FC³!

I like the clam boxes I designed for my MSX project better. Cardboard wear easily and are a bit more fiddly to open up.

I recently booted up the Wii to play Mario Kart using the "classic" joypad and immediately got very confused in menus because there are so many white buttons. I think 4 identical main buttons on right thumb is just too much. I get confused by which two buttons are the bottom ones (B A). The Genesis/Megadrive controller doesn't feel like it has this problem, with a braille dot on the center button and special start button above.

I think the B, A and raised Oops-Cancel button on my joypad here would confuse me less. Menus tend to pause games so it feels like the best label there (and better than "home"). Maybe immersion could be preserved by calling it "inventory", but it might not suit all applications.


I'm unsure what kind of connectors I'll need for the Joypad, maybe mouse, Keyboard and splitter/hub. The Joypad has 10 buttons (and mic?), the mouse might be of the wheeled variant, and the keyboard might have ~100 keys. I don't want to support some wonky legacy protocol, but at the same time I want to stay away from unrealistic and taxing modern stuff (unsure how taxing USB 1 is...). I wonder if the few floppy drives available nowadays are only manufactured with USB...

Getting a custom connector made is pretty expensive (1-3 dollars per unit?), so I was thinking of using a common DE-9 (a bit clunky) or DIN (round). I cover joypads more on my EE/joy page. I'd probably stick to shift registers in the peripherals. The A1200 apparently used an MCU in the keyboard module so it's not that unrealistic. I wouldn't be opposed to using them for the keyboard and floppy controller. Those didn't have ASICs back in the day and were usually a kludge. There are generic peripheral interface chips but I could imagine having a single MCU managing all of it and focus the ASIC effort more on sound and graphics.

I think... the FamiCube offer a unique eco system. If it tries to integrate into the normal one that we use, then it will just be a mediocre slow regular computer which can perhaps be upgraded to be slightly less mediocre, losing even more of its identity in the process. So no USB.

Keyboard and mouse

1984 style keyboard, based on the Sony's HB-101, Nintendo's Advanced Video System home computer (which used the round top keys popular on some keyboards of the time). Instead of a joystick, it would be interesting to include a turn-knob (rotary encoder) for Breakout/Space Invader/Pong games. Milli/Centipede sort of needs a track ball (identical to mouse interface), but I suppose up and down could be digital...? Trackballs can be a bit expensive, not sure why, they are just a ball mouse upside down. The ball needs to be pretty large so it has a bit of momentum.


A design based on the Family BASIC keyboard. The layout is alphabetical to match the Katakana layout of the original keyboard and also early MSX machines. Katakana (rather than hiragana) is suitable because it's used to write English loan words (often computer terms). There's a thumbshift for han/dakuten. I chose a left-handed layout limiting wrist "yaw" movement, instead going more from the upper numpad to lower editing/formatting area. On a regular QWERTY there's a lot of unfortunate hand movement from mouse, cursors, pg.U/D, Del/BS, tab, and JKL. I often find myself tapping/holding the arrow keys rather than using figuring out which modifier key to use to word step (ctrl on linux). Word Del/BS could be useful too. Maybe having two modifier keys for movement granularity (word/paragraph, line/document) on the pinky could keep keycount down.

Moving on, my upper math section has its own shift key to reduce pinky stretch. The thumb can reach ,. which is handy when entering comma-separated floating point values. 0 & 1 are more common than 2-9, hence the ordering. are I simplified the layers/levels by removing AltGr... well, it's probably the Graph key. Perhaps it's here used to type popular emoji (text) characters, like certain Wingdings, Cyrillic, (or to select tiles). In the old days I think it was used for PETSCII and such. Deadkeys are in blue. 90 keys total. That's a matrix of 12x8, or less as modifier keys don't go in the matrix and three shift keys could be joined electrically. Right shift is a bit of a pinky-stretch, but it's tricky to address without displacing the katakana further.


Test using the MF2 form factor (with the characteristic impress). It might work. While some of my old floppies have disk errors, a lot had their data intact, even after 26 years. Still, FamiCube games might be somewhat compact so using the extra space for data safety perhaps is an option. A sort of "RAID" system might be interesting to try, where one side of the disk has redundant data. Dust and scratches on one side would not be the end of things.

Palette mockup

64 color palette by Arne

Version 8. (Code name: "Moonfinger") I turned a near white cyan-blue into another mid blue to facilitate sky gradient play. Might nuke the white-green and replace with a deep blood red, as I only have an orange red now and quite a jump to the adjacents. That said, the reds that I have are useful enough... I haven't really been missing a new red, and having gaps gives the palette some character, because now my lone red is that red. Maybe another skin tone then? Bad banding, dither or sick hues are quite unsightly on humans, less so on rocks, monsters and thingamajibs.

How did I choose these 64 colors? I think a palette made for 8 color sprites works differently from a 4 color one. In a 4 color palette, sprites are likely to use graphically strong flats. With 8 colors you can do more shadow+light, and in-betweens. Some of my colors are set up to fill those roles, but I also wanted to keep the strong NES color feel. I'm a big fan of including dark shades for black background games (I often favour that over textured backgrounds, so I don't have a lot of fogged colors I suppose).

Comments on the games

Zelda 1: No, I'm not gonna do snot-green Link cloth, though mine's still quite warm.

Devil World: These enemies were redesigned a bit. My blue is wimpy but I use the same color index for the Mario sky so I don't want to make it obnoxiously saturated/teal.

Spartan X / Kung Fu: Beat em up games have a lot of large body animation frames, so palette swapped bodies is probably necessary to save tile space. It's a bit harder to puzzle together new poses from different small tiles when the colors aren't NES flat though.

Castlevania: Being more conservative with the colors here. Wall noise could use some work, as it's very haphazard. Unhappy with the muddy blocks here. They need to pop. I want to fit a Castlevania pink-orange into the palette somehow. (done in V4?)

SMB 1: I over-rendered the stuff here and used up too many 8 color palettes.

Sonic: A bit gritty, though maybe it has more to do with the overpopulation of features/characters which happens in mockups. Trying to pay heed to the color identity of the original game with the dark sky and colored background. Can't do parallax so maybe background tiles should be more fogged than in the original, or they might look like foreground stuff. Maybe some fog on the lake to get the same effect as the bright water in the original (odd since the sky is so dark).

Section Z: The guy is orange-ish ingame and purple-red in the cutscenes and red in the art.

Chaos Angels: If the system has a real bitmap mode (probably only fast enough for visual novels and the like), maybe Chaos Angels might look something like this. I didn't optimize the palette into little 8x8 chunks, because then I'd need to be clever and patient Doable though. 16 colors used here for both BG+FG.

Metroid: WIP. I'd like for the background here to be a clean black. Any background elements should be subtle and interactive. I don't quite like feeling like there's a world in the background that I can't access, so I'm probably not gonna do any faded blocks or so. Plant life is fine because it's organic and flowing, not looking like anything which can be stood on, and it exists right behind the foreground plane. As for enemies, I'd like them to have some more behaviors, giving them a life of their own. Simple behavior for humanoid enemies feel inappropriate because we expect a certain complexity from something human. It's less noticeable on "things", such as the popup cannons in Megaman 1, or maybe Metroid's limbless rippers. A Zoomer might stop and clean its mandibles like a fly. I'm thinking the Skree will only explode if it hits close to the player, otherwise it will waddle around like a bat and maybe jump.

...Couldn't resist adding some ancient Chozo machinery. I'm thinking these... invasive vacuum tolerant scalemail pancake corals came and grew all over the place, so I hid some gizmos inside the blocks.

The Turtles and Shadow of the Beast mockups highlighted some problems with missing values in the green ramp. Shadow of the Beast can't really be done with this palette because of the long desaturated ramps, so I made a saturated version with the same hues. However, it seems I don't have any ramps around the light gray.

Psycho Fox: I didn't have just the right orange for the fox, so I used light, shadow and saturated edge to give the surface some vibrancy, but ended up sort of breaking my color count limits in the process. Garbled terrain, still. I might refine it later. The dirt had some strange ultra yellow happening with no special texture (hints of a rhomboid?) so I didn't know where to take that. I'll have to redo.

Fantasy Star and Gods: Wanted to test the pastel range out here. I guess it sort of works. Gods made me realize that I needed another grayish color so I eventually made that (gray teal) but didn't use it much on the mockup. I failed to mix one with just dithering.

Wonderboy (Wondergirl): I didn't have the appropriate yellows so I did some dithering and buffering just so I could stay close to the color identity of the game. The blue hair is a homage to the skateboard helmet Wonderboy wears. I saw the original game in action on a cruise ship way back, and remember being very impressed by all the cool things which could happen in the game. I guess to a child's imagination a game can seem boundless like that. I redid some of the colors in V.6 so the mockup looks slightly better now.

Megaman (Megagirl): I dreaded doing this mockup because it's such an important game. I was dismayed that my V.5 palette lacked the correct flat blues, but by using a mix of light and shadow I could sort of approximate the colors. With 8 colors I don't need an extra sprite for the face, but I boldly added a ponytail which will be flailing about.

Shatterhand: Sloppy test to see what I could do with those oranges. Decided to hue shift a lot as I didn't have the exact original colors. Gave the guy a metal fist because he's all about punching stuff. I never actually played the game.

Bosconian: Just a bunch of greeble atm. I'm thinking the dreadnoughts whatever have modules attached which spew forth different threats. The early ones have more harmless modules and exposed cores.

Pinball An unfinished mockup of a Pinball board, based on Pinball Dreams' Nightmare/Graveyard. V.5 of the pal on this one, but it's all simple flats. It should probably be 320px wide. I used the width of the NES board here.

Additional: Zelda dungeon test.

64 color palette by Arne

Ghosts'n Goblins / Makaimura /Gargoyle's Quest: It's interesting how the latter created a living world of monsters. Not sure what kind of game I'd like to make here, but playable monsters would be fun.

Wonder Boy: More enemies, a lot of them from the third, rather nice looking game.

Mônica: Another Wonderboy mockup. Gave her a bunny helmet as I could not stand her comb-over. I mean, really, a baby and balding already? Mônica is a sort of Brazilian version of Giana as I see it, except Giana has hair in abundance of course.

Pac-man: Flip!

Alex Kidd: Turned him into a monkey and gave him a gun (bubbles?) instead of the stupid janken stuff. I'm thinking this game could have several playable characters.

Puyo Puyo: Quite hungry for colors this game, but I think I managed to stay within my restrictions. The game has some fun characters, a legacy from its origin as an RPG.

Lost Vikings: Olaf gave me a lot of trouble. Had to give him a white beard instead of yellow to stay under 8 colors. With all 3 vikings on screen the enemies will have to borrow their palettes. Seems to work. Never actually played this game.

Madoola: Lots of enemy frames/activities would make them seem less like cardboard targets.

Layla: Another gal-game which seems pretty interesting.

Centipede: Best kept simple? Lot's of fun could be had on the designer's part, adding all sorts of embroideries. I used the art of the arcade cabinets as reference for some of these sprites.

Cosmic Soldier: Some of the best title-screen breasts around come from Cosmic Soldier. An unfortunate case of weirdo-thong tho. Interesting series!

Dredd: I don't think the NES had a Dredd game. These kind of games easily turn into dumb shooty platformers without the richness of the comics.

Gauntlet: One of those games which... touches on an appealing concept but isn't quite the embodiment of it. I like how it's digital (tiley) and very spammy but it could probably be deeper and more satisfying destruction-wise.

Moon Patrol: Tempting to turn this into a physics game, but physics are quirky and untrustworthy... kills that whole precision jump feel.

64 color palette by Arne

Knightmare: I have vague memories of playing this back in the day, perhaps even on the MSX. Gunsmoke was fun too, with the aiming. Would be cool to be able to plow through destructible tiles like in a... similar game I can't remember the name of atm.

Ducktales: My imagined version is about an evil Gyro Gearloose from a mirror universe causing all sorts of trouble with robotic menaces. Donald dons the battle suit.

Dogs of War: That weapon screen, so bad-ass. I remember playing Commando and Who Dares Wins, and Rambo a lot of the C64 on a tiny B/W TV. Rarely rescued the poor prisoners!

64 color palette by Arne

Made a histogram over the colors used in mockup so far. My style and color preferences probably plays in, but that very light green probably isn't very useful. Could be a bright, saturated yellow? Could be a lot of colors! Generic flasher special color.

Palette ordering

With 8 color sprites, color ramps are less important I feel (games are not likely to feature smooth gradients), so this palette isn't geared towards linear ramp structues. With no clear ramps, fading effects (and palette animation), is best done with a user defined table rather than using the natural indices of the colors in some clever way. I'm not going to try to force my colors into a hue-value structure they can't fit into anyways. So, I chose this ordering because it looks pleasant to color pick from. I couldn't find a RGB to HSV algorithm which gives the same values as Photoshop's so I skipped the Saturation and Luma rows. Maybe later. In my PALDAC section I talked about another way to order the palette.

Hex Value Int RGB Hue
0 = #000000 0.0000000.00
1 = #00177D 10.886013023125228.96
2 = #024ACA 26.30150218274202218.40
3 = #0084FF 41.79340470132255208.94
4 = #5BA8FF 60.74600703991168255211.83
5 = #98DCFF 79.8710018047152220255200.39
6 = #9BA0EF 65.6910199279155160239236.43
7 = #6264DC 44.35644834898100220239.02
8 = #3D34A5 26.5040111736152165244.78
9 = #211640 11.792168384332264255.71
10 = #5A1991 22.7959047859025145272.50
11 = #6A31CA 32.74695956210649202262.35
12 = #A675FE 57.7510909182166117254261.46
13 = #E2C9FF 84.1714862847226201255267.78
14 = #FEC9ED 86.6516697837254201237319.25
15 = #D59CFC 72.1513999356213156252275.62
16 = #CC69E4 58.2813396452204105228288.29
17 = #A328B3 36.321069278716340179293.09
18 = #871646 24.0288530621352270334.51
19 = #CF3C71 43.141358142520760113338.37
20 = #FF82CE 69.0316745166255130206323.52
21 = #FFE9C5 92.341677152525523319737.24
22 = #F5B784 76.751610330024518313227.08
23 = #E18289 62.4314779017225130137355.58
24 = #DA655E 53.0114312798218101943.39
25 = #823C3D 31.7885351011306061359.14
26 = #4F1507 14.4151827277921711.67
27 = #E03C28 41.871469546422460406.52
28 = #E2D7B5 84.081486635722621518145.33
29 = #C59782 63.671294937819715113018.81
30 = #AE6C37 47.72114309671741085526.72
31 = #5C3C0D 25.18604468592601335.70
32 = #231712 10.20229966635231817.65
33 = #AD4E1A 39.4011357722173782621.22
34 = #F68F37 64.22161585192461435527.64
35 = #FFE737 85.53167708712552315552.80
36 = #FFBB31 75.14167596012551874940.19
37 = #CC8F15 57.78134059732041432140.00
38 = #939717 53.0296724711471512361.87
39 = #B6C121 67.24119769931821933364.12
40 = #EEFFA9 94.161566301723825516971.86
41 = #BEEB71 81.431251211319023511382.13
42 = #8CD612 66.4892298421402141882.65
43 = #6AB417 54.8969929191061802388.28
44 = #376D03 31.67363238755109390.57
45 = #172808 12.2615175762340891.87
46 = #004E00 17.96199680780120.00
47 = #139D08 38.731285384191578115.57
48 = #58D332 61.1358212348821150105.84
49 = #20B562 49.8021435863218198146.58
50 = #00604B 25.452465109675166.87
51 = #005280 24.6021120082128201.56
52 = #0A98AC 43.8569444410152172187.41
53 = #25E2CD 65.53248289337226205173.33
54 = #BDFFCA 89.8912451786189255202131.82
55 = #71A6A1 58.667448225113166161174.34
56 = #415D66 33.5942837506593102194.59
57 = #0D2030 11.04860208133248207.43
58 = #151515 8.2413816532121210.00
59 = #343434 20.3934212365252520.00
60 = #7B7B7B 48.2480925391231231230.00
61 = #A8A8A8 65.88110532241681681680.00
62 = #D7D7D7 84.31141454952152152150.00
63 = #FFFFFF 100.00167772152552552550.00


Will you try to make this?

I do feel that the entire point of the project is to create (so far in imagination) a thing with presence. One can think of the project as a three legged platform, where the legs are: Unique Fun Hardware (the architecture, in particular graphics and sound), Software (OS, launch software), Spiffy Case... and Branding (Nintendo) as a bonus leg. If any of those are generic, the whole thing falls directly into the abyss of meaninglessness. That said, writing an emulator for a modern computer will be necessary. Thinking about the various costs in a mass production scenario, I'm estimating some 1-10 million USD. The Ouya had millions in budget and it was just a tiny thing using more or less generic chips, afaik. The Amiga was done in the 80's with several custom chips, and it seems to have been in the 10 million range. Real pioneer work there of course, not old hat like this.

Paper model

Paper model! Feels a tad too large. It's 15cm cubed here, with 4mm bevels. Might make that 14cm with 3mm softened bevels. Disk is exact W*H of the MF2DD seen (the photo lies a bit), but should be about 7mm thick.

Will it be upgradeable with socketed chips, GPIO etc?

It's really, really tempting, but I'm hesitant to support expansion (other than perhaps socketing the BIOS/ROM). The Famicube is supposed to offer a static standard and defined character. It is designed to be an already old thing which presumably worked as it was. It's sort of like, if you make a C64 or Amiga 500 demo then you probably won't make it for a heavily expanded version.

Circuit board

Yeah, I couldn't actually resist. No, nothing on there makes real sense, but is that a Metroidola 68K I spy? RAM used to be large arrays of chips but I don't quite care for it (though a bank of SIPs like on the X68000 doesn't look bad). Modern surface mount components like these are very compact and I like the clean look. I'm tempted to throw sexy (copper-tone aluminium, splayed fins) heatsinks on the chips and some art on the backside of the boards (rather than on the top of the chips). Oops, I think my PPU heatsink will bump into the floppy cable. I don't care where it goes, but I do want a copper tone heatsink in there! The case might be mostly empty, but the early version of the system was probably packed.


A later drawing of a graphics card. I'd substitute the scanline jumper for a trimpot in a voltage divider. A VGA signal is 0-0.7V iirc. The PPU would (on even / odd scanlines) supply 0.7 / 0.7 through Voltage divider to VREF on my PAL-DAC? The PAL-DAC might need 15 pins minimum for 6-bit parallel in. Oops, 448x252 is not a multiple of 8. Maybe a 4:3 picture is OK anyways, most TVs support it. It's half of classic VGA so then I can output a doubled picture. I'm thinking of maybe offsetting it sideways 1 px sideways every other frame for a more authentic CRT blur effect (interlaced offset?). I'm also thinking about using 4 sets of the 64 palette for the 2x scanline effect, at least in emulation. This will allow a sort of brick appearance, e.g.:
Bright row 100% x 100%, 90%
Darker row: 70% x 90%, 100%
...but it doesn't work with a voltage divider then I think.

Is this fantasy console realistic (for its time period)?

...Vaguely. I've scaled up the RAM and CPU quite a bit to make it easier to develop on. The Amiga 500 had 512KB RAM and a 7MHz CPU at the time (it was initially expensive compared to a NES). I wouldn't go above 16MHz and might go below. I'm pretty sure that my suggested components (certainly the money spent on them) could've been used to make a far more powerful console graphically. In my backstory I've made excuses for the PPU being a bit dated. Other parts of the design were upgraded over time but the PPU stayed. As a side note, if you want a powerful console nowadays, why don't you develop for the Ouya? You could draw scaled and rotated 24-bit "retro" pixels with awesome openGL quads :o

Why a tiled PPU with fixed palette?

To give the console an identity, though 16 colors does this even more effectively. Of course, a fixed palette makes a bit less hardware sense nowadays, but perhaps having it hardwired in circuit can speed things up a little (no memory access). My PPU does sort of make bit-sense, by the way. I've written a (partial) emulator for it, but it currently outputs to a 32bit frame buffer / window just so I can see what's going on. Anyways, if you don't like to be confined by a certain look and feel, check out the Ouya? I read that it can do millions of open source colors.

Why a floppy disk?

Because floppies have the right capacity, physical feel (cartridge'ish), price, and label space. Also, the drive sound adds a lot of character. I remember being able to tell when I had a virus by listening for the drive acting suspicious. But hey, if you like silent hidden flash storage, I hear the Ouya is quite neat. The games could all be loaded from a text menu, a picture grid, or even the cloud!!! I'm sure that when it's so quick and easy to get a game booted, you'll never hesitate to play with your Ouya.

Any similar projects?

Single Board Computer, Amiga, MSX/JSM, Acorn/Beeb, Misc, Rotro

Is the case design final?

I sort of liked it early on, but now it's starting to feel a bit too monolithic. The colored panels and decals make up for that a little, but after having seen (and bought) the MSX machines by SONY (see link above), I'm... very tempted to explore some more. I don't want to end up with a design too close to the Ouya after all...


Fooling around, not quite getting my idea down on paper. I like how old datacorders in Japan were vertical, like boombox cassette decks, so I wanted to play around with that aesthetic.

SEGA tangent

Sega Master System

A Sega Master System version, packaged like an "Elite" ship. PPU might work differently here, using two 16 color palettes for the background and sprites. It's really a bit surprising (and dissapointing) that the SMS didn't have better looking games overall, with such (relative) graphical prowess.

Sega Master System Game Gear

The Sega Master System has character, but the Gamegear design fell a bit flat, in my eyes at least. This is how I'd do a modern re-release. I quite like the asymmetric, angular look and don't think I'd mind holding it. I'm OK with NES joypads after all. Shoulder buttons might need to be longer/moved in. Hmm... The Sega Gamegear logo should be like a Dreamcast swirl forming a square/pixelated G.

Speaking of the SMS, The white/blue Sega Mark III design (the SMS in Japan) is good too, very striking. Too bad they removed the text blurb from the Mark II!

NES classic/mini

NES classic cube concepts

I think I'd actually prefer an original case designs for these mini Nintendo consoles. It would make them feel more like they are their own thing, and not just an ARM chip in a mostly empty plastic box which lies about taking cartridges. I added the LED array to have an extra, original element to be curious about. "It's an [X], but also something else." (A real DATA-MACHINE in YOUR home.)

Art by Arne Niklas Jansson