Famicube

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?

- A static 64 color palette will create a certain overall color feel.

- The tile based PPU and 8 color/tile limit will encourage certain designs and aesthetics, reminiscent of the NES whilst not being as ruthless with color restrictions.

- The sound chip is bound to bring some recognizable character to the audio.

- The console case will create a physical identity for the console itself. DIY consoles have none, and modern consoles have become very minimalist, don't you think? It's like they don't want to be seen, camouflaging themselves as generic monotone (monolithic) living room devices.

- The joypad design can limit and encourage certain designs and simplifications.

- Last but not least, real floppy disks turn game media into something which can be touched, and certainly heard! You'll never wonder if something is loading or not. And when bored one can fiddle with the springy dust cover or browse the manual. For me, floppy disks vs SD card files is like... real pinball machines vs video game pinball. A physical game can sit on the shelf where you can feast your eyes on it while smoking a pipe, nodding with pleasant memories.

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

!Image 1: Famicube

!Image 2: Famicube

!Image 3: Famicube concept by Arne

!Image 4: Ataricube concept by Arne

!Image 5: Twin Famicom cube concept by Arne

!Image 6: Twin Famicom joy concept by Arne

!Image 7: Twin Famicom keyboard concept by Arne

This is a BASIC oriented keyboard so certain characters need to be more visible than others. I replaced the dollar sign (strings symbol) with the region neutral currency turtle/sun. Dollar, pipe etc could sit in the shift-alt layer, unmarked. I've added a diacritic deadkey top right for Swedish, German, etc. Japanese can be typed using syllables. Like on the BBC Micro, a clear plastic bar can hold a reference sheet over the function keys.

Toploader,

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

Duopad concepts

Duopad schematics

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.

Prelude

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.

!Image 8: A mystery.

!Image 9: CNES-88 concept by Arne

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.

- **CPU:** 8MHz with 20-bit address bus (1MB). 68PLCC?

- **RAM:** Upgradable (cards with SIP banks). The Famicube came in 256kB, 512kB and 1MB versions.

- **ROM:** Serial 256kB which loaded into early RAM on boot. Socketed EEPROM 8-PDIP in later versions.

- **Sound and I/O:** VRC6, or "Pauline" chip: Essentially a SID clone with additional 4-bit 32 sample/step wavetables. It's controlled by a small 8-bit CPU (6502 coprocessor?) with access to dedicated audio RAM (16-bit address space). It can operate independently from the rest of the system (main memory bus/CPU).

- **Video:** "Daisy" (Ricoh PPU II): See PPU section.

- **VRAM:** 64kB. Still unsure if shared with main RAM. Would be nice to map VRAM and a regular ROM with RAM space. But I don't know much about memory contention. Maybe just for the pixel mode.

- **Media:** 3½ inch 720kB microfloppy drive with a custom controller to thwart piracy.

- **Ports:** Unlike cartridges, floppy disks can't contain chips to increase the performance of the system. For this reason an expansion port was provided. There was also a data transfer port on the side. The front has two joystick ports, to which a joypad, mouse, or keyboard can be connected. Communication is mostly serial using shift registers.

- **BIOS:** NintenDOS 4.1

- **Launch price:** Due to the ordeal with Commodore, Nintendo missed the xmas launch of '87 (priced at under 200$). Instead the system launched summer '88 for the somewhat pricy 269.99$. This included only one joypad and the peculiar "programmable" game Construction Crew which was meant to showcase the floppydisk saving capability of the system. However, the game was too cerebral. The next quarter a new base system was released, containing two joypads, a simple Mario Bros port and also Super Mario Adventure which perhaps was meant to be included at launch but got delayed. Oddly enough this was strictly a one player game (though Mario Bros was not), whilst Construction Crew was playable by two players cooperatively. By the xmas of '89 the price had gone down to 179.99$ and the game library was rapidly growing, though mostly with Nintendo's own ports of earlier NES games. Because the system was expandable it survived well into the late 90s in certain markets, despite competition from the Nintendo Playstation, MSX 4 and SEGA Dreampod.

PPU design

- 320x240 resolution, 64 color hardware palette.

- Tiles: 2 background and 2 foreground tile tables with 8 colors, and 2 + 2 more tables with 1 color tiles. Each tile bank has 256 8x8 pixel tiles. In VRAM, tile tables take 2K for 1-bit (x4), 6K for 3-bit (x4), 32K total. A ROM contains default (BIOS) tile tables for the system characters (font and common symbols) and OS icons.

