VoCore2 + DOOM Port

I spend around 10 hours finish this, looks like it is pretty easy to port exists project to using VoCore2 display.

First checkout source code from git@github.com:Vonger/Doom.git, thanks for its contributor jeffdoggett, other DOOM source code I can not even compile 🙂

Only need to change one file /Doom/Source/i_video.c

//	DOOM graphics stuff for VoCore2 Display, OpenWrt.
//  based on i_video.c.

#include "includes.h"
#include "libvodisp.h"

unsigned int SCREENWIDTH = 320;
unsigned int SCREENHEIGHT = 200;
unsigned int ORIGSCREENWIDTH = 320;
unsigned int ORIGSCREENHEIGHT = 200;

union pixel {
    struct _rgb {
        unsigned char red;
        unsigned char green;
        unsigned char blue;
    unsigned int full:24;
static union pixel palette_table[256];
static byte *framebuffer;

void I_InitGraphics (void)
    framebuffer = malloc(800 * 480 * 3);
    memset(framebuffer, 0, 800 * 480 * 3);


void I_ShutdownGraphics(void)

void I_SetPalette (byte* palette)
    unsigned int colour = 0;
    do {
        palette_table[colour].rgb.blue   = gammatable[usegamma][*palette++];
        palette_table[colour].rgb.green = gammatable[usegamma][*palette++];
        palette_table[colour].rgb.red  = gammatable[usegamma][*palette++];
    } while (++colour < 256);

void I_FinishUpdate (void)
    byte *src = screens[0], *dst = framebuffer;
    int i, j, pos;

