I haven't received my player yet, still I wish I could already toy around with the firmware, so I looked a little bit more into that emulator everybody has tried to compile...
Well, I don't think we have that "PCEmulator" that is shown in RK27_PC_Emulator_V1.0.pdf
I don't think compiling that RK27xx.dll file is difficult at all, I am almost there using VC++ 8.0 after handling a few missed files (debug stuff, mainly).
Rockchip people have been very smart in their approach of developing the OS for their chips
The bulk of the code is good ansi C and is platform independent, it will compile on both ARM and i386.
Of course, there is a bunch of exceptions when it comes to low-level, and for that, they have to have two different source files for both processors.
Also, I am not sure that for the i386, any mp3/video decode is available since those have many parts written in ZSP400 assembly. However, I am seeing some code that open sound channel on the PC, in that RK27xx.dll
Anyways, I simply believe that video and audio playback on the PC is not at all the goal of the PCEmulator
I presume
the goal is about the OS.
Writing games and improving the user interface can be done faster than with using the target (although, I presume you can probably do that using JTAG directly on their ARM chip).
So yeah, we all want that emulator...
In fact, the code is already there in that rk27xx.dll (It is really a dll, so don't try to rename it to .exe or so forth...)
That dll is just the i386 version of the actual ARM+ZSP code.
The problem is, we do not have the GUI front-end that is driving that little DLL
But ..... I do not think it is that a big deal to write our own !!
The DLL interface is fully described in rk27dll.h
You can see about 15 useful functions there, and that is what the GUI front-end must play with !
For most of them, just looking at their names and parameters is enough to understand what they do and how our GUI front-end should use them.
However if it is not self-explanatory, we can always look at their C implementation to be sure we get it right.
It seems very easy by looking at pccore.cpp
Let's see .......
The GUI probably first have to call
PCCoreSystemStartup(HWND hwnd , int ep);
At the end it should nicely call
RK27DLL_API void PCCoreSystemShutDown(void);
Those TR functions that I had to #define to nothing can be written by us in that missing debug.c file
This is very useful to display textual debugging info in the GUI (like you can see on the right side of PCEmulator).
Then, the GUI uses
RK27DLL_API char* RPCGetTraceBuffer(void);
RK27DLL_API void RPCSetTraceBuffer(void);
to retrieve the debug trace info ....
Those functions are not defined anyways in the SDK so i presume they were really part of that debug.c
We just have to write our own, it is easy.
Buttons and touchscreen must be simulated by the GUI front-end by calling
RK27DLL_API void PCKeySetKeyState(int keyScancode , int UporDown);
RK27DLL_API void PCTouchSetTouchState(int state , int x , int y);
As you can see it is very self-explicit.
To draw the actual screen, the GUI must first question the size:
RK27DLL_API INT16U PCGetLcdWidth(void);
RK27DLL_API INT16U PCGetLcdHeight(void);
RK27DLL_API INT16U PCGetLcdDisplayFlag(void); (always returns 0, not very interesting)
Finally, with those infos, the GUI can correctly display the screen from the pixel buffer:
RK27DLL_API LCD_RGBDATA* PCGetLcdLogicBuffer(void);
There are 2 functions left about simulationg IRQ :
RK27DLL_API void PCIGenerateIRQ(int irq);
RK27DLL_API void PCISetIrqData(INT32U irqIndex , INT32U irqData);
(for that I would have to see in the C code what behavior we can trigger, it might not be that useful for us at the beginning...)
There is one function for which I quickly looked at the C implementation
void __stdcall RkPCTimerTick(
HWND hWnd, // handle of CWnd that called SetTimer
UINT nMsg, // WM_TIMER
UINT nIDEvent, // timer identification
DWORD dwTime // system time
)
There is a comment in chinese that i don't understand and i see a 5ms.
That's the info i wanted
Our GUI front end should call this function every 5ms (which is pretty tight, btw).
I guess a "multi-media timer" will have to be used for this in the GUI.
This periodic timer is probably necessary for their multitask OS to function.
To handle any sort of animation on the screen for example.
(although I bet most of the important stuff is interrupt-driver, which switch tasks depending on the task priority)
That's all for now ..
1Likes
