NesDev designs a console

[pubby]

Recently I've been reading Agner Fog's message board where he and others discuss creating an open source instruction set. It's interesting stuff, so if you have 30 minutes you might want to check it out.

Anyway, this got me thinking:

What would it look like if NesDev designed an imaginary 8-bit video game system? We could come up with our own design for a CPU, PPU, and APU, and have fun discussing the options.

So let's try it!

Let's start out with some basic specs:

• 4KB RAM
• 8-bit CPU
• 16-bit address space

For the PPU, I'm thinking a window size of 256x224 with nametables of size 256x240 would be good. This gives 16 extra VBLANK scanlines vs the NES, and allows 4-way scrolling to hide tile updates in the off-screen section.

For the CPU's instruction set, I think it's important that it be compatible with C, as that would make the system much more accessible. I don't know what the ISA should look like, however.

What do you think?

[tepples]

Three words:

Turbo
Grafx
Sixteen

[zzo38]

I had a design for PPU that had its own instructions that it could execute during hblank/vblank (and the program always restarts from the beginning during each vblank), and then the PPU is clock-interleaved with the CPU, so that they can share memory without conflicting.

My ideas for another computer it had the "video instruction set" as follows:

• 0: JMP: Jump to the operand's address. (If the operand is immediate, treats it as an instruction.)
• 1: WAI: Same as JMP but wait for the next hblank before continuing.
• 2: ROL: Rotate left operand value through carry, and store result in A.
• 3: ROR: Rotate right operand value through carry, and store result in A.
• 4: ADC: Add operand value with carry to A.
• 5: CMC: Complement carry flag; operand is read but ignored.
• 6: SBC: Subtract operand value with carry from A.
• 7: CMP: Subtract operand value from A (without carry); update carry flag but do not update A.
• 8: AND: Bitwise AND operand with A and store in A.
• 9: ORA: Bitwise OR operand with A and store in A.
• 10: EOR: Bitwise XOR operand with A and store in A.
• 11: SAR: Write value from A into video register specified by operand. (This includes the playfield address, palette, modes, and other stuff.)
• 12: LDA: Load operand value into A.
• 13: LDB: Load operand value into B.
• 14: STA: Store A into operand. (You can write to an immediate value.)
• 15: STB: Store B into operand.

The video instruction set also has one flag (carry), two 8-bit accumulator registers (A and B), and each instruction also has an addressing mode (A, B, 8-bit immediate, or 16-bit absolute), and a condition code (never, if carry clear, if carry set, or always). Note also that this enables tile height to be any number, because it is programmed by software.

Note that the CPU would have its own instruction set, not the above.

For audio, there is some kind of ideas. You could have different channels that act differently, and maybe even some like SID, some like GameBoy, etc. One idea I had is you could have a "IDFX" channel. There are four 4-bit numbers, called I, D, F, X (in addition to the period, which is separate). If the phase is p, and output volume is v (0 to 15), then (as a C code): v=(((p&I)^(p<D?15:0))&F)^X

You could also have additional RAM in the cartridge if 4K is insufficient, like it can be on NES/Famicom.

I also think there should be both keyboard and game controls, and possibly even Forth built-in that can be executed when no cartridge is present (you may then save the program on a tape, if you want to keep it; usually you would use ROM cartridges though; the Forth is just something extra).

You may vary these things; all of the above are just ideas, and you can do differently if you want to do.

[lidnariq]

... Good for C? On an 8-bitter? Er.

Just how much cheating is allowed?

Can I choose a 16-bit machine that's contemporary? (CP1600) Can I choose an 8-ish-bit machine that's substantially later? (AVR;1996) How about a 16-bit ISA that's older than the AVR? (MSP430;1993) ... How about a 32-bit ISA that's substantially older? (MIPS or ARM; 1985, both with prototypes back to 1980)

Honestly, if I wanted to make something "Like the NES, but less bad for C" I'd end up very close to the SMS.

[Rahsennor]

I've been doing this in my head for ages. So many silly ideas, so little time. I even wrote an emulator for my APU design, the FRA1, though I'm still not convinced it would actually work in period-accurate silicon.

[pubby]

@zzo38: This is an interesting idea!

Can I choose a 16-bit machine that's contemporary? (CP1600) Can I choose an 8-ish-bit machine that's substantially later? (AVR;1996) How about a 16-bit ISA that's older than the AVR? (MSP430;1993) ... How about a 32-bit ISA that's substantially older? (MIPS or ARM; 1985, both with prototypes back to 1980)

The three guidelines are:

• Possible to be manufactured using 1985 fabrication methods
• Fit what people imagine when they think "1985 game console"
• Be decently cost effective

IMO 32-bit CPUs are out of the question because that's not how gamers remember the era.

You can use modern instruction sets if they're not too complicated, though honestly, when I started this thread I was hoping people would come up with their own wacky instruction sets instead of using existing ones - not because they would be better, but because I think it's fun to start from scratch

