Close
0%
0%

The Dingo Console

An Open Source fully hackable game console packed with features. Based on the Pentium III CPU!

Similar projects worth following
This project has been my lifelong dream since I was a third grader. Now, after years of planning and learning, I finally have a design I'm happy with and can start. The Dingo Console is, to the best of my knowledge, the first high-performance game console that is Open Source and meant to be hacked, even the FPGA based GPU. Here are the target specs:

Pentium III Coppermine CPU running at 800MHz

1GB 128 bit DDR667 RAM. RAM space is split with GPU.

8 core custom designed GPU running at 400+MHz

Programmable DSP with FX post processing

IDE port for a 2.5 inch laptop HDD / SDD

4 controller ports

Bluetooth also for controllers

Boot games from SD card

Wi-Fi

Supported resolutions 640x480 and 720x480

RS232 port for debugging

Plenty of hardware ports for hacking

The CPU:

The Pentium III CPU I'm using is similar to the one used in the original XBox, but runs at a higher core clock and has twice as much cache, but at a slower 100MHz bus. The Dingo Console will have eventually have an overclock function called After Burners, which effectively sets the core voltage to the maximum 2.1V*, the GPU voltage to 1.1V*, and sets the bus frequency to 120MHz*. To dissipate the extra heat, the fan will overvolt from 5V to 7V*. Since the bus is overclocked, the GPU and RAM are also overclocked. To prevent damage, the system will go back to it's standard speed if either the CPU or GPU hit a preset temperature, by default 85C*.

*Can be changed by the user in the BIOS, at their own risk.

The GPU / NB:

For the graphics, I'm making my own GPU architecture from scratch, and it will be programmed onto an Artix 6 FPGA. It will have 8 cores running at least 400 MHz, maybe more, and each having 256 KB of shader script cache, and the entire device will have a 4 MB texture cache. Unlike other console GPUs where the rendering is fixed, this device will behave more like a PC GPU and run shader scripts of my own language, something similar to GLSL.

The GPU will also dual purpose as the Northbridge. The CPU has to go through the GPU to access the RAM and peripheral devices. The GPU will split the RAM space dynamically, defaulting at 8 MB on startup. Then when the console boots into the game, the RAM split will change to what the game needs. The RAM controller will run at 667MHz.

