PET-GCM

From Forskningsavdelningen Wiki
(Redirected from Rbox game)
Jump to: navigation, search
Design concept
Hardware

PET-Gaming Computer Module. A LED dot-matrix computer panel attachment for the PET-BASE/Reggaebox.

GIT repository[edit]

Portable Entertainment Terminal - Gaming Computer Module

Coverage (videos, pictures, articles)[edit]

Participants[edit]

ADDITIONAL PARTICIPANTS WANTED - SEE PROJECT STATUS.

  • @STG
    • Project coordinator
    • Funding

  • Jenx
    • Repetitive tasks
    • Mini-display

Jenx had to drop out when his kid was born :)

  • Jimbo
    • Learning electronics and programming
    • Mini-display
  • Morpheo
    • Mini-display
  • Olle
  • CareBear
    • FPGA introduction and support
  • JonasB
    • Creator of awesome ideas and applications

Introduction[edit]

The goal is to build and program a game console attachment for the Reggaebox portable music system.

You will see alot of striked out text throughout this documentation and the reason for this is that I leave everything in because I want people too see how the project has evolved and how thoughts, ideas and implementations often change during the development of large projects.

I am hoping that this can serve as an inspiration to people who want to do large projects but don't feel they have the knowledge. As you read this page you will realize that I had far from all the knowledge I needed to finish the project when I started it and alot of the design changes were based on knowledge aquired during the course of the project and oppertunities that have presented themselves while talking to people about the project.

Not having all of the know-how is not a reason to not start working on a project, rather the opposite - it can be the reason and motivation to learn about all of those things you've been putting off!

Planned features:

  • 64x48 pixel color display
  • Integrated display and SID audio controller
  • Exchangeable game cartridges
  • Two game controllers

Changes to original ideas during development:

The Reggaebox attachment idea still stands, but the project has since evolved into much more than just a gaming platform.

  • SID audio was built but never installed, instead a Amiga500 compatible soundcard was implemented.
  • Exchangeable game cartridges were dropped in favor of software on an SD card.
  • An IrDa port was implemented to allow for remote control applications.
  • Ethernet port was added to allow network conectivity.
  • MIDI was added to allow the platform to be used as a visualizing synth.
  • The original idea was to use a µC only, the addition of an FPGA was a later choice.

Project status and updates[edit]

  • [10-09-17] Laser cut the front panel for the I/O board.
  • [10-09-03] Played PONG with Limpkin's panel over the internet
  • [10-08-24] Hack-a-day posted an article about the project
  • [10-08-24] Interlude

Today we had the most awesome meetup at the space. While I was coding something as trivial as Pong, JonasB wrote an Android-app that connects to the panel using WiFi, accessing the camera and streaming live video directly from his cell-phone (see video), resulting in standing ovations. Damn good work man! Also my car wouldn't start - CareBear to the rescue!

  • [10-08-20] Video of streaming app. is up
  • [10-08-19] AviSynth plugin to transmit video over UDP completed @GitHub
  • [10-08-17] Gamepad controller completed
  • [10-08-16] Gamepad controller chassis completed
  • [10-08-12] All gamepad controller parts aquired
  • [10-08-06] Interlude

Very little work done on the hardware this month, because the project has reached a stage where I can actually start to play around with it, which is exactly what I've been doing. An operating system has been written, drivers and libraries are also starting to take shape. The application framework has been used to build a ProTracker MOD player and a MIDI synth that sounds like an Amiga! We've also been able to display video on the display sent by a neat little Ruby script that Olle and jonasb put together. As for hardware I've been tinkering on the first real gamepad (i'm currently using a prototype) and thinking about what to use for a second controller. Ideas are in the works on several games and controllers, which will require some slight changes to the hardware.

  • [10-07-12] UDP network communications operational
  • [10-07-11] "Hello World!" app. launched from SD-card using application browser
  • [10-07-10] Replaced DC-filter module with superior design
  • [10-07-09] Implemented basic "OS" with graphical application browser
  • [10-07-08] Audio-filter module completed and fitted
  • [10-07-07] DC-filter module completed and fitted
  • [10-07-06] FAT16/32 driver from robs projects implemented and working
  • [10-07-05] SD communications working
  • [10-07-04] MIDI in and SD/MMC connected
  • [10-07-03] Power filter completed
  • [10-07-01] Enclosure sides constructed
  • [10-06-30] I/O board finished and mounted
  • [10-06-24] I/O board schematic and PCB available
  • [10-06-24] Coverage links added
  • [10-06-21] Signal integrity problems solved
  • [10-06-19] DEMO on display at Hacknight II
  • [10-06-16] Simple DEMO code for Hacknight #2 completed
  • [10-06-15] Display is operational, with minor signal integrity problems
  • [10-06-14] PCM synth sound samples availble (sound controller section)
  • [10-06-10] Amiga MOD (ProTracker) player completed
  • [10-06-09] FPGA PCM synthesizer verified
  • [10-06-09] FPGA PWM audio filters prototype constructed
  • [10-06-08] Mainboard connection to FPGA verified
  • [10-06-08] Mainboard (CPU, RAM, Flash, Oscillator) completed
  • [10-06-05] FPGA connection to row driver verified
  • [10-06-04] FPGA PCM synthesizer completed
  • [10-06-01] PSU & row driver completed
  • [10-05-28] PSU & row driver PCB layout and schematic available
  • [10-05-27] PSU & row driver PCB completed
  • [10-05-23] Display matrix completed
  • [10-05-23] Matrix drivers row connections done, 384x
  • [10-05-20] Column data buffers done, 8x
  • [10-05-17] Matrix drivers column connections done, 288x
  • [10-05-17] FPGA board modified to function with the USB-blaster
  • [10-05-10] Cyclone II FPGA board arrived
  • [10-05-09] Electronics for row switching ordered, 8x
  • [10-05-04] 5V 25A regulator ordered
  • [10-05-02] Display segments tested, 48x
  • [10-05-01] Display and fixture assembled
  • [10-04-30] MDF display fixture completed
  • [10-04-29] Display driver VHDL code finished and successfully simulated
  • [10-04-26] Altera Cyclone II minimal FPGA piggy-back board ordered
  • [10-04-18] Failed attempt to cut baquelite display fixture
  • [10-03-26] All matrix boards completed
  • [10-03-19] Reflow Oven arrived
  • [10-03-18] Goodie bags prepared for mini-display participants
  • [10-03-17] Display segments arrived, 52x
  • [10-03-12] T-962 IR Reflow Oven ordered
  • [10-03-12] Display segments ordered, 52x
  • [10-03-10] Matrix driver IC samples arrived, 10x (64x total)
  • [10-03-09] Matrix PCBs shipment arrived
  • [10-03-06] Acid interface tested and fully working
  • [10-03-04] Acid interface completed
  • [10-03-03] SPI_SID schematic replaced by AS_SID [Acid] schematic
  • [10-03-02] An evening of fail...
  • [10-03-01] SPI_SID schematic available
  • [10-03-01] Matrix PCBs delivery confirmed to ship 10-03-09
  • [10-02-28] Streamlined Network Stack for mainboard completed
  • [10-02-25] Matrix PCBs ordered
  • [10-02-24] Prototype controller/mini-display schematic updated
  • [10-02-23] Fully functional prototype, PCB design verified
  • [10-02-19] Prototype controller/mini-display completed
  • [10-02-18] Prototype controller/mini-display schematic available
  • [10-02-17] Matrix ICs arrived, 54x
  • [10-02-15] Matrix ICs ordered, 48x needed + 6x spares = 54x
  • [10-02-09] First matrix proto-PCBs fitted with display connectors, 2x
  • [10-01-30] First matrix proto-PCBs manufactured, 6x
  • [10-01-27] Matrix IC samples ordered, 10x
  • [10-01-25] Matrix driver schematic and PCB available