I've been doing this in my head for ages. So many silly ideas, so little time. I even wrote an emulator for my APU design, the FRA1, though I'm still not convinced it would actually work in period-accurate silicon.

Have you published anything about it?

[madbrain]

Writing a C backend is not for the faint of heart. Something like LLVM is designed for 32bit machines with a bunch of identical registers, no flags, automatic sign/zero extension, flat addressing space and [register+offset] addressing and so forth.

[nicklausw]

Is there a limit on number of registers? That's pretty detrimental to the whole C thing important in terms of making the CPU C-friendly, for better wording.

[madbrain]

Is there a limit on number of registers? That's pretty detrimental to the whole C thing.

It depends on how registers are accessed. In 1985, arcade games had started using FM chips like the OPM and OPN and OPL, and those have over 200 bytes of registers which is pretty massive for the time. This is because they're all large shift registers that are always accessed in the same sequence and constantly get refreshed, which makes them very efficient to implement. (this is also why the tg16's audio chip works the way it does)

[Oziphantom]

50Mhz 4510 CPU
128K-512K RAM
Graphics chip with sprites, bitmap and char mode. Should be 256 colours per each, so 256 colour sprites, 256 colour chars
1080p graphics with modern output HDMI/DP etc
DMA engine
Blitter

so basically just a MEGA65
http://c65gs.blogspot.com.au/
http://mega65.org/

[Rahsennor]

Have you published anything about it?

Not yet. It's a 4-bit wavetable chip similar to the N163 or PCE, but designed to stream samples from external memory by stealing a few bytes from each scanline of the PPU's fetch pattern. Other than what's involved in doing that, avoiding aliasing and a neat little sample compression trick, there's not really much to it.

Here's a demo rendering, using my crappy homemade samples and a random MIDI. 6 MHz host clock, 6 channels and 128-byte samples (I think only 4 of them are actually used in this clip, so that's 512 bytes total).

[tokumaru]

I love the 6502, but if I could improve anything about it, I'd expand the support for addressing modes (indirect addressing using the X register, for example), and maybe add another index and possibly even another accumulator. I don't really care about C, coding in assembly is more fun!

nametables of size 256x240

Oh, come on! Why can't we go for nice power-of-2 dimensions to make scrolling easier? Getting the attribute tables out of the way already helps a lot with vertical scrolling even if name tables are 240 pixels tall, but 256 pixels would make things much cleaner overall, and even provide some extra room for the scroll seam (useful for 32x32-pixel metatiles maybe?).

Other than that, I find the idea of 3bpp graphics really interesting, that combined with a decent number of palettes (maybe 8, shared between sprites and the background) could produce really nice graphics. A larger, more consistent master palette than what the NES has would be very welcome. Other PPU features I'd want are more sprites per scanline (16 would probably be OK, but the more the better) and a built-in scanline counter. Background attributes such as tile flipping and priority (in front or behind sprites) would be cool too.

[pubby]

Other than that, I find the idea of 3bpp graphics really interesting, that combined with a decent number of palettes (maybe 8, shared between sprites and the background) could produce really nice graphics.

I was thinking about having only a single pattern table with 4bpp. This allows 15 colors per sprite, but you can also combine two 2bpp tiles into one 4bpp tile, or four 1bpp tiles into one, etc.

Oh, come on! Why can't we go for nice power-of-2 dimensions to make scrolling easier?

I like this idea but you need to come up with how attributes/tile colors exist in memory.

[Drew Sebastino]

16GB RAM
64-bit CPU
48-bit address space

[lidnariq]

name tables [ that are ] 256 pixels would make things much cleaner overall, and even provide some extra room for the scroll seam

It'd also be nice to not treat PAL consoles as second class. Supporting a 256x256 mode would be awfully close to full screen...

Other than that, I find the idea of 3bpp graphics really interesting, that combined with a decent number of palettes (maybe 8, shared between sprites and the background) could produce really nice graphics. A larger, more consistent master palette than what the NES has would be very welcome. Other PPU features I'd want are more sprites per scanline (16 would probably be OK, but the more the better) and a built-in scanline counter. Background attributes such as tile flipping and priority (in front or behind sprites) would be cool too.

And that's basically what I meant by "I'd end up with the SMS". Fix the obvious awkwardnesses of the NES (e.g. 8.5 bits per nametable entry obviously becomes 16 bits; increase bit depth of both sprites and backgrounds from 2bpp to 4bpp, enlarge the source palette from 56 colors to 64), switch to a more-nearly-C-friendly ISA (Z80 is better than 6502 for that),

I mean, not that the SMS is flawless. There's plenty things I'd take from the NES side of the equation, too (such as the ability to do any interesting raster effects at all, the external PPU data bus, a sound IC that doesn't hurt to listen to), but ... all things said, it'd be closer to the SMS.