• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by ahellmann - 2007-01-10
Last edited by BigBambi - 2010-06-05

FS#6524 - Sansa E2x0 emulator

Here is the source code to emulate Sansa firmware on a PC.

Until now I have done following components (rockbox used functionality only!):
- emulate cpu
- emulate ata (read only functionality)
- emulate display
- emulate memory
- emulate keys
- emulate timers
- log the executed code to disassembler file (including infos)

I can run the compiled rockbox.bin and play some games. :-) It is still very hackish, but works sufficiently to get an idea,
what the original/rockbox firmware does (unknown address access, program
flow, timings). Hopefully this also gives some hints, how the
DAC can be controlled (not in the near future).

Not supported yet:
- thumb code
- coprocessor
- firq / audio

- audio codecs

Input files needed in the emulator executable directory:
- partition.bin from the sansa
- (for rockbox binary)
- rockbox.bin (or of.bin from sansa)

Output file:
- disassembly.txt (logs the last n instructions in the instruction loop)

I compiled under MSVC, so be aware to get some porting problems, if you use
another compiler.


Closed by  BigBambi
2010-06-05 22:25
Reason for closing:  Out of Date

I played with this for a while, and installed the Windows SDK, but cannot get it to build in VS2005 Express. Unfortunately I have no idea how VS works, but it typically fails out linking or with type errors in sansa.c, depending on which of the settings I randomly change. Since most people here probably aren’t too familiar with VS and how to set it up, maybe you could post the VS project files too?

I once tried the VS2005 Express with no luck. It seems, that basic libraries are missing.
I used MSVC6.0 instead, which provides the complete package. Borland Turbo C V5.x would be
also ok. I have no experience with other IDEs. If you want to use a free compiler, why not
try to port this software to the VMware SDL compiler. You know, that you can compile
rockbox simulators? All necessary code is there (graphics, message loop, key input) waiting
to port this code. But I don’t know, wether the VMware includes a reasonable debugger.

Thanks for the tip, it works fine in VS6. I think it will also build in 2005 once you install the SDK, but I don’t know enough to make that work myself.

Anyway, since i don’t have a Sansa to dump a partition from, would it be possible for you to post the partition.bin file you used? (Assuming you have a relatively small partition you use for this, and not a whole 4 or 8GB one).

Here is my (as small as possible) sansa partition.bin I use for testing.

bot47 commented on 2007-01-16 19:54

Would someone be able to drop a build?

I have done some bugfixes to the cpu emulation and the game emulation.
Now at least the mp3-codec works as expected. Of cause you will get no sound.
- And I added the windows binary for playing around:

Took me a moment, but I see you need to also add the mpa.codec file to the directory. Unfortunately, it still doesn’t actually decode for me. It just sticks at 0 seconds and shows the play symbol. I also saw you have a save_wav function, but I never get any wav written.

Perhaps the build of rockbox I’m using is incorrect? Can I combine any rockbox.bin/ with your partition or do they need to be synced to specific cvs versions? (Basically, what do you actually read out of the partition file?) Also, is there a good way to edit the bin file?

Sorry for confusion, but the inclusion of mpa.codec and the separate writing into wav-file
was only for testing this specific codec.
Basically the mp3-codec is included in the ‘partition bin’. No need for external linking.
To read the output, I hacked the data-stream at specific code addresses.
You can use any rockbox.bin with the attached partition.bin. You only have to pay attention
to a possible interface change in the codecs/plugins. This can happen at any time. On
the real target you will face the same problem: You cannot simply update ‘rockbox.e200’ but you have to update the whole .rockbox directory. You will get a splash screen in
this situation.
The emulator reads all info from the partition.bin: mbr, config-sector, fat-table, files

Project Manager

How hard do you think it would be to adapt this to be a more generic PP emulator?

It would probably be helpful for reverse engineering other portalplayer platforms.

The code includes a generic arm7tdmi engine. So the code of all targets with this cpu will run on this emulator.
Some major parts are still missing though: thumb code execution, dual core support, documentation to make it more
usefull for others. I am currently working on the first, because I think already the bootloader does a lot of
initialization (at least on the sansa).
When I have finished this, I will check again, wether I can reach the standard sansa menu display
(until now I only get the sansa startup screen, then the same code is executed over and over (waiting for
the cop to show up?).
I don’t know exactly what is needed for a generic emulator. There is already the separation between general
code/memory and specialized registers/functionalities, which can widely vary between the different targets.
I can do more code cleanup, give input/output options. And to my understanding to run this emulator only
makes sence together with a decent debug environment. I don’t intend to add memory screens, disassembler
screen, breakpoint support and other fancy stuff to the emulator.

Update of the emulator code:
- now executes thumb and arm code
- all registers mapped in a consistant way
- minor code cleanup

Now the emu runs the original bootloader (bl.bin) until switching to the firmware file.
With i2c capturing it should be possible to figure out, how to
- shutdown (if hold switch activation is known)
- battery status (I added a dump of the i2c traffic for this in the zip)


I’m having trouble getting this to run. My build freezes after the Sandisk logo. Could you unzip it and tell me what files I’m missing?

So far, all I’ve done is edit paths to point to the files in the zip (instead of global paths) and of course I added all the files I saw mentioned in the the source. (930.6 KiB)

Hi saratoga,

You can run the emulator with three input files:
1. bl.rom: ‘hangs’ at the try to switch to the firmware file)
2. of.bin: ‘hangs’ at the attempt to start the COP)
3. rockbox.bin: runs complete rockbox (as implemented for now)
So it is normal, that you don’t get behind the startup screen, when running the bl.rom or the of.bin.