We are looking for people interested in joining the project! If you have any good ideas, suggestions or just want to help out and learn, let us know! There are still alot of things that need to be thought out and tested such as:

  • Choice of µC
  • Cartridge and cartridge port design
  • Game protocol
  • Music visualization
  • SID-chip implementation
  • Controller design
  • Game ideas
  • Emulator implementation
  • More...?

There are also several side-projects or spinoffs that you might be interested in, see the project layout section below for more information!

Links and acknowledgements[edit]

David Cuartielles

David provided me with access to, and tought me to use, the laser cutter used to cut the fixture and i/o board cover panel. All in all a great guy! Visit his websites:

Limpkin

I've been working together with Limpkin in Austria to develop a network gaming setup between this panel and his 96x64 pixel reg/green FPSLIC-controlled AVR LED panel. His panel does not have ethernet so the system consists of the Server, running on my panel and a PC-application running as the Client on his side - communicating game parameters over a serial connection to his AVR controller. Check out his blog - it's a nice read!

Kepyla

Kepyla helped me understand the operation of MOSFETs, and to verify my selection of these.

Lessons learned[edit]

No project is complete unless you've learnt something along the way. During this project I've been forced to aquire alot of new knowledge:

  • Designing for price efficiency
  • Designing for power efficiency
  • Component sourcing
  • PCB production options and worldwide pricing differences
  • How to design and verify PCBs for professional manufacturing
  • Practical insight into manual PCB production using different methods
  • SMT soldering by hand
  • SMT soldering using reflow oven
  • Laser cutting using laser engraver, possibilities and problems
  • Switched regulators, availability and functionality
  • FPGAs, avilability and functionality
  • Programming FPGAs using VHDL
  • Understanding MOSFET operation and datasheet specifications
  • How to use MOSFETs to efficiently switch large currents
  • Insight into signal integrity problems
  • MIDI hardware and protocol
  • How to implement an SD/MMC card
  • How to work with FAT filesystems

Project layout[edit]

8x8 display segment, 32pin

The project consists of these parts:

  • CONTINUOUS: Brainstorming, game prototyping
  • COMPLETED: Sound card (SID chip µC interface)
  • COMPLETED: Prototyping (display segment drivers)
  • COMPLETED: Display (assembly and lots of testing and soldering)
  • COMPLETED: Controller interface (Quadrature decoder in FPGA)
  • COMPLETED: Row driver (MOSFET array)
  • COMPLETED: Graphics controller (FPGA using integrated block-RAM)
  • COMPLETED: Amiga-style PCM-synthesizer (FPGA using onboard RAM)
  • COMPLETED: Main board
  • COMPLETED: Hardware debugging
  • COMPLETED: I/O board (cartridge, audio, midi, game ports)
  • COMPLETED: I/O board modules (DC Filter, Filter, DAC)
  • CURRENT: Controllers (pulsgivare/rotationssensor, 2 knappar)
  • CURRENT: Enclosure (trä/plast/metall, plexiglas)
  • FUTURE: ADC module

Mini display spinoff[edit]

Mini-display concept animation, hopefully this will give you a good enough idea

The prototype boards will not be part of the finished project - but they can be hacked into mini-displays for stand-alone applications, such as a desktop clock (see concept animation, right), a peripheral display for your PC or --insert your idea here--. The PCBs can be had for free, but you'll have to add a display matrix, a driver circuit, matrix drivers and a µC. Total cost would be roughly 150-200 SEK unless components can be scavenged - a good deal, given that these modules (display only, no controller or electronics) usually sell for around 300SEK.

I've ordered several spares for the drivers, but you should let us know if you're interested before it is time to order the displays - these are too expensive to order spares and they will cost you a bit less if we order them together, since I'll be ordering at least 48 of them.

Displays have been ordered (at discounted price) for the following participants - projects:

  • Jenx - desktop clock Dropped out, this kit is available
  • Morpheo - animated bicycle lamp
  • Olle - test results indicator
  • Jimbo - something awesome