- Name table: The Name table uses up a full byte for character selection because there are 256 tiles.

- Attribute table: The tile table selection data (0-3) goes in the Attribute table along with palette selection (0-3). 2 bits + 2 bits, i.e. half a byte is used per tile in the Attribute table, so the Attribute table is half the size of the Name table. If the tile table 3 is selected along with palette 3, the tiles above 192 will be rendered as simple flat blocks using colors 0-63.

Byte:b7 b6 b5 b4 b3 b2 b1 b0 Name Table:8-bit Tile select (0-255) Attr Table:2-bit Table select (0-3)2-bit Palette select (0-3)(next entry)

- Palettes: 4 background and 4 foreground palettes with 8 colors from a static 64 color palette. Unlike the NES, only the foreground sprites have a transparent first index, so hiding sprites behind background tiles is a more quirky affair using sprite tricks.

- 80 simultaneous sprites on screen, 32 per line. Flags for flipping and solid color flashing (using a global flash color). Draw priorities. Collision detection. No scaling or rotation. 8x8px up to 16x16px size in increments of 8.

- 64kB PPU VRAM, half is used for tiles and the rest for many (18 or so) screens worth of Name table and Attribute table space. This design was intended to make scrolling routines and tile persistence logic faster and easier to handle. Some of this VRAM is sometimes used for general storage though (some advanced scrolling routines use much less name table space). The built in screen display function can take several parameters allowing screen tile data to be mapped in say, long strips or large square-ish playfield (known as a Zone).

- Horizontal split screen using some type of interrupt / scanline sheenanigans.

!Image 10: Famicube Schematic

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:

- **MODE 0:** This is the default mode detailed above. Late in the Famicube's life, a new PPU board was released, adding two modes rather than improving the existing one (for backwards compatibility reasons).

- **MODE 1:** Aka SEGA Master System mode. If I was having a general PPU made, I'd include this mode. It would be similar to MODE 0, but it uses 1+1 16 color palettes instead of 4+4 8 color palettes. There are four 16 color tile tables taking up 8K each, and these can be either sprites or background tiles. The Attribute Table has no palette select, but it can select any of the four tile tables. It is half the size of a MODE 0 Attribute table since only 2 bits are used to select table. Color 0 is transparent for both background tiles and sprites. Sprites can thus be drawn behind the background if flagged for it.

- **MODE 2:** Screen mode. The PPU can place a pointer anywhere inside VRAM and draw the contents as a 320x240 16 color image (38K, packed pixels). The pointer can be moved at scanline porch, and a different palette can be selected (as a pointer, or from a set?). There's also a "blit" function for quickly copying memory from one place to another. Perhaps the PPU can also do burst mode input/output. The 16 colors come from the 64 color palette. Games like Lemmings and Elite, or Paint programs would benefit from this mode.

PPU dev page.

ROMDAC? PALDAC?

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.

!Image 11: 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.

!Image 12// ------------------------------------------------ // Verilog-AMS ROMDAC / PALDAC // 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, in_color_index, 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; endcase

// 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);

end

endmodule

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.

NintenDOS

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?

!Image 13 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.

!Image 14: FAMICUBE PPU emulator

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

!Image 15

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.

!Image 16

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.

Connectors

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

!Image 17

!Image 18: Keyboard and mouse

Keyboard with too many keys?

!Image 19: MF2HD

Palette mockup

!Image 20: 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.

!Image 21: 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.

!Image 22: 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!