    for (j = 0; j < SCREENHEIGHT; j++) {
        pos = j * 480 * 3;
        for (i = 0; i < SCREENWIDTH; i++)
            *(unsigned int *)(dst + pos + i * 3) = palette_table[*src++].full;


void I_ReadScreen (byte* scr)
    memcpy(scr, screens[0], SCREENWIDTH * SCREENHEIGHT);

void I_InitKeyboard (void)

void I_UpdateNoBlit (void)

void I_SetScreenSize (void)

void I_SetWindowName (const char * title)

void I_StartFrame (void)

void I_StartTic (void)

Here is necessary library and Makefile, you might need to modify.

Download: http://vonger.cn/misc/vocore2/doom.openwrt.tar.xz, uncompress and put it in /Doom/Source then compile.

VoCore2: UI Library 4

I want to make the display support SDL so we can play a lot of games and make app based on SDL2.

PS: I love DOS games 🙂

SDL2 supports directFB which is not maintained anymore.
So I am consider to write a video driver for my display.

In SDL source code, SDL_DirectFB_video.c, we can get every interface:

    /* Set the function pointers */
    device->VideoInit = DirectFB_VideoInit;
    device->VideoQuit = DirectFB_VideoQuit;
    device->GetDisplayModes = DirectFB_GetDisplayModes;
    device->SetDisplayMode = DirectFB_SetDisplayMode;
    device->PumpEvents = DirectFB_PumpEventsWindow;
    device->CreateSDLWindow = DirectFB_CreateWindow;
    device->CreateSDLWindowFrom = DirectFB_CreateWindowFrom;
    device->SetWindowTitle = DirectFB_SetWindowTitle;
    device->SetWindowIcon = DirectFB_SetWindowIcon;
    device->SetWindowPosition = DirectFB_SetWindowPosition;
    device->SetWindowSize = DirectFB_SetWindowSize;
    device->SetWindowOpacity = DirectFB_SetWindowOpacity;
    device->ShowWindow = DirectFB_ShowWindow;
    device->HideWindow = DirectFB_HideWindow;
    device->RaiseWindow = DirectFB_RaiseWindow;
    device->MaximizeWindow = DirectFB_MaximizeWindow;
    device->MinimizeWindow = DirectFB_MinimizeWindow;
    device->RestoreWindow = DirectFB_RestoreWindow;
    device->SetWindowGrab = DirectFB_SetWindowGrab;
    device->DestroyWindow = DirectFB_DestroyWindow;
    device->GetWindowWMInfo = DirectFB_GetWindowWMInfo;

    /* !!! FIXME: implement SetWindowBordered */

    device->GL_LoadLibrary = DirectFB_GL_LoadLibrary;
    device->GL_GetProcAddress = DirectFB_GL_GetProcAddress;
    device->GL_MakeCurrent = DirectFB_GL_MakeCurrent;

    device->GL_CreateContext = DirectFB_GL_CreateContext;
    device->GL_SetSwapInterval = DirectFB_GL_SetSwapInterval;
    device->GL_GetSwapInterval = DirectFB_GL_GetSwapInterval;
    device->GL_SwapWindow = DirectFB_GL_SwapWindow;
    device->GL_DeleteContext = DirectFB_GL_DeleteContext;


    /* Shaped window support */
    device->shape_driver.CreateShaper = DirectFB_CreateShaper;
    device->shape_driver.SetWindowShape = DirectFB_SetWindowShape;
    device->shape_driver.ResizeWindowShape = DirectFB_ResizeWindowShape;

    device->free = DirectFB_DeleteDevice;

Of course, I do not think VoCore2 can run OpenGL, because it do not have any video hardware, ignore that.

PS: mesa3d has a software mode but it must be very slow. 🙂

To be simple, we do not need shaped window support either…

OK, rest interfaces for windows look like necessary, every video driver has them.
So they are VideoInit/Quit, Get/SetDisplayModes, CreateSDLWindow/From, SetWindowTitle/Icon/Position/Size, Show/Hide/Raise/Maximize/Minimize/Restore/DestroyWindow.

But it still need to code a lot…
I find most of the interfaces are empty in its psp video driver, maybe there is a way to make everything simple.

Any good idea?


VoCore2: 5 ethernet + SD card

Currently default pinmux is one ethernet port + sdcard + i2s + i2c + refclk + many gpio.
Actually there is a hidden pinmux in mt7628 chip, we can use ethernet x 5 + sdcard without i2c/i2s.

Very interesting, this pinmux works well on VoCore2 but do not have any clue in datasheet.
We need to remove i2c pull up resistor to make it work normal.

Its pin order:


but also need to update driver to make it work. 🙂

VoCore2: Production Lifetime

Today, support get an interesting question, how long is the VoCore lifetime?
I think this is an important question for the people want to use VoCore2 as part of their production.

As we promised, VoCore2 life is not end until the chip stop production. Mainly VoCore2 have three chips, one DDR2, one CPU, one NOR flash, DDR2 and NOR flash are widely used in many area, so we can think it will keep production forever. The only problem is CPU.

VoCore first version is using RT5350F which is almost stop production by mediatek/ralink. I said ‘almost’, because we still able to buy it from MTK(not recycle chip, the new one). The only problem is its price is increased a lot, almost double of MT7628.

Chip companies such as mediatek will not allow their chips suddenly death, that is not good for themselves and not good for their loyal clients. Normally mediatek will increase the chip price month by month if they decide to end one production. One day, the old chip price will be higher than the new one, so why pay much to use old slow one but not the new fast low power consume one? At that time people will start to upgrade their production. For RT5350, this process is over three years.

Actually VoCore old version is still in production, but price is much higher than the one based on MT7628. When RT5350F price is same as MT7628, I removed VoCore from site, because MTK is giving a clear signal: we are going to stop, do not use it anymore.

MT7628 is coming around four years, it still have over 10 years lifetime, so no need to worry about VoCore2 🙂
note: MTK is not stupid, why stop a cash cow? unless nobody use it already.:)

VoCore2: UI library 2…

I find many good library.

Actually directFB is an good choose but currently it can not compile at all.

First is the one from China, named GuiLite, it has everything I need and its code is really simple, performance is good.

Second is littlevgl, very good interface and light weight.

Third is uGFX, also light weight but not totally free, for test and study it is free.

4th, μGUI, it is too light weight for VoCore2 🙂

I like C better than C++, so I’d like to choose one from littlevgl & uGFX if no better find.

VoCore2: UI Library

Now the screen is working, I need to find a good UI library for this screen.
Currently candidates are:

1. Qt embed.
2. SDL2.
3. miniGUI.

Qt embed consume a lot of memory and disk space, normally one application will take 10MB.
SDL2 is not designed for embed device UI.
miniGUI is a good project, but I did not use it before, might be hard to combine.

My display is true color and vocore2 has 128MB memory and cpu speed is good, can show beautiful user interface than the 51/ARM based single chip microcomputer. So maybe my best choice is Qt.

…but I am not sure if Qt is light enough to run on this, try first.

Qt has nice support to compile it 🙂

Qt is based on DirectFB, looks like directFB.org is abandoned, source code still valid at github.

Maybe I can directly use directdb?

VoCore2 USB Screen Part8

Trouble, trouble… framebuffer can not work normal in VoCore2.
I guess openwrt has some limit of the /dev/ node size.

My plan of driver is like this:

Kernel Side                    User/Client Side            Display
Framebuffer (memory)  ->read   vodisp agent app     ->     libusb 
                      <-write  other framebuffer app

For max compatible and speed, I use Simple Framebuffer driver in Linux kernel. Actually it just a free memory space used to store video data.

vodisp is a simple server read from frame buffer and send data by libusb to USB screen. And other application depends on frame buffer can directly write to frame buffer.

This should work, but get weird issue. When I write 1152000 bytes to framebuffer, I find Linux is dead, looks like internal deadlock.

This is really critical bug, even though USB display is still working, but can not compilable with framebuffer app, that is a great lose.