Costs as follows:

  • Discounted display: 85 SEK
  • Matrix driver: 25 SEK
  • Resistors and capacitors: 10 SEK
  • PCB: 15 SEK
  • Grand total: 100 SEK (either i'm being nice, or i suck at math)

Discounted displays include headers for mounting. Regular price is 119 SEK without headers.

The sample/prototype display is now also available, complete with a PIC controller for anyone interested in buying it for private use or just playing around with it at the research department. Requires 3.3-5V input for operation and an PIC ICSP-capable low-range programmer for development. Programmers may be borrowed on tuesdays from Jimbo and STG.

Additional modules can be ordered from swechtrading - there are still a few drivers and PCBs available!

Game programming spinoff[edit]

Interested in game programming for the system? The full game cartridge pinout and protocol will be available in the cartridge specification section once it is finished! There will hopefully be an emulator available for download, so that games can be easily tested on a PC. Games need to be written for the eZ80F91 in the Zilog ZDS II Development Studio using eZ80 assembly or ANSI C. My hope is that this project will spurr people to try their hand at microprocessor programming and I will be available each Tuesday to help you get started, or if you get stuck.

Hardware SID player spinoff[edit]

Now has it's own article - SIDblaster

Research[edit]

The display will be based around a load of 8x8 RGB LED dot-matrix modules that I've come across cheap at swechtrading. The most common method of driving an 8x8 LED matrix is to use three shift registers with latched outputs, hooking up each output to one row pin (8 rows x 3 colors = 24 pins) via a resistor. This however proved economically infeasable when constructing 48 such drivers. After several days of researching I found that the cheapest candidate is a 48pin TQFP driver from ST called STP24DP05BTR. This component is cheap, and requires only 5 external components - compared with the 26+ required when using a conventional driver setup. In addition, this component also has a higher power efficiency, which translates directly to longer battery life.

Cartridge specification[edit]

Cartridges may be built using any 3.3V microprocessor. This way each game programmer can use whatever system they are most familiar with and the choice of CPU can be adapted to the complexity requirements of each game. Game dynamics will run on the cartridge CPU, while graphics and sound rendering will be handled by the host system. The cartridges will communicate with the host system using some form of serial protocol. The connector and pinout has not yet been defined.

The most current draft of the serial protocol is available here:

Protocol definition

The original idea of using a serial protocol has been dropped in favour of binary executables on an SD/MMC card.

Schematics[edit]

Matrix driver[edit]

This is the matrix driver schematic, I need to build 48 of these to fit onto each display.

Segment driver schematic

Only one or two of the capacitors will be mounted, all three are included in the schematic for PCB-conformity since the PCB actually has three capacitor mounts. The reason is that I want to be able to experiment with different decoupling solutions. Controller connections (nets A1-A8) are ommited from the schematic. These will be hooked up to an external board using the 8-shaped connectors at the top corners of the PCB-layout.

Mini-display[edit]

This is a prototype (small-scale) controller for a single display and control logic for testing. This will drive a single display module and can as such be used directly to build the mini-displays.

Mini-display schematic

The PIEZO element will not be mounted unless you want the design to be able to emit sound. The VPP pin can be hooked up to a resistor & button array if user input is required.

AS_SID interface[edit]

This is the AS_SID [Acid] interface that will allow the 5V TTL SID bus to be interfaced with the 3.3V µC using either an I2C or UART interface.

SPI to SID schematic

This design replaces the original SPI schematic and is designed to allow for some degree of experimentation since I'm not entirely sure what the best communications strategy is at this time. The µC can be interfaced using either I2C or UART, and the CLK line can be driven either by software or the dedicated PWM module, whichever turns out to work best.

PSU & row driver[edit]

PSU & row driver schematic

This card will convert battery voltage to +5V power for the display and has linear regulators for 3.3V and 1.2V. It also contains the MOSFET drivers for the row groups. Finally it acts as an adapter for the data interface towards the data bus.

I/O board[edit]

I/O board schematic

This card hosts all of the necessary connectors, midi opto-coupler and buffers for the game controllers. It is a modular design because I wanted the option of replacing some of the function with better designed hardware in the future. It also reduces the risk of errors on the board due to a minimum of components. Because of this the board has module connectors instead of the actual componenents for the following functions:

  • The DC filter - because I'm unsure how much filtering I will actually need.
  • The ADC (Analog to Digital Converter) because I want to save this option for another time.
  • The Filter/DAC (Digital to Analog Converter) because I want to replace this with a better design in the future.

Note: This board was revised manually several times after it was constructed. This schematic does not reflect all of those changes.

After a week of fashion shows at Mercedes-Benz Fashion Week, there are few trends that stand out, among them: pale tones and sexy Christian Louboutin Shoes. These open-toed booties from Nicole Miller's Spring 2011 collection are a good example of spring's pale palette. After four seasons of subdued shopping by luxury buyers, looks for spring were dominated by white, nude and other neutral colors, which gave the clothes on the runway a softer, lighter look. It was a real shift from recent shows, where designers had picked darker colors that seemed to reflect the gloomy mood of the economy. This trend even extended to the fingertips with a peachy-nude-putty-colored nail polish worn by models in the Marc Jacob show and a manicure of beige polish, with a thin coral arc applied by celebrity manicurist Jin Soon Choi at Prabal Gurung's runway show. Overall, many of the looks for spring were uncomplicated and versatile, which should help these clothes make the transition from the runway to the stores as retail buyers remain selective in their purchases. What was wild? The Christian Louboutin Shoes-both on and off the runway. (You have to see for yourself. Look at our slideshow.) It stands to reason. Consumers can only shop their closets for so long. Eventually, they have to start buying again, but they will look for pieces that will work with what they already own (hence the neutrals) and that will make a fresh new statement (cue the shoes.) Find big Christian Louboutin sale at www.uChristianLouboutin.com

PCB design[edit]

Matrix driver[edit]

Next up, I designed a PCB for the matrix driver:

Top layer Bottom layer

Due to the small size (the card is only 50mm high) I had to use a two-layer design. This, in conjunction with the fact that the TQFP pad has 0.25mm pins with a 0.5mm pitch means that prototyping will be difficult, to say the least! Once the PCB has been verified though, the boards will be "professionally" manufactured by pcbcart. When ordering 50+ boards it is actually cheaper to have the cards manufactured than to etch them yourself.

PSU & row driver[edit]

For the PSU & row driver I opted for a single sided board with silkscreen:

Bottom layer and silkscreen

The silkscreen was added using ordinary toner transfer and as such is not very heat resistant. But it looks nice :)