!Image 23: 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 | R | G | B | Hue | | --- | --- | --- | --- | --- | --- | --- | | 0 = #000000 | 0.00 | 0 | 0 | 0 | 0 | 0.00 | | 1 = #00177D | 10.88 | 6013 | 0 | 23 | 125 | 228.96 | | 2 = #024ACA | 26.30 | 150218 | 2 | 74 | 202 | 218.40 | | 3 = #0084FF | 41.79 | 34047 | 0 | 132 | 255 | 208.94 | | 4 = #5BA8FF | 60.74 | 6007039 | 91 | 168 | 255 | 211.83 | | 5 = #98DCFF | 79.87 | 10018047 | 152 | 220 | 255 | 200.39 | | 6 = #9BA0EF | 65.69 | 10199279 | 155 | 160 | 239 | 236.43 | | 7 = #6264DC | 44.35 | 6448348 | 98 | 100 | 220 | 239.02 | | 8 = #3D34A5 | 26.50 | 4011173 | 61 | 52 | 165 | 244.78 | | 9 = #211640 | 11.79 | 2168384 | 33 | 22 | 64 | 255.71 | | 10 = #5A1991 | 22.79 | 5904785 | 90 | 25 | 145 | 272.50 | | 11 = #6A31CA | 32.74 | 6959562 | 106 | 49 | 202 | 262.35 | | 12 = #A675FE | 57.75 | 10909182 | 166 | 117 | 254 | 261.46 | | 13 = #E2C9FF | 84.17 | 14862847 | 226 | 201 | 255 | 267.78 | | 14 = #FEC9ED | 86.65 | 16697837 | 254 | 201 | 237 | 319.25 | | 15 = #D59CFC | 72.15 | 13999356 | 213 | 156 | 252 | 275.62 | | 16 = #CC69E4 | 58.28 | 13396452 | 204 | 105 | 228 | 288.29 | | 17 = #A328B3 | 36.32 | 10692787 | 163 | 40 | 179 | 293.09 | | 18 = #871646 | 24.02 | 8853062 | 135 | 22 | 70 | 334.51 | | 19 = #CF3C71 | 43.14 | 13581425 | 207 | 60 | 113 | 338.37 | | 20 = #FF82CE | 69.03 | 16745166 | 255 | 130 | 206 | 323.52 | | 21 = #FFE9C5 | 92.34 | 16771525 | 255 | 233 | 197 | 37.24 | | 22 = #F5B784 | 76.75 | 16103300 | 245 | 183 | 132 | 27.08 | | 23 = #E18289 | 62.43 | 14779017 | 225 | 130 | 137 | 355.58 | | 24 = #DA655E | 53.01 | 14312798 | 218 | 101 | 94 | 3.39 | | 25 = #823C3D | 31.78 | 8535101 | 130 | 60 | 61 | 359.14 | | 26 = #4F1507 | 14.41 | 5182727 | 79 | 21 | 7 | 11.67 | | 27 = #E03C28 | 41.87 | 14695464 | 224 | 60 | 40 | 6.52 | | 28 = #E2D7B5 | 84.08 | 14866357 | 226 | 215 | 181 | 45.33 | | 29 = #C59782 | 63.67 | 12949378 | 197 | 151 | 130 | 18.81 | | 30 = #AE6C37 | 47.72 | 11430967 | 174 | 108 | 55 | 26.72 | | 31 = #5C3C0D | 25.18 | 6044685 | 92 | 60 | 13 | 35.70 | | 32 = #231712 | 10.20 | 2299666 | 35 | 23 | 18 | 17.65 | | 33 = #AD4E1A | 39.40 | 11357722 | 173 | 78 | 26 | 21.22 | | 34 = #F68F37 | 64.22 | 16158519 | 246 | 143 | 55 | 27.64 | | 35 = #FFE737 | 85.53 | 16770871 | 255 | 231 | 55 | 52.80 | | 36 = #FFBB31 | 75.14 | 16759601 | 255 | 187 | 49 | 40.19 | | 37 = #CC8F15 | 57.78 | 13405973 | 204 | 143 | 21 | 40.00 | | 38 = #939717 | 53.02 | 9672471 | 147 | 151 | 23 | 61.87 | | 39 = #B6C121 | 67.24 | 11976993 | 182 | 193 | 33 | 64.12 | | 40 = #EEFFA9 | 94.16 | 15663017 | 238 | 255 | 169 | 71.86 | | 41 = #BEEB71 | 81.43 | 12512113 | 190 | 235 | 113 | 82.13 | | 42 = #8CD612 | 66.48 | 9229842 | 140 | 214 | 18 | 82.65 | | 43 = #6AB417 | 54.89 | 6992919 | 106 | 180 | 23 | 88.28 | | 44 = #376D03 | 31.67 | 3632387 | 55 | 109 | 3 | 90.57 | | 45 = #172808 | 12.26 | 1517576 | 23 | 40 | 8 | 91.87 | | 46 = #004E00 | 17.96 | 19968 | 0 | 78 | 0 | 120.00 | | 47 = #139D08 | 38.73 | 1285384 | 19 | 157 | 8 | 115.57 | | 48 = #58D332 | 61.13 | 5821234 | 88 | 211 | 50 | 105.84 | | 49 = #20B562 | 49.80 | 2143586 | 32 | 181 | 98 | 146.58 | | 50 = #00604B | 25.45 | 24651 | 0 | 96 | 75 | 166.87 | | 51 = #005280 | 24.60 | 21120 | 0 | 82 | 128 | 201.56 | | 52 = #0A98AC | 43.85 | 694444 | 10 | 152 | 172 | 187.41 | | 53 = #25E2CD | 65.53 | 2482893 | 37 | 226 | 205 | 173.33 | | 54 = #BDFFCA | 89.89 | 12451786 | 189 | 255 | 202 | 131.82 | | 55 = #71A6A1 | 58.66 | 7448225 | 113 | 166 | 161 | 174.34 | | 56 = #415D66 | 33.59 | 4283750 | 65 | 93 | 102 | 194.59 | | 57 = #0D2030 | 11.04 | 860208 | 13 | 32 | 48 | 207.43 | | 58 = #151515 | 8.24 | 1381653 | 21 | 21 | 21 | 0.00 | | 59 = #343434 | 20.39 | 3421236 | 52 | 52 | 52 | 0.00 | | 60 = #7B7B7B | 48.24 | 8092539 | 123 | 123 | 123 | 0.00 | | 61 = #A8A8A8 | 65.88 | 11053224 | 168 | 168 | 168 | 0.00 | | 62 = #D7D7D7 | 84.31 | 14145495 | 215 | 215 | 215 | 0.00 | | 63 = #FFFFFF | 100.00 | 16777215 | 255 | 255 | 255 | 0.00 |

