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
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)
And yes! The Omegas Rocks! :D
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.
- 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.