Just last night with a half hour to go before the new decade, I finished soldering the last board for my game console. (With the caveat that this is the non-compactized proof of concept version)

I haven't done much on the software side yet, other than a sound test program that plays "Solfeggietto" by C.P.E. Bach on the first square wave channel.

The specs are:

• 128x100 256-color graphics over composite video (NTSC)
• Sound generator with 2 programmable square waves, a programmable LFSR noise channel, and a PCM sample looper
• Two controller input ports compatible with Sega Genesis controllers, (possibly also with Atari/C64 controllers but I hadn't thought too hard about those)
• DMA controller for copying rectangular sections of dedicated Graphics RAM (assets) into Video RAM (framebuffer)
• Currently has a 3.5MHz oscillator installed as main clock. Might push this higher, but with the DMA I might not need to.
• Cartridge port exposes IRQ, Reset, and Clock; connections to the audio output lines; as well as an I2C port driven by the 65C22 VIA

Apart from the WDC 65C02, VIA, memory, and analog chips, the ICs are 74HC series. (Except for the one 74LS07 used as an open collector IRQ driver). Anywhere that the schematic says otherwise is because I'm too lazy to re-label the parts in the EagleCAD libraries.

Some more info:

• The "256 colors" spec comes from having 8bpp, mapping 3 bits to luma and hue with 2 bits for saturation. Because hue (shouldn't) matter when saturation is zero, I've set it up to use the hue bits as extra luma bits when the sat bits are zero. Still have to test this part, as expanding the resistor ladder DAC on my breadboard seemed too daunting. (Though now that I look at it again, maybe I should've just used the 7524 DAC chip I used on the soundcard. So this is what they meant by "Hindsight is 2020")
• The soundcard has a 4 kilobyte dual-ported SRAM for its wavetable. Programmable counters march through the address space, and the data output is connected to the input of a DAC. The counters get reloaded whenever the RAM outputs a 0xFF byte, or when the register holding the start address gets written.
• Not shown in the photos is that this prototype actually requires connecting the select pins on the expansion cards to headers on the address decoder with jumper wires. Convenient-ish for prototyping because it makes the system more modular, but it's also kind of ugly and I wish a little bit that I just included these select pins on the backplane headers.
• The cartridge loaded in the picture is a hastily-cobbled ZIF socket adapter.

I've been working on/towards this for about a year and a half now, on-and-off. My background is in software engineering and gamedev so I've been learning as I go. My previous electronics experience mostly consisted of premade Arduino and Raspberry Pi modules. I had played a couple of games centered around hardware design and assembly programming, and when I came across a pinout for the 6502 I thought "wow this looks like it'd be fun to interface with". So I of course did the logical next steps: Buy a 6502 on eBay, stick it in my desk drawer, work on peripheral devices for a year, order a 65C02 when I find out it's easier to use, and finally design a motherboard after designing every possible other piece; only running the first test programs onto it a couple of weeks ago.

I'm looking forward to writing up some routines for controlling the I/O hardware in the next few weeks, then finally putting some games together on this thing. Eventually I hope to make a more compact version with SMD components that fits into a neat little enclosure that evokes a console of the 8-bit era; and share the designs as open-source including some nice programming documentation.

Thanks for checking out my post! Would love to hear what folks around here think of what I've got so far. Critiques, suggestions, general feedback all welcomed. Reading these boards and the primer have been exceedingly helpful on this journey.

Nice work. Almost looks like a city skyline.

Pedantic note: 2020 is not the start of a new decade, just as 2000 was not the start of the current millenium

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I like it - thanks for sharing!

(BDD, there's a cartoon about that. But this is off-topic.)

A little update on the game system progress:

I ended up getting the pinout for the dual-ported RAM totally messed up, and had to re-order the Video Signal Generator board. Should arrive tomorrow, and hopefully I'll have some images to share.

Other boards had a couple of mistakes but not fatal ones:

• I forgot that the LFSR noise generator on the audio board will remain silent if its shift registers are all zeroes, but swapping the XOR for an XNOR chip should remedy this.
• Leaving my read strobes from the address decoder ungated would have been fine, but I forgot about this and assumed phi-gated select on my joystick board. My joystick reading scheme is to toggle a D-type flip flop on successive reads to the address, and use that as the selection output to the controller. The early select edge resulted in inconsistent controller reading. For now, a small adapter breadboard fixes the problem.

So far on the software side I've improved on my music playback and loading routines by making their target channel numerically selectable via the X register. I've also switched from wait loop timing to using the timer interrupts from the 6522, making the playback more consistent.
Currently, I want to figure out a bug I'm having with the wavetable channel where it fails to reload address counters upon hitting a $FF byte, and then outputs bursts of noise even when my program should have zeroed out the wavetable RAM. Might need to give the soundcard another cleaning, and inspect for more accidental pad-via connections that have been a running theme for this build.

Can't wait to get back to it, end of the work day can't come soon enough!

It's been a little while, huh? I eventually got the video card working... somewhat. I still have a memory access glitch that interferes with CPU access to the lower half of both Video/Framebuffer RAM and Graphic Assets RAM. Though the DMA copy between the two seems to not have any problems. Before today I thought something was off with the timing for direction control on the '640 that I use to separate the main bus and the video bus... but rewiring that pin to R/W didn't help anything. Starting to wonder if the problem isn't actually on the motherboard!

Anyway here's a video demonstrating the progress, including the hardware blitter and an implementation of Conway's Game of Life.
(Also an emulator I'm working on, to speed up development)
https://www.youtube.com/watch?v=VtUykovbR04

Thanks for the video - system looking good. I imagine that memory access thing will prove to be something simple. Good idea to write an emulator for the machine.

Thanks!! This is actually inspiring!!

Great looking system. "Proper" retro too with a raft of TTL!

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Nice system.

@BigEd, I'm glad you posted that relevant XKCD, because I was about to to so.

On my motherboard, I had gating R/W with Phi2 to generate read/write pulses as seen in many example schematics. However, it turned out that there were enough gate delays between Video/Graphic RAM and the CPU that the end of the read/write pulse would arrive after the address lines destabilized. I was able to fix this by tapping into my clock divider for the next highest frequency, gluing another AND gate to the board and reshaping the read/write pulse to go low only during the FIRST half of Phi2 high. I was worried that this might not give enough time for the data lines to stabilize, but from my tests the fix seems to be working.

I had to do a similar thing to fix a bug in the sprite copy, where an additional black pixel would be drawn on the right side of transparent sprites, because the write pulse would begin before the "transparent pixel detector" could inhibit it. So I gated that against the next-higher clock to delay the pulse.

Now that I can properly access the full memory of the graphics module, I wanted to try filling the screen with image data. My current batch of ROM carts only have 8K of memory, while a full 128x128 screen contains 16K of data.
Using the DEFLATE algorithm brought my test file down to 2570 bytes, and with Piotr Fusik's zlib6502 library it takes less than a second to unfurl it all into Graphics RAM.

One part that was a little tricky was linking the library into my existing demo code, since I've been assembling with vasm while zlib6502 uses xasm. I couldn't find much documentation on xasm, but found that it seems to tack a small header onto its output by default. I used a disassembler to find the *real* start of the code and included it as binary data into my demo. This is probably the first time I've manually performed the job of the linker.

Looks very good! zlib6502 is a handy project for sure.

Looks really good. Love the design of the video circuit.

Happy to report that I've got all three expansion cards working at once, and started working on a simple game for the system.
I spent yesterday putting together a video update to share with friends and colleagues, much of it covers stuff I already posted about here, but the gist of it is:

• Simple game with platform jumping physics, music/sound effects, loading more screens when you walk off to the side
• Cut read/write pulses in half to combat skew between writes and address changes
• Pulled out the mixer components and wired them out to a breadboard (for now) because I still can't analog very well
• Oops, that XNOR gate has open-collector outputs. Jammed a resistor in there
• Sound test program to manipulate audio registers
• Using aseprite, HxD, TileKit, zopfli, and JS to create graphics assets. (Then decompressed with zlib6502)
• Platform game accidentally doubles as an awkward memory monitor
• Emulator progressing as well, now has keyboard input and (approximate) soundcard simulation

One thing I didn't mention in the video: Initially when I plugged all three cards in at once, the system wouldn't work properly. With only two cards inserted I noticed that if I poked the D0 line with tweezers, a paperclip, or even the oscilloscope probe the same symptoms would manifest. I soldered on a couple of resistors to pull the line to Vcc/2. For the sake of compactness the next hardware iteration won't be a backplane, but will I still need to add bus termination resistors somewhere?

Wow, I missed a lot being away for a few months.
This is great! Kudos!!

Brad

Been a while since the last update, but I am indeed still working on this.

I'm now working on a second set of boards, eschewing the backplane and the modular select line jumper wires in favor of a system that actually works every time I plug it in.
Well, I guess I should say *mostly* eschewed the backplane since I'm still breaking the system bus out to separate boards. But now it goes to dedicated slots instead of having
a bunch of general purpose surplus bus connectors.

I haven't recreated the soundcard in the version 2 form yet because I'm still deciding how to deal with the digital potentiometers being discontinued.
Starting to think about replacing the whole audio circuit with another 6502 controlling a DAC.

The blitter hardware has a couple of new features: namely the ability to flip the source image as well as toggling whether to wrap around to the other side of the screen when drawing close to the edge.
There are a couple of new bugs, of course. I switched to the 74HC191 for the ability to count in either direction to support the flip function, but it seems that they are a bit finicky in the ripple carry arrangement when loading a value that raises the Carry Out signal of the lower counter.

I've also retconned my cartridge pinout to include a SPI connection. After developing my platform game test into a fully playable (albeit short) game, I kept hitting into the 8KB size limit of my EEPROM chips.
So I'm planning to design a cartridge PCB that includes a serial EEPROM that will hold mostly compressed graphics and music, alongside the parallel EEPROM that will contain code. This also means that I'll need to redesign my cartridge programmer tool.

At this point I have a pretty decent idea at the scale of the final version in its proper game console form factor. It's most likely going to be a stack of four PCBs, each 5x7 inches and about 3 inches high without a cartridge inserted. That'll go into a 3D-printed case, though coming up with specific aesthetics is a task I'll save for later.