The FPGA will have a JTAG port so you can reprogram it however you like. But due to the fact that it's attached to just about everything in the system, I highly advise not touching it unless you know exactly what you are doing.

  • Some more design changes

    FloppidyDingo12/21/2016 at 06:36 0 comments

    So I once again was not happy with my design, so I tweaked it a little.

    • I have enough information to use the PIII as the CPU, so that's staying.
    • I'm upping the RAM to 128 bit, but lowering the frequency to 667MHz. This still increases the bandwidth to 10.6 GB/S.
    • I'm ditching the CD drive entirely and having games only boot from SD cards or the hard drive if one is installed.
    • I'm making the console somewhat modular. The power supply will be removable and the AV out will be VGA format on a custom connector, but you can use adapter cords to convert it to any other format such as composite or HDMI.
    • I'm beefing up the GPU a bit. I'm now going to use an Artix 7 FPGA and upping the texture cache to 4MB. I'm also considering to remove having half the cores run out of phase from the others.
    • The fan is now a 5V laptop fan.

  • GPU architecture Part 1

    FloppidyDingo04/19/2016 at 00:04 0 comments

    I got more on my GPU architecture planned out, and I have come up with (in my opinion) a very efficient design. Instead of having all 8 cores running at the rising edge of the clock, half of them will operate at rising edge, and the other half at the falling edge. This way the GPU is always doing something. Next up, recall that each core has it's own code cache. Well that cache will operate at the opposite edge of the core's clock. So when the core sends a data request to the cache, the cache will process that request when the core settles into the next clock, so the data is ready when the next cycle begins. The texture cache will do the same thing, but I'll have to find a way to compensate for the fact that half the cores are running out of phase. Also, due to chip limitations, there will be 2MB of texture cache instead of 4.

    The GPU will also have two sets of FPUs. One will be a big FPU that processes less common operations. Then each core will have their own smaller personal FPU to handle more common operations. Both FPUs will be pipelined to allow for high frequencies, and the architecture for the FPU will allow an operation to run multiple times at once. So you could spam the add instruction, and the data will come out in the order you put the arguments in (as long as you don't overflow the pipeline). The pipeline registers will also load data at the opposite edge of the clock as the core. So when the core clock goes high, the register feeds data to the next stage. When the clock goes low, the register stores data from the previous stage. I will also try to give each core branch predicting and out-of-order execution, making them superscalar.

    I have also decided to not lock the GPU speed to 400 MHz, but instead experiment to see how hard I can push the Spartan 6 FPGA before I get graphical glitches. If anyone has anything other ideas to improve the architecture, then by all means let me know and I may implement it.

  • Reconsidering possible CPU options, and changing RAM setup.

    FloppidyDingo02/26/2016 at 05:39 0 comments

    I have done some thinking, and realize that I don't have the required docs to interface an FPGA with a PIII correctly. So I had an idea: if I really can't use the PIII, I'll just save it for later and implement my own CPU on a separate FPGA, or I could use one FPGA and make some sort of SoC. That way, I can work with a familiar architecture and an instruction set I know, because I made them. But I'll try my best to use the PIII. Perhaps I could strike a deal with Intel. Or maybe I could use a PowerPC cpu, or even an ARM core.

    As for the RAM, having it be socketed would not give the required memory bandwidth I need. So the RAM will instead be 512MB of DDR400 RAM, split across 8 32bit chips. This will give a bandwidth of 12.8 GB/s. That'll be able to handle a GPU and CPU at the same time no problem.

View all 3 project logs

Enjoy this project?

Share

Discussions

KennyAwesome wrote 02/26/2016 at 07:21 point

Which os? What games? Or are you DIY all of them by yourself?

  Are you sure? yes | no

FloppidyDingo wrote 02/26/2016 at 23:26 point

OS and games will be DIY as well, since all of the hardware is customized. The OS is going to be designed to be as little in the way as possible, so games can run at their absolute best. I will also create a design suite so it'll be easier to make games for this console. Maybe later I'll port Linux to run on it, but that'll wait. I do however want to port a few games to run on this console, not sure which ones though.

  Are you sure? yes | no

Dylan Brophy wrote 03/29/2017 at 01:51 point

I think porting java and LWJGL will bring you some games.  I feel like that could really help.  Then you have to port one thing but bring many games on. Just an idea.

  Are you sure? yes | no

FloppidyDingo wrote 03/29/2017 at 04:28 point

@Dylan Brophy I actually had that idea during the design process of this. Being that the GPU is going to be custom made and therefore will most likely not support OpenGL, I'll a have to hack together a cross compiler to give OpenGL compatibility. But yes, porting Java and LWJGL are on my to do list once this thing is running

  Are you sure? yes | no

aisflou wrote 01/21/2016 at 23:34 point

Amazing!! :D just the thing that you are going to do the graphics in a fpga your own... i have no words!!

Why the 256mb of RAM "only"?

I read from instructables that you are going to use the laptop version of the PIII, any reason not to use a "normal" one? maybe the heat?

Planning to make some sort of "portable" device? or its more like take all the "junk" and put it where you want, be creative, express yourself? :P

I will looking closer to your development, im really amazed!! :D

  Are you sure? yes | no

FloppidyDingo wrote 01/24/2016 at 21:51 point

Hello! Thanks for the comment, and sorry for the late reply. My RAM choice is because that's what I have on hand. Actually, I think I'll change the design so that the RAM is socketed rather than soldered on, exactly like in a PC, so that way the user can upgrade it.

I'm using the mobile PIII for three reasons: 1) Less heat, 2) Less power consumption, 3) It's what I have on hand.

I am as a training exercise making a portable console using an ARM processor. That way I'll have practice soldering BGA packages and routing high speed data busses. Then later on I have a Pentium M that I can put in another portable model. But let's see how these two go first.

  Are you sure? yes | no

aisflou wrote 01/24/2016 at 22:42 point

Thanks for the info!! :D you dont have to apologize for the "late reply" ;)

I will keep an eye on you!! hehehehe

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates