- High Performance / Low Latency Audio on Android
- Heat Music Synthesizer Android App – now live on Google Play
- Soon in the Google Play Store: Heat Synthesizer for Android
- 2012-2014: Heat Synthesizer Android App
- Car Radio: Android Head Unit review – Foryou Adayo AN6B01 / Nakamichi NMMC-1300 / OttoNavi K1 / Rydeen DV621 / HiTV iDroid 8000
Tag Archives: freescale
I decided to release my 56300 emulator project as open source. I added the whole project to bitbucket, feel free to download it here:
Though I didn’t post much, I coded much
Nearly all instructions are implemented. My test code is running, but not with the result I expected
There are some tricky parts that I have to solve at the moment. In the last days I spent much time on proper ccr updates, scaling modes, adding the support for the “latched” registers a,b,x and y to be able to handle parallel instructions correctlythat use the same register in both an ALU and a MOVE instruction.
The bugs in the 56300 family manual can be really annoying. It’s very clear to me that they copy-pasted the documentation from the older 16-bit DSP and then changed the doc to fit the new 24-bit DSP, but they missed some parts, which can be a real pain.
Additionally, some things aren’t explained detailed enough for emulation, the only thing I can do is to test it in the simulator GUI, which I found on the net. This one helps a lot!
Unfortunately, I’m still not able to tell how good it will perform once it’s completed. Most of the time I’m still testing in debug mode to find mistakes or to test something. The code isn’t optimized very well yet, but this will be the fun part
Meanwhile, most instructions are implemented, some are still missing though.
At the moment, I implement the Instruction Cache
Because the DSP 56362 that is used in the Powercore (Firewire) allows access to the instruction cache through P-memory, the instruction cache has to be emulated aswell.
That’s something I didn’t plan to do, the plock/pfree and other cache instructions are currently left empty because I thought I didn’t have to implement them. Well, things have changed, so they will be implemented properly and the instruction cache, too.
The DSP 56300 emulation took a big step forward this weekend. I implemented a lot of ALU instructions and many others, too.
To be able to handle the different register types (24,48,56 bits) more efficiently, I created a template class that respects all the different conversions when moving data between different registers during compilation time. This results in code that is solid and fast aswell.
To help me debugging, I created a little app that shows me register states and allows me to handle execution control:
Meanwhile, the first instructions are executed by the emulator.
The hardware stack is working (not the software stack extension though). A lot of move instructions run fine, jump and branch instructions, too. The do instruction is already supported aswell.
I have to rethink the implementation of the registers, though. It turns out that all those different operands in the move instructions are quite complicated, some of them place the data in the MSBs of the register (fractional numbers), some of them in the LSBs (integers).
It may get clearer to me once I started implementing more of the ALU operations. The only supported ones at the moment are bit manipulation instructions and comparison. The CCR bits get updated as they should and Bcc already works.