I/O board[edit]

I/O board bottom layer, top plane and silkscreen

I used a ground plane for better noise immunity due to the noise sensitive DAC and ADC components. Note: I was unable to mount this card so that the ground plane faces the panel, where most noise emissions are generated. This was a bad design choice on my part, causing the plane to lose some of it's efficiency.

Note: This board was revised manually several times after it was constructed. This layout does not reflect all of those changes.</b>

Prototyping[edit]

Etched boards, top and bottom layer

PCB manufacturing[edit]

For prototyping we used the toner transfer method.
If all goes well we'll have at least 6 prototype boards to play with.

For more details regarding the manufacture processes, see the pcb manufacturing article.

The First batch of prototype cards, produced using the toner transfer method, are pictured on the right.

Microscope closeups of these particular boards are available at the manufacturing link above.
Microscope inspection

Cut and inspect[edit]

The cards were cut to size using a regular guillotine-style paper cutter.
This works well for thin plastic boards, but is not recommended for thick (1mm+) glass fibre laminates.
Once the cards were cut to size, they were carefully inspected using a microscope.
When dealing with 0.25mm traces, breaks and shorts are too small to detect without magnification.

Vias

PCB finalization[edit]

Each card was then repaired simply by adding a gentle amount of solder across any breaks.
The connections between the two layers are called vias, and were drilled to 0.3mm.
Through-hole mounts were drilled to 0.8mm.
This can be done by hand, but it helps alot to have a pillar drill suitable for small scale applications.

To finish the vias, 0.2mm copper wires were inserted through the holes and soldered at each side.
The picture on the right is a microscope image of the finished vias. The traces in the picture are 0.5mm wide.

Display segment mounted on board

Display attachment[edit]

In order to be able to easily attach and detach the display, headers were added to the board.
This is single display segment mounted onto a prototype driver board using these headers.

STP24DP05BTR next to match head

Matrix IC arrival[edit]

The STP24DP05BTR drivers have arrived, and they are tiny...
To give you a good idea of the size of these things, I took this size comparison shot of a chip next to a regular match.
Now I just need to figure out a way solder these chips manually since I do not have access to a reflow oven.

STP24DP05BTR mounted on PCB

SMT soldering[edit]

Searching the interwebs gave us alot of ideas on how to solder small scale SMT (surface mount) components. Most commonly a reflow oven is recommended, but there are several other methods. The military teaches a method where you add a generous amount of flux to a row of legs, then adding an adequate supply of solder to the tip of the iron and quickly dragging it across the row. Apparantly this attaches just the right amount of solder to each leg, without bridging them. Naturally you could also simply solder each leg individually using a good quality smt soldering tip, but this is time consuming and requires a stable hand.

The method I chose to try was to add a generous line of regular solder across a row of legs, not minding that several of the legs become bridged. You then simply use a good quality solder wick to remove superfluous solder, removing the bridges. This worked very well, and it was an immediate success at the first try.

Late night forsken session
Prototype row driver

Row driver[edit]

After a late friday session at forsken the prototype row driver is finished. I did not bother making PCBs for this, insted I built the driver on an experiment board. This is usually alot quicker when dealing with simple boards that do not require SMT components.

As you can see, there are three potentiometers on the board that is not in the schematic. These will be used for experimenting with the resistances used to control the current to each set of LED colors. When I've found the correct values and achieved white balance, they will be replaced by SMT resistors on the matrix driver.

Check out the bambuser broadcast of the prototype running a text scrolling application. Quality is awful, but it still shows the display in working order.

Static graphic test

White balance calibration[edit]

It's been determined that adequate white balance and brightness is acheived using the following resistor values:

  • Red channel: 1k6 = ~11mA @5V
  • Green channel: 1k5 = ~12mA @5V
  • Blue channel: 3k9 = ~5mA @5V

The currents are taken from the resistance vs. current graph in the STP24DP05BTR datasheet, but I must admit that the display seems awfully bright for such low currents and I haven't actually measured the true currents so they may be wrong. However, the values do correspond well with my previous experience regarding white balancing of RGB LEDs.

If the values are correct means that I should be able to double (or more) the lumen output. I won't do that though, since I also need to consider the power requirements of the completed display. Using these values the display would draw 48*8*28mA = ~11A @5V = ~55W if all pixels are set to white. And thats in a perfect world! Efficiency will not be anywhere near 100%... The switching regulator I'm using in the reggaebox can only supply 6A @5V which means that at any given point a maximum of 50% of the pixels can be white or the system will simply fail and reboot. The switching regulator has been replaced with one capable of delivering 25A. Current hardware is fully capable of displaying an all white screen for extended periods. That's one big flashlight.

I am guessing that an average game will use roughly 10% of the pixels at any given time which means that the display will draw somewhere in the order of 1A @5V. The switched DC-DC regulator I will be using has an ~70% efficiency at this current which means that the system should normally stay below 1A current draw from the 12V battery. The battery we are currently using is rated at ~60Ah. So with music at full volume and games constantly running we should get at least 24 hours of portable entertainment!

System boards[edit]

Microcontroller[edit]

System board µC module

The choice of µC is still open, but currently I am leaning strongly towards the Propeller due to it's low price, DIL form factor and ability to perform parallel processing (it has eight cores). Parallel processing is a good choice since the finished system will need to perform several tasks concurrently:

  • Serial game cartridge communication
  • Reading and processing input device data
  • Graphics rendering
  • Display management requires roughly 7Mb of data to be clocked out each second
  • Music and SFX management and playback
  • Processing FFT transforms for audio visualization

