From what you drew, it looks like one of the pins of the cable goes to the DP pin of the Rockchip (pin #5), which is one of the two USB data pin ... very suspicious. Mmmmh, are you sure about that information ?

Soon our own PCEmulator for Rockchip ?
 

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 :p
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 !! :D

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 .. ;)

sid6581
Do you have the doc for the emulator? here is a dump what the interface supposed to look like.

The buttons below the image represent the buttons on the player , you got up, down, left, right menu, ok etc. Like you say not much to it, but missing from the source. Ought to be possible to recreate the interface though..

I have the chinese PDF file yes, so I know what it looks like.
I am going to try to do something very simple without button, just using keys for up/down etc etc, and using SDL to render the screen....
If it works we will be to see the trace in the command line window....

I have just compiled rk27xx.dll
I have to add my own functions for TR (trace)
Then I will try to start the system .....

I will let you know :)

We all have doc for PC_Emulator, it's inside This link was deleted archive with other documents.
But if you don't want to download 20 Mb just because of small document,
HERE it is

It's cool but unfortunately it does not help much.

I almost gave up on everything when I realized that the pccore.cpp is using source file that we don't have for implementing their OS on the PC-side.
Fortunately, they provide us with a precompiled pccore.obj !!! So it's ok to not have those files :)

I hope I am not going to find out other issues like this that make this impossible to achieve .... I am crossing my fingers and continuing digging into this .....

Here is what I got so far when I start "the emulator" :

Sys Disk Writable[0]
User Disk Writable[1]
SYSTEM INIT!
Open File[C:\RESOURCE\BID\BMP0.BIN] Failed!
Open File[C:\RESOURCE\BID\BMP0.BIN] Failed!
INIT SYS BMP STYLE FAILED!
Open File[C:\RESOURCE\FONT\FT12.BIN] Failed!
Open File[C:\RESOURCE\FONT\FT16.BIN] Failed!
Open File[C:\RESOURCE\FONT\FT24.BIN] Failed!
OPEN ASCII WIDTH FILE[C:\RESOURCE\LANGUAGE\ENGLISH\CWIDTH12.BIN]FAILED!
OPEN ASCII WIDTH FILE[C:\RESOURCE\LANGUAGE\ENGLISH\CWIDTH16.BIN]FAILED!
OPEN ASCII WIDTH FILE[C:\RESOURCE\LANGUAGE\ENGLISH\CWIDTH24.BIN]FAILED!
OPEN LANG TRANS FILE[C:\RESOURCE\LANGUAGE\CHINESE\GBK2U.BIN]FAILED!
Open File[C:\RESOURCE\SID\STRINGID.BIN] Failed!
Open File[C:\RESOURCE\SID\STRINGID.BIN] Failed!
INIT SYS LANGUAGE FAILED!
BMP BUFF SIZE[6c90fc] , NEED SIZE[200000]

I use the LCD functions and query some info:

-> Pointer on framebuffer = 103ba6a0
-> LCD Width = 320 LCD Height = 240

So I still have good hope everything can be achieved :)
I am going to relocated the resource to the right directory and try to get rid of all those "failed" messages.

Once it's error-free, I will display the framebuffer to my SDL window .....

Ouch that thing is trickier than expected...

The rk27dll.dll is compiled with the ROCK_FS define, by default.

Rockchip guys are probably testing their filesystem on the PC-side.
Maybe a disk image representing the NAND flash is created (?)
The problem is, the pc-side implementation of the file-system is masked to us and is pre-compiled in Library\PC\fs_vc_lib.lib that we statically link to rk27dll.dll
So, I have no idea where and what kind of disk image it wants to read, how to generate that image and so on.
It might be described in the docs, but it is all in chinese, and it does not seem they talk about this anyways.

So, I have removed the ROCK_FS preprocessor definition from the vc++ config.
I had a few errors related to audio that i simply commented in the code, so I can still generate my rk27dll.dll
I have spent a bunch of time looking at the whole code about FS, and i see that if ROCK_FS is not used, the PC-side code will use normal disk functions to open a disk, read/write files.

I went to the resource folder and started getResourc.bat, which generate a bunch of stuff in the Output directory.
I copied the Outout\Resource to C:\Resource and now the OS does not complain about anything anymore and it seems it has read the whole stuff.....

So ...... I am ready to finally try and display what's going on on the virtual LCD ...............

When trying to generate BMP0.bin, i get a bunch of messages due to chinese folder names :

Open File:C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\MusicguageBack174_223.bmp
Failed Cmd Failed!, argc=1,argv[0]=C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\M
usicguageBack174_223.bmp,Ret=1
Open File:C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\MusicMiddleBack0_102.bmp F
ailed Cmd Failed!, argc=1,argv[0]=C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\Mu
sicMiddleBack0_102.bmp,Ret=1

And so forth .....

How did you guy solved that one ? I need to generate this bmp0.bin properly it seems ....

I generated the BMP0.bin in the end. I had to rename all the bmps and the resource file.
I'll upload my build, then you can use it if you want.

Send big files the easy way. Files too large for email attachments? No problem!

If nothing can be done with the emulator the firmware does work on the player itself.

btw it expects a the path to be C:\rk27sdk_new\Resource\input\bmp\ etc

You're doing well, I was stumped with the emulator.;)