FAQ

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.

- ASICs: I'd really like to have a custom PPU chip made (unsure about sound chip), rather than having software running in a generic powerful chip, or using an FPGA. ASICs are really expensive to make, though this PPU would be relatively simple. It could possibly be sold separately as a hobbyist GPU (something that's sort of missing from the market now?). Hard to find figures on ASICs, but it might be in the 10-100K ballpark for something quite coarse in detail (over >1 µm I suspect, not exactly doing an i7 processor).

- Off-the-shelf-ICs: A megabyte of (S)RAM is 1.5 - 3 dollars, and a 512 kilobyte EEPROM PDIP-8 seems to be about 1.5 dollars. A CPU in my range generally seems to be about 4 - 15 dollars (I'm just using digikey here). Couple of candidates: A 680x0 because I like the Amiga and some versions have a Famicom'y brass plate on top. Some Z80's now have a larger addressing space, like the Z80180 68PLCC which I'm currently considering. The CPU should be pretty clean and for-purpose however. A lot of modern ones have a bunch of... out-of-character stuff. A solution is needed for address decoding, IO, and various glue. CPLD?

- System architecture and PCB engineering: This might not be a huge task, we have very good design tools nowadays and a "retro" computer is known territory. Maybe 6 months of work for sourcing components, laying out the boards? Manufacturing custom PCBs has fortunately gotten cheap and easy, along with SMD pick and place.

- PSU: With low power modern chips, I suppose one could get away with using a little neat switching power supply placed on a separate board so it can be swapped for different regions, or if it breaks. Many take 110V-220V AC nowadays. An off the shelf one would work. I could even imagine using an external "brick" (5V PSUs are hardly bricks anymore).

- Floppy drive: Who knows... perhaps floppy drive factory stuff is sold off cheap because it's an obsolete technology? Could also be a lost art. If I can't have fatter floppies, I'd at least go for some relief on the casing. Maybe it would be neat to have the rear side in black, front in maroon, and metal in brass/gold, label in cream. Most drives are probably USB now (too much overhead) but perhaps replacement boards could be made for existing drive mechanisms.

- Plastics: Tooling for the plastic components (case, joypads) is quite expensive, but I think it has come down in price quite a bit over the decades, and the moulds for this preject are pretty low detail. A limited run would likely use the cheaper aluminium moulds, which can go as low as 10K at the right plant. I would need several though. Then there's metal folding work done for RF shielding. I'm thinking armour on case sides like in a PC tower, rather than annoying heat trappers screwed directly over the MoBo, though sometimes those double as sinks. Also need some rubber membrane stuff for joypads.

- OS and included software: Quite significant costs here. Two years, five people is 10 man-years at... what - 50K/Y minimum? Much more for office, HW and admin.

- Assembly: Given the target demographic, this thing could easily be a kit? It should be built to be taken apart anyways.

- IP: Another problem is that I'm using a lot of IP that's not mine as basis for the mockups. Because this is designed as a Nintendo console, at the same time being a nice product for people who would definitely want it, at least marketing would take care of itself.

!Image 24: Paper model 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.

!Image 25: Circuit board!Image 26: Card 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...

- * *

Art by Arne Niklas JanssonAndroidArts.com