Ahoy matey's - I've struck gold, arrrrrrrr! Strike the propeller idea. At work, we use the Zilog eZ80F91 µC in our products and you can't really get the programmer for these devices without purchasing an entire development kit. Since these programmers are prone to ESD damage we've bought a number of these development kits throughout the years. The kits come with a large experimentation board that serves as the evaluation playground. The actual µC though, is housed on a much smaller board that attaches using two 2x40 headers.

This board turns out to be completely self sustained and requires only 3.3V to run. It is equipped with the following:

  • 50MHz clock - nearly 50MIPS using a pipelined instruction architecture
  • 256Kb internal Flash memory
  • 1Mb external Flash memory
  • 16Kb internal SRAM
  • 512Kb external high-speed RAM
  • RTC (Real Time Clock) with battery backup
  • IrDA tranciever
  • SPI and I2C controllers
  • 2x UART with 16byte FIFO

The board cannot be programmed on it's own, but I've designed a basic network stack that allows programming of the external flash using a proprietary UDP protocol. There is no need to use a dedicated programmer, except when you need debugging capabilities.

This card has everything I need for this project without any bloat except perhaps the IrDA. It's also comparable to the Propeller in regards to speed - the propeller runs at 12MHz, but all instructions take 4 cycles or more meaning that it can process a maximum of 3Mips * 8 cores = 24Mips, while the eZ80F91 should be able to do at least 25Mips. I also happen to be intimately familiar with this µC so getting it up and running will be quick and painless.

On a side note, the eZ80 (The core CPU in the eZ80F91 µC) is based on the Z80 which was the main processor in the ABC80, the ZX Spectrum, the Sega Master System and the Nintendo Game Boy to mention just a few! Quite the suitable ancestral lineage for a project such as this.

Graphics controller[edit]

I eventually realized that to be able to anything other than turn pixels on or off (3-bit color, producing only primaries black, red, green, blue, yellow, magenta, cyan and white) while also running game software I would need something a bit more powerful than the eZ80... so I've ordered a Cyclone II FPGA piggy-back board that is up to the task, and then some! I've written, compiled and successfully simulated VHDL code that:

  • Interfaces with the eZ80 bus
  • Acts as a RAM memory with 2 wait states @50MHz
  • Addresses two distinct memory pages, selectable using the page input
  • Directs memory I/O to the inactive page, while displaying the active (double buffering)
  • Drives the display with ~7MB/second PWM data
  • Uses 8 parallel data channels towards the display, one for each column
  • Supports 18bit color (6 bits/channel) producing a total of 262.144 colours

Since I do not have a source code management system, the VHDL code is available upon request.

However, current code only takes up a small portion of the resources available in the Cyclone I , and this opens up some interesting possibilities that could really change how the rest of this project plays out... The FPGA could fit an entire softcore CPU as well as the interfaces towards the game cartridge, controllers and sound card which means that the entire system could theoretically be housed on this one single board, eliminating the need for the eZ80 board I initially planned on using. Extending this thought further I might even be able to create a SID compatible implementation directly in hardware, eliminating the need for any external cards whatsoever. Removing the SID would hurt though, but it's just a thought ;)

Upon arrival we quickly discovered that our Altera USB-Blaster Rev.B does not play nice with the JTAG interface on these boards. With some help from CareBear and checking schematics for solutions with similar interfaces we eventually found that simply lifting the pull-down resistor on the TCLK-line solved the problem. The boards are now good to go!

Audio controller[edit]

Audio testing setup (from left): PSU, FPGA with prototype audio filters, µC running ProTracker MOD player

The sound controller will be a two stage retro rocket, where the primary stage is a VHDL implementation of an Amiga 500 compatible sound card running on the FPGA. To complete the setup a C64 SID will be used as a secondary synthesizer. Edit: There will be no SID, sorry :) The SID soundcard is up for grabs though!

The primary sound card consists of eight DMA channels with single shot, looping and ping-pong capabilities. The last four channels are used to modulate the volume of the first four channels to construct complex waveforms. Two of the resulting compositions are mapped to the left channel and the other two to the right - just like on the Amiga ;)

I've also taken the time to write a full ProTracker MOD player in C for the eZ89F91 µC. Source code is available. This is what it sounds like:

The Acid-interface, a serial SID soundcard
Verifying bus timing using a logic probe

THE FOLLOWING TEXT IS JUST FOR HISTORICAL REFERENCE, THERE WILL BE NO SID CHIP IN THE SYSTEM! THIS PIECE OF HARDWARE IS UP FOR GRABS!

As for the secondary SID sound card... The eZ80F91 is a 3.3V µC, while the SID is only 5V compliant. Even though the µC has 5V tolerant inputs, other circuits connected on the bus do not. Interfacing them directly is not an option, and there are few acceptable level translators readily available. The SID does accept 3.3V as a logic 1, which means that if I never read data from the SID everything should work fine, since the bus will never be driven to 5V by the SID...

... however, after some research it turns out that this is not the only problem. The SID needs to be clocked at roughly 1MHz, and while a 1MHz signal could easily be generated by the host µC, the problem is that all bus transfers need to be synchronized to this clock and there is no way this can be done using the eZ80, except making heavy use of timer interrupts or wait loops. Loops would be much too time consuming when I need to pump as much data to the display as in this case. Interrupts are not an option since the display needs to be fed with a constant data rate, or I will see jitter in the PWM signals causing pixels to flicker.

The eZ80F91 does however have both I2C and UART hardware. The I2C hardware is rather basic, does not have buffers and does not support automated transfers, thus requiring a state machine to go through several states of processing and error management for each byte to be sent - but it is the faster alternative in regards to data transfer speeds. The UART hardware on the other hand is a bit slower, but has a 16byte FIFO and supports fully automated data transfers which means that the software can be kept fast and simple, with perfectly reliable timing conditions.

