are certainly not a good idea if a program is supposed to be portable. Unfortunately that is exactly what ZXTune is using to parse the different binary music files.
“One of the rules of packed structs is that you have to access them directly through the packed struct type. In other words, you can’t, in general, take the address of a packed field and then access the field through that pointer, because the pointer type won’t reflect the packed attribute.” (sunfishcode)
Unfortunately ZXTune used boost::array instances within the various packed structs.. Problem: when methods are invoked on boost::array (or std::array, etc). The ‘this’ argument to the boost::array functions may be misaligned, but the boost::array functions themselves don’t know this.
On CPUs which don’t mind unaligned memory access you may get away within without realizing that there is a problem.. and in this case it was my attempt to cross-compile the program using Emscripten that revealed the issue. Not wanting to rewrite too much of the foreign code I opted for a quickfix: replacing the boost::array with a built-in array fixed the immediate problem…
Naturally a clean implementation should better refrain from depending on unaligned memory access at all… not all the CPUs are as forgiving as Emscripten.
(click on the below image for a live demo).
It was back “in the old days” and I remember my relief when some day I found out that all PCs were not necessarily mute: Thanks to some “walking frame” called “AdLib” they could actually make sounds… and a bit later things became pretty neat with the rise of Sound Blaster…
AdPlug plays sound data, originally created for the AdLib (OPL2) and Sound Blaster (Dual OPL2/OPL3) audio boards, directly from its original format on top of an emulator.
My latest bit of Xmas tinkering is a HTML5/WebAudio version of AdPlug (Thanks to Simon Peter and the other authors of AdPlug.). For a live demo click on the below image..
Having the building blocks of my SID player available (see earlier posts), it really was no brainer to take up the suggestion of a colleague to take his Rockbox version of a MOD player and also turn it into a Flash version (it took about half an hour).
To try out at least something new, I decided to tap the WebService of a popular chiptune page and learn how that is done with PHP. Also I am using AJAX to integrate the resulting data.
As I had already done in my SID version I am using a PHP/cURL based proxy script to work around the Flash security restrictions and load the music files indirectly from the respective domain.
The result can be seen here.
This next little experiment led me into the world of Joomla 2.59 (an open source CMS system). Since PHP and MySQL are among the few things that my web hoster is comfortable with, there wasn’t much of a choice really. Still I jumped at the opportunity to get some hands-on PHP5 experience.
As expected a simple Joomla site was quickly setup with pre-existing building blocks like user management, commenting functionality and a simple release system to share my source code. Also it came as no surprise that the ‘point & click’ based Joomla software development approach got hairy once I needed my own custom functionalities. With hairy I mean the energy that is wasted to find the different places (e.g. via plugins, modules and component config or site templates) that need patching to rectify the “incorrect turns” that the “framework” is otherwise taking (or to just add missing hooks).
To make the music player from my previous experiment a bit easier to use I decided to put it into its own floating window and integrate it with some HTML based playlist functionality. After some failed attempts to get my floating window re-positioning code to consistently work in different web browsers (using “plain HTML”), I ended up using jQuery which solved the respective problems just fine. jQuery then also proved useful for the CSS based highlight/expand/collapse functionalities that I added and later it was the base for implementing a dynatree.js based file browser with “load on demand” and “drag & drop” functionality.
The final result (here) turned out quite as I wanted.
Still I was somewhat surprised about the “immaturities” that sometimes manifested in the above tools. With that I mean that eventhough I used these tools superficially at best I already ran into a couple of bugs which previously had gone undetected – which does not speak for thourough testing. However it was a pleasure to then witness the speediness with which these bugs got fixed once they were reported (I hope they also created a new testcase.. ). Community driven software development at its best 🙂
When it appeared in the early 80s, the C64 home computer was appreciated particularily for the capabilities of its SID (Sound Interface Device) audio chip.
The SID audio chip featured tree channels, each with its ADSR envelope generator, ring modulation and filter capabilities. Technically it was a small revolution for the home computer domain of the time.
In the more than 30 years since the C64 first hit the shops, countless musicians have created tens of thousands tunes with that characteristic early 80s sythesizer sound (see High Voltage SID Collection). People that grew up with the C64 will certainly still remember some of them.
With the advent of the personal computer people started to program C64 emulators and by now there is quite a selection of more or less complex ones available for different platforms.. so far (i.e. when this experiment was done in 2012) none of these was available for the web browser.
Goal of the experiment: Create a lightweight C64 emulator that allows to playback original “music files” within the web browser (i.e. multi-platform). Lightweight meaning that the program should be fast enough to execute well also on computationally weak devices like smartphones. This certainly qualifies as a technically interesting if practically irrelevant ‘just for fun’ endeavor 🙂
The diagram to the right shows what the emulator is about: Contrarry to file formats like .mp3 or .ogg, .sid music files do NOT represent a dedicated audio file format but are in fact little more than arbitrarry C64 program files.
Within those programs any official as well as any undocumented C64 feature may actually be used to influence the SID chip’s audio output. An example of an official feature might be the program’s use of the SID chip’s independent oscillator register while an undocumented feature might be one of the ways to trick the SID chip into playing a specific audio sample:
The playback of audio samples was never an official feature of the SID chip.
The tricks exploited for the respective playback therefore are usually highly timing critical: While regular audio output is handled quite independently within the SID chip, sample playback must be explicitly handled by the program code, i.e. depending on specific execution times of 6510 CPU instructions, the timing of interrupts generated by the CIA timers or the 6667 video controller chip, etc. (Not to speak of timing interferences originating from the interactions between the different chips, e.g. the VIC may block the CPU during certain tasks, etc..)
Approach: Not having any experience in electrical engineering nor owning the real hardware for analysis, I decided to build on someone else’s existing SID emulation. I picked TinySid created by Rainer Sinsch because it is more compact than the more sophisticated competitors. This choice allowed me to get my ‘proof of concept’ going quickly – however I had to realize later that the existing emulation was limited to only parts of the CPU and the SID and none of the other above building blocks… so there was quite a bit of tinkering left for me to be done.
I did my ‘proof of concept’ with Adobe Flash since I had found that I could cross-compile the existing C code using Alchemy (TinySid is written in C.) This would also give me an opportunity to play with Flash (which I had not done before).
With a bit of extra AS3 code for the UI, the Alchemy compiled emulator code was up and running quite quicky. (It took a while though to then locate and fix the gaps in the existing emulation logic.) You might have a look here to see the completed player in action.
I also reached my cross platform goal, since the player runs about anywhere where Flash is available (e.g. even on my old HTC HD2 smartphone – reflashed to Android.. no pun intended).
It was fun doing some AS3 for a change, but coming from a C++ and Java background, the respective Flash development tools leave a lot to be desired. In particular when using Alchemy. It then helps to not make any programming errors.. 😉