The next tasks for the emulator will be:
1. get a working flow from the bootloader into the firmware (not so hard)
2. add COP support (will be difficult)

Just realized I had to actually change emulator.c to point to rockbox.bin. Now I think I understand what you meant.

I cannot get it to decode the Mp3 though. It just sits at zero percent (but doesn’t freeze). The codec buffer has a few percent read in, and the PCM buffer is nearly full. Is this normal or do I need to change something?

If the PCM buffer is full, then it is probably decoding MP3s OK. It probably won’t actually play MP3‘s yet because they are done by a fiq (interrupt) handler and maybe that isn’t supported in the emulator yet?

Ah sounds good. I just want to look at memory accesses in the MP3 decoder. As long as its decoding I’m happy.

It builds under cygwin with
gcc -o sansa_emu.exe *.c -lgdi32

However, I get these errors in the GetTicks function:

sansa.c: In function `GetTicks':
sansa.c:15: error: parse error before "__emit"
sansa.c:15:16: invalid suffix "Fh" on integer constant
sansa.c:16:16: invalid suffix "h" on integer constant

But it seems to work ok without that function (I don’t see where it’s used).

I had a little bit of free time today, so I took a stab at adding a cache simulator to the emulator. The current version is almost useless, it logs ALL memory accesses to disk, which makes it impossibly slow AND causes it to dump 50-100MB of data per second of emulated time, but it does simulate 8KB of cache with a variable cacheline size and associativity. The replacement policy is hard coded to be Least Recently Fetched. I don’t know what the correct parameters for the PP chips are, but I did put in good guess as the defaults.

Eventually I want to integrate the cache data with the .map parser and have the emulator print out statistics instead of raw data. That should be fast enough to actually be useful. But that might take a while, so I’m tossing this out in case anyone wants to play with it until then. If you’re interested in actually profiling something, I suggest modifying the logMiss() and logHit() functions in emulator.c to only log the address of the code you’re interested in. Otherwise you’ll have 300MB of bootloader logs to dig through :)

I would like to see this in linux but I’m not as good as I’d like to be.
here is my first attempt to port it to sdl. It doesn’t do anything right now
I have to figure out what all the calls to windows.h do
if anyone wants to look at it, or help me out if they can.
you will need the sdl-dev libs

Read me.txt has a short log of what I changed and why, along with many todos

Toni, just wondering how far you’re planning on taking this emulator. Do you see it being able to boot the retail firmware anytime soon?

For what its worth, I am slowly working on the memory profiler here and there. Finally got it to spit out function names instead of memory addresses.

Hi saratoga,

I still plan to get the original code running.
To do so, I have to get the cop emulation running, which is tricky in several aspects.
So don’t expect this step soon (if ever).
I succeeded in running the boot.rom together with rockbox bootloader and firmware, but
trying to run the original PP5022.mi4 fails in the descrambling code. There seems to be
a bug in the cpu emulation.

Below is the output of my latest work on the emulator:

The logfile includes all register reading/writing from the sansa bootloader + sansa us-firmware.
The COP has been disabled for this purpose, according to my investigations there is no impact from the COP during startup.
The logfile shows:
- the startup bootloader sequence,
- the startup firmware sequence
- up to dma reading 10 x the mbr sector

I have removed following register addresses from the logfile (for size reduction pupose):

Sorry, the above log only includes the sansa firmware startup log.
Here is the complete log (with transition from bootloader to firmware).
The bl.rom I used here is 392.888Byte, probably 14.Jan.2007?
The OF.BIN is 5.419.520 Bytes

I succeeded to run the original sansa code up to the menue selection.
Unfortunately the interesting parts (the codecs) need correct COP support,
which is not yet implemented correctly.
I now mainly understand, how file dma is working in the sansa firmware.
Also some interrupts work well.

To make the emulator run the original sansa code, you now need a complete image of the flash.
To run rockbox firmware, you need to switch the CPU_INT_STAT definition. (see sansa.h).
Don’t be surprised about the strange rockbox colours, this is because the display
is configured for the sansa firmware now. The latest rockbox firmware unfortunately
breaks the emulator. I have to investigate the reason.

MikeS commented on 2007-05-11 17:31

Toni, this is the version you’re running or do you have something more up to date? I do want to get some real RE done and have been a bit lazy about getting this up and running. ‘Bout time I get some tools to answer questions I have instead of trying to outsource to you. :)

cax commented on 2007-05-12 11:09

Can this newer emulator running sansa original firmware give us any clue
about proper initialization of LCD to avoid “screen garbage” as described in  FS#6896  ?

Have you some updates for us?

Bibo commented on 2007-11-25 15:13

can someone tell me pls how can i run sansa emulator on pc (windows) step-by-step? Thanks

Thanks for the emulator! This could be quite useful for learning more about the hardware.

The binary kept crashing, so I removed the “dict.rock” related code from WinMain, rebuilt it with Cygwin and put a ROM image from my iPod as “of.bin”. It did quite a bit of firmware initialization and then got stuck in a loop. I patched the firmware image to not do Broadcom initialization, and now it’s stuck on some I2C stuff. I guess I should work on I2C emulation now. The main thing I want to do with it now is to find how the bootloader uses IDE0, because it’s faster than Rockbox.


Available keyboard shortcuts


Task Details

Task Editing