Regarding voltage level compatibiliy - anything above 2.0V on the PIC16F884 will be regarded as a logic 1. Using I2C, voltages will stay within the tolerable 3.3V range since it is open-collector. The UART of the PIC16F884 will drive the TX pin with 5.0V logic levels, but as previously mentioned the eZ80F91 is 5V tolerant so neither solution should require voltage level translation.

Currently I have firmware for the PIC16F886 that will allow the SID to be driven at 500kHz (1MHz is recommended) when clocked at 20MHz by an external source. This software uses I2C communications and is capable of receiving a constant I2C data stream at a maximum of roughly 900kbps, which translates to 50000 SID register r/w's per second.

The next step is to develop a firmware that will use UART communication and hopefully reach the 1mHz target clock frequency using the integrated PWM module, while synhronizing at least 10000 SID register r/w's per second to this clock. If all goes well, this circuit should be very close to what the original C64 was capable of.

Dubbed AS_SID [p??'na?nsd: acid], the hardware and software for my Asynchronous Serial SID Interface Device is now completed. The interface is capable of receiving asynchronous serial data at a rate of up to 1mbps when clocked at 16 MHz, while clocking the SID at exactly 1 MHz. It is capable of 50.000 r/w's per second with a minimum of 10µS between operations.

Note: I settled on using the PIC internal clock, communicating at 500kbps = 25.000 writes per second. Due to the timing constraints when running at 8MHz this firmware cannot reliably read SID registers, but I have no need for this.

PSU & row driver[edit]

PSU PCB with silkscreen

Power will be generated using an Ericsson 118L DC-DC regulator capable of outputting up to 25A at 5V with an efficiency of up to 90%. Other voltage levels will be generated using linear regulation based on the 5V supply. The CPU and FPGA boards have suitable regulators already mounted. Display module anodes and the ASSID module will be fed directly from the 5V supply. I estimate that the system will require a maximum of roughly 15-18A from the 5V supply when everything is running and all LEDs are powered. The system requires ~12.5 A at full capacity.

After reading the MOSFET chapter in "The Art of Electronics" and getting a quick primer from Kepyla and Jonas@swech-trading I decided to use the IRF3706, which is capable of switching the nearly 15 amps of power required to drive the display. Each driver will only work on a 1/8 duty cycle so hopefully they will not require any cooling. Each driver will dissapate roughly 400mW of power. These drivers have very low Rds and have very quick switching times. The low Rds will ensure minimal power-loss and the low switching time will ultimately increase the overall brightness of the display as well as simplifying the FPGA code.

I/O board[edit]

I/O panel connectors

To be able to interact with the system in any way (except using a programmer) we need to be able to hook up input and output devices to it. The I/O board will facilitate this need by featuring the following connections:

  • Ethernet port (mostly because the µC has an ethernet controller).
  • SD/MMC card reader to be used for loading programs and games.
  • MIDI in, allowing the system to become a synthesizer.
  • 2x game controller ports.
  • Audio input for visualizations
  • Audio output.
  • 12V battery power.

The board will also host the DAC, ADC, buffers between the FPGA and game controllers as well as an optocoupler for midi in. The ADC and DAC are both sensitive to noise in the power supply, so this board will also need to filter the +5V and +3.3V DC supplies. Because of the many functions of this board I chose to design it in a modular fashion with the host board containing only a minimum of components while providing headers to connect the remaining functionality. This also allows me to focus on one part at a time with the option of easily upgrading the hardware at a later time. For example, the audio filter will at first be a simple 1-pole low-pass filter initially but the module header also has data connections so that a programmable filter may be added in the future. The two other modules are the DC-filter and the ADC (Analog to Digital Converter) to be used for sampling the audio in port to do visualizations.

SD/MMC card reader[edit]

The I/O board features an SD/MMC card reader that is to be used for games and programs. SD and MMC cards have a physically compatible layout. They both have their own native protocols that support faster rates of data transfer through the use of multiple data pins, but these specifications are not fully open. However they both also support SPI (Serial Peripheral Interface) which is a common interface supported by many µCs, including our eZ80F91. The SD card has 9 pins and the MMC 7, but they have been placed so that the pins needed for SPI (SDO, SDI, CLK, CS) match up. There are differences between the cards in regards to the protocol, but they are similar. I expect that I will be able to support the SD, SDHC and MMC, if the need arises. For now, I will support only standard version 1.0 SD cards.

First of all, the reader pinout was hooked up the corresponding SPI data pins on the µC. Pull-up resistors on the data lines are important for proper operation. The µC (host) needs to be configured with SPI mode 0 (CPOL 0, CPHA 0). All commands towards the SD card are 5 bytes long:

  • Command index (or'ed with 0x40 / bit 6)
  • Four parameter bytes (pad shorter parameters with zeroes)
  • CRC (is not necessary in SPI mode and should be hardcoded to 0x95)

Each command has an associated response type (R1, R1b, R2, R3... etc). The first byte of responses R2 or higher match the R1 status response. To receive a response the host polls the card by sending a string of 0xFF (no operation/idle) until bit 7 of the response is 0. The remaining bits then contain the cards status/error bits.

The initialization procedure is as follows:

  • Set SPI rate to 100-400kHz
  • Assert CS
  • Send 100 0xFF (used as delay
  • Deassert CS
  • Send CMD0 - leave SD-mode, enter SPI-mode
  • Send CMD58 - read OCR (operating conditions) so that supported voltages can be verified
  • Send ACMD41 (CMD55 followed by a CMD41) repeatedly until idle bit goes low - initializes card
  • Card is now initialized, but reading the CCS is done at this point to find additional information
  • Identify file system and begin file operations (using block read/write commands)

The dot-matrix display[edit]

Hand soldered SMT PCBs

The matrix PCBs have arrived, so now I have all of the components required to construct the display. I decided to purchase a reflow oven to help with the soldering process, but it can be done manually as well. The cards pictured on the right were soldered by hand, using a thin 0.25mm solder and lots and lots of flux! The rest of the cards will be produced in the reflow oven as soon as it arrives.

If you have any surface mount components you need soldered, the oven will be available at the research department upon request, please ask in the irc channel a few days in advance. The oven can also be used to quickly desolder large quantities of components if that's your cup of tea. Maximum PCB size 180x233mm.

All of the display segments

The display segments have arrived. I now have 48 display segments each containing 192 LEDs arranged as 8x8 RGB pixels. Each display segment will need to be connected to a matrix driver, and all of the matrix drivers will need to be chained together once mounted. The first step is to construct a fixture for the display segments so that they can be easily handled while testing and connecting the matrix drivers.

Using electrolysis to etch a solder paste stencil
Finished solder paste stencil

Solder paste mask[edit]

While waiting for the reflow oven I decided to try to make solder stencils. The original idea was to manually deposit solder paste, but a good solder paste stencil should make the work alot easier. Turns out it's not that easy to find copper or brass sheets with a thickness of between 0.1 and 0.2 millimeters. Eventually though, I managed to obtain a free sample from a pcb manufacturer nearby.

The idea was to do a toner transfer and etch the brass as you would a regular PCB. I thought this would work since brass is mostly copper, but it turns out that the etchant (sodium persulfate) isn't very agressive towards brass at all. After over an hour in a saturated etchant solution (400% recommended concentration) at near boiling temperature it had barely made a dent.

After giving up on regular etching I decided to try and get some electrolysis going instead. This turned out to work remarkably well when simply using a weaker etchant solution as a medium for the electrolysis. Matter is removed from the positive electrode (in this case the stencil-to-be) and deposited on the negative electrode of the same material. The first time I did not limit the current, causing the toner layer to immediately dislodge, ruining the stencil. On the second try, current was limited to a maximum of 300mA. The process took roughly 5 minutes to eat through the 0.13mm sheet and it actually turned out pretty decent. Some adjustments the original and the toner transfer will be necessary to to obtain a good quality stencil, but this one might just get the job done. Edit: it didn't, but due to other problems, see below.

T-962 IR reflow oven from Puhuit
Baking cakes
48 display modules and 54 driver boards

PCB production[edit]

Once the reflow oven arrived I immediately began trying different methods to see what works and what does not. It seems quite easy to succeed with 0.5mm pitch components, but the 0.25mm drivers on these boards were not as easy... Since the PCBs have been treated with HASL (Hot Air Surface Leveling, a solderability preservation method that results in a thin layer of tin on all pads) the solder mask could not get close enough to the PCB, resulting in too much solder paste being deposited. I tried several different mixtures of paste to reduce the amount of tin per volume, and as a last resort - manually depositing paste. Nothing seemed to work very well. The resulting cards all had a large number legs bridged and it was extremely time consuming to probe and fix the cards.

After experimenting for a while though I found a method that works 100% and is quick. Capacitor, resistor and thermal pads are prepared by manually depositing solder paste, while a thicker layer of tin is deposited on the fine pitch pads by adding a small amount of regular solder to the tip of the soldering iron tip and quickly sliding it across a row of pads that have been generously fluxed. The pads are then cleaned and refluxed so that the driver IC will adhere to the pads. Using this method I should be able to solder all cards in a matter of hours, with no bridging - eliminating the need to probe each card.

Data connections[edit]

288 cuts, 576 wire strips and 528 solder points later...

Once the display fixture was in place it was time to start soldering drivers together into eight chains of six drivers each. Each driver is hooked up to the next one using six wires, GND, VCC, OE, CLK, SDA and LE. While soldering a wire isn't very time consuming - cutting, stripping and soldering a large number of wires sure is! But after half of an eternity (half only because alot of nice people helped out with the wire cutting and stripping) all vertical connections are finally in place.

The next step was to construct individual data drivers for each column of matrix drivers. These are needed because CLK, LE and OE are common for all 48 displays, but one output on the FPGA will not be capable of driving that many inputs. Each of the eight columns is buffered through a schmitt-triggered hex inverter (74AC14, AC = low-voltage, high-speed) at the top of each column. I will not bother making a schematic for this driver since it does not contain anything besides this chip and a header for connecting to the data bus.

Power connections[edit]

Another 384 wires, strips and solder points and the display is finally finished!

Once these were in place, I began soldering the horizontal connections that will deliver power to the LEDs, while at the same time testing the displays one by one so that I did not end up with a finished display where nothing works because just one driver has a problem.

During testing I came across a variety of problems:

  • Initially the test device was hooked up incorrectly causing it to work only when people were close enough to it ~20cm... magic :p
  • One of the data drivers had a malplaced bridge causing it to behave sporadically.
  • Three matrix drivers had their driver chips soldered on 90* rotated and had to be replaced.
  • Two display module had had a leg bent when the driver was mounted.
  • One of the matrix driver PCBs had two vias bridged from manufacturing causing odd behaviour.
  • Two matrix drivers had tombstoned resistors causing the blue channel to be very faint.

All problems have now been fixed and the display is now fully operational, but there is nothing to drive it at this time, so I'll need to construct the MOSFET drivers that will power each group of rows with up to 15A at 5V.

Construction[edit]

Fixture[edit]

Plexiglas and MDF fixture

To hold all of the segments together into a single large display I need some kind of fixture.

The idea is to fix the panels between a plexiglass sheet and a plate with holes for the pinouts on the segments and capacitor on the pcb. Because of the large number of holes required it would be very difficult to make this piece manually, so I worked with 1scale1 to produce it using their laser engraver. Initially I wanted to use baquelite, because it has a retro feel to it that goes well with the theme of this project, but as it turns out that baquelite was very tough after having done maybe 80 passes with the laser angraver we eventually had to give up.

A week later we tried again, using MDF instead, and this worked well. All pieces fit together nicely, and the display is now finally starting to take shape!

System boards and first power up[edit]

The first screen shown on the display was generated by internal timing violations in the FPGA. Pretty cool "bug" though :)

The system boards were screwed directly into the laser cut frame using plastic distances to ensure they are kept far enough from the matrix drivers to ensure they can not come in electrical contact with the drivers.

IDC connectors and flat cables are used to connect all of the boards together. I realized (thankfully before turning power on for the first time) that the system carries way to much power to be handled by the thin copper layers of the pcb substrates, so I reinforced all large current carriers with thick EK wires. The switched row-driver currents are carried over dual wires in a flat cable which means each wire will be carrying an avererage of 750mA (6A at 1/8 duty). They get warm, but not hot.

Initially I forgot to reinforce the ground return wire that carries 12A continously (for a white screen). This was also run through a flat cable using two wires and within seconds at full power it got so hot that it started melting the plastic I used to prevent short circuits during the temporary setup where the system boards were placed directly on the matrix drivers. This connection was reinforced with a thick FK cable using a powerpole connector.

Since the PSU is cabable of delivering 25A of power, there is definetely a possibility of fire and other bad things happening in case there is a short circuit. Given this fact I was a bit worried when I was about to power on the display for the first time, so you can imagine that I almost jumped through the roof when the system made a very loud tesla-coil-like sound with bright flickering white light when I first turned it on. Turns out I hade made a mistake in the VHDL code where outputs were not properly inverted causing the empty memory to be draws as all white. This requires a significant amount of power (~5A at the 12V side), and the 12V supply was current limited causing rapid reboots of the system which in turn produced the nasty sound (through the speakers) and the flickering light.

I had intended to slowly ramp up power by turning leds on in smaller groups just to be on the safe side, but as soon as I increased the current limit on the supply the system turned on, at full power, without any problems - and this was something I hadn't really expected since I had several worries about the design. I guess sometimes you just get things right from the start :)

Hardware debugging[edit]

Once everything was operational I started writing some demo code for the display and we soon discovered that there are a few hardware "bugs" in the system...

Afterglow[edit]

The drivers that supply the 12V control voltage for the mosfet row-drivers turn off very slowly causing afterglow primarily on the low-voltage green LEDs when the next row is turned on.

There are several options for correcting this, and replacing them with rail to rail op-amps on a piggyback board is probably the easiest. More on this at another time.

Resistors R2, R4, R6, ... R12 on the row driver board will be replaced by 270ohm resistors. This is not the most elegant solution, and it will increase the power consumption by ~20mA at all times but it is very easy to do and it will limit this problem to a level that is not noticeable even though it will not be completely removed.

Signal integrity[edit]

Also, the panel displays signal integrity problems causing some LEDs to briefly flicker on and off in certain situations. It's not all that noticable except in some static images and high-contrast moving graphics. Currently I don't have any ideas on how to properly correct this problem but I'm trying different solutions including better power filtering by distributing capacitors throughout the system, and removing high frequency interference from the data lines using pico-range capacitors.

When scoping the data lines they look intact even at the furthest end from the drivers, but it's obvious that the drivers are picking up on unwanted noise since just hooking up the probe causes increased flickering that varies depending on how close the scope wire is to the display. Any help would be appreciated.

The signal integrity problem was caused by weak power connections in the matrix drivers. If a single column has alot of pixels that are to be turned on (does not matter for how long) they are all set to on during the first PWM cycle (then turned off after their respective pixel intensity/duty time). When the column is latched they all fire up simultaneously, pulling the ground connection ever so slightly towards the +5V drive voltage for the LEDs in effect causing a slight voltage increase on the ground and +3.3V wires that accumulate for each of the six panels on a column group. At the fifth and sixth panel the difference was big enough to place signal noise on the data lines in the trigger region of the inputs.

By rewriting the VHDL code so that pixels are turned on in a distributed fashion across the first 8 pwm cycles the electronics get the time they need to recover from the sudden current rush. Sadly, this decreases brightness of the panel by rougly 10%, but the panel is so bright it is hardly noticeable due to the non-linear perception curve of the eye. It seems I should be able to decrease the number of "distribution cycles" from 8 to at least 4 or maybe even 2, limiting this effect. There are also several other ways to increase the brightness by increasing the complexity of the FSM that drives the panel.

Audio noise[edit]

Due to the large currents being switched in the system the main power lines fluctuate slightly. When amplified in the audio filters these fluctuations become a significant and very annoying tone at ~1700hz with several noisy harmonics. This problem was anticipated and should easily be solved by power filtering for the audio filter components and a schmitt-triggered buffer for the noisy digital signals.

The cheapest choice turned out to be to build a separate regulator for the 3.3V and 5.0V used by the audio circuitry, but I also had to make some changes to the audio filter to reduce the amount of rf being picked up by this board. It is still not perfect, but the levels are now acceptable at normal volume.

Controllers[edit]

Prototype[edit]

The standard controllers will be constructed with a rotary encoder (Elma 36-step with press down switch) and action two buttons. This requires 5 control lines and the last control line will most likely be used as a serial port for more advanced controllers (repurposing my old guitar hero controllers is a tempting idea).

The prototype is as simple as can be - an experiment board with controllers mounted on it, without an enclosure.

Gamepad controller[edit]

Gamepad controller, ready for airbrushing.

The first real controller is in the works. It will be repurposed from a "TV Game Station" controller found amongst the tons of gear at Forskningsavdelningen. It has a digital pad, six action buttons and a select/start pair.

After removing all original buttons I used my pillar drill to lathe a wooden plate that fits snugly into the hole that used to hold the x-y pad. This plate now holds the rotary encoder. All button holes except two were filled with glass fibre plastic padding, which was also used to attach the rotary encoder plate. The controller was then sanded down in preparation for painting, which will be done by a friend of mine who is a "professional hobbyist" airbrush artist.

Joystick controller[edit]

The second controller will work in exactly the same way as the first one, but the idea is to use a flightstick instead of a gamepad for the chassis. Faidros has found one that may be suitable - we'll see once the first controller is finished.