Need Deteiled Datasheets to make a Gameingconsole with 2x Omega 2+
-
HI! I am developing a gameconsole with 2x Omega 2+ this is very funny because 2 of them have so much power, when you write your own Firmware from scratch with Assembler..
Status: Developing Operating System/Firmware
Specs:
Omega #1 = Main CPU for video (Output is 3D rendering over SPI and main calculations.
Omega #2 = For Input and Audio(5.1 over USB)
Screen: LCD, 320x240,16bpp
Gamepad: Digital, 12 Buttons
Any ideas are welcome here so i will try to release this Project..
Firmware: Custom. Yep it's really hard but i can do it..
I/O Interface: Muliplexed SPI, controlled over i2c (Actually only for the Screen and communication between Omega #1 and Omega #2, Gamepad and combinied RAM so that this System have 256MB Ram(it's a little bit slow but it works), a Spartan-7 will controll this..)
Yes! This is Hardware sided cheap and powerfull, but my fail is actually the software coding..
First tests are allready succesfull with constant 28-36fps, target are 60fps
I have to write better assemblercode.. xD
So i need detailed very much datasheets, i think a detailed datasheet for the Spartan-7 and Omega CPU(MT7688) will help too, some links with it are very welcome..
Simply to write better code and reach my target of the 60(fps)
Thanks!
And yes! The Omegas Rocks!
Any questions? Write it here, i will help you
-
Nice project idea. But why abandon the Linux OS and all the peripheral drivers and start everything writing from scratch? For the sake of a pure speed advantage or wanting to learn MIPS assembler? I feel like doing a UBoot bootloader + using baremetal C/C++ combination would have very similiar performance and be way more feasable to program.
Still as soon as you want something like USB for Audio you probably don't want to re-implement the USB stack and USB peripheral driver from scratch. Or multitasking. (maybe use FreeRTOS on an Omega? ;))
How is data shared between the Omegas? You say you have a 'combined RAM' but the memory / data bus of the Omega isn't exposed? How are they going to have shared memory?
As for the video output, I think the fastest way to output the framebuffer would actually be USB because of its highest available bitrate. That's why I started using USB display adapters (here), they have an ok performance for low resolutions (90FPS @ 160 × 144 @ 16bpp) but need substantial optimizations for higher resolutions. I did rendering to SPI displays here.
Or:
- use the even higher-speed Ethernet peripheral and an FPGA to render to a SPI display an HDMI encoder chip
- write framebuffer into shared RAM or a dedicated RAM which a FPGA renders out
The only problem I see with graphics / 3D performance is the missing GPU. Everything has to be done in software. Maybe you can at least accellerate a few 2D operations with DMA acellerated copying though. I was using software-rendered OpenGL here (MESA 3D).
The whole thing sounds a like a modern Nintendo64 (64-bit MIPS CPU @ 93.75MHz for game logic, 64-bit Reality Coprocessor @ 62.5MHz as GPU, audio processor, I/O processor, loadable with custom Microcode for programming the rendering stages), just that we have two 580MHz 32-bit MIPS cores now (with a 64-bit DSP).
links with it are very welcome
Only datasheet of the MT7688 I know of is at https://labs.mediatek.com/en/chipset/MT7688 and https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/documentation, I'd gather the rest of peripheral drivers from the linux source code and patches (https://github.com/OnionIoT/source) or other bare-metal implementation (e.g. GPIO)
Anyways if you want to work together I'd be a happy about a mail.