JSIDPlay2: a cross-platform SID player and C64 emulator

Download the latest build.

JSIDPlay2 is more than just a sidplayer. We are focusing on providing a cross-platform emulator for the C64, including joystick, keyboard, drives, display, etc. In addition to that, we will support the C64 system and the formats used in HVSC and CGSC music formats, with the exception of Amiga PlaySID and sidplay1 music formats, which are identified by "_PSID.sid" extension. The project's sourceforge page is also the best way to obtain source code.

Consequently, I've moved the stuff pertaining to the C++ port elsewhere. I'm still maintaining new distortion improvements for the C++ codebase, but I am not going to port other emulation updates such as the rewrites of the CPU, CIA and VICs.

Why Java?

Java is relatively rare choice for project such as this (open source & real-time emulation). Thus the question is raised frequently enough to deserve a place on this page. While the usual knee-jerk reaction to Java seems to be "oh my god, why" and "java sucks", my opinion is that Java is actually a fairly excellent language, and that there's a lot of things going for Java:

It's here now and works. No waiting for Mono to grow up, or C++0x to get ready, or Vala, or any other modern language.
Provably working platform neautrality. End users can run the same build on OS X, Linux and Windows, whether on 32- or 64-bit CPUs. Developers can likewise use any platform, as the IDEs work roughly the same.
Several world-class IDEs to choose from, with debugging, code completion, symbol use tracking and refactoring.
Java makes a nicer programming environment than C++. I like Java's fast builds, and hot code replace that allows modifying code in realtime and seeing it run instantenously. On the other hand, all that runtime dynamic compilation causes a startup delay, one of the largest problems remaining with Java.
Fast enough runtime. Dynamic compilation gives Java a performance of 30–100 % of C code today. Based on my tests for JSidplay2, equivalent Java code works at 50 % of the speed of C++ version.
Debugging and tracing features: jsamp for sampling cpu usage profiling, jvisualvm for memory profiling, and an integrated debugger in Eclipse.
Java is now open source, with several functioning implementations to choose from. I recommend the official Sun JDK, but OpenJDK seems to work fine, too.
One can argue that the resid-fp modifications became possible only because CPUs of the last decade have got impossibly fast. They keep on getting faster, and the extra penalty incurred by Java is increasingly more affordable.
Unfortunately, mobile devices are generally too slow and memory constrained to run a project such as JSIDPlay2. I ported jsidplay2 to Dalvik VM one afternoon, and discovered that hardware floating point, JIT and something like the Snapdragon CPU are necessary before it will run fast enough. Chances are that the Android 2.2 and better can run asidplay on Nexus One.

In summary, using Java raises the baseline experience for application developer, especially when compared to development on Linux. The baseline is very low: usually only a syntax-highlighting editor, autotools, gdb and valgrind. I admit that choice of Java might lower the experience for end user, given that a java runtime may need to be installed first, the startup delay is annoying, etc., but these are tradeoffs that are well worth it from my perspective. I hope the downsides will further minimize in time. Based on my testing, the upcoming JDK7 release will run JSIDPlay2 with about 10 % improvement, but sadly offers no apparent improvement in startup time.

I might also add an imflammable rant here about the poor state of Linux APIs, regarding both sound and GUI programming. Java insulates you from these, although each platform will add its own quirks nevertheless. Sadly, Eclipse on Linux hasn't really worked well for me as every update of GTK+ seemingly breaks the SWT that Eclipse is built upon, and PulseAudio broke my sound output with Java, and so on.

What's going on with jsidplay2 these days?

The focus of development has been in improving the emulation in all areas. We have mostly piggybacked on the work done for VICE project, and its new cycle-exact emulation engine x64sc. I'm happy to say that I have also contributed something for this effort, so it's not been entirely one-sided. For instance, we have borrowed the CIA 6526/6526A emulation, and the 1541 code from VICE, and are thankful for the VICE project for these bits. In turn, jsidplay2 has provided the hints required to make VICE too pass Lorentz suite and some of those irqdma tests which used to fail for it.

CPU: We now pass the entire Lorentz suite. The CPU compatibility should be very good.
CIA: We pass Lorenz suite's CIA tests, and various VICE testprograms. The CIA compatibility should be very good.
VIC: We have a reasonably good, cycle-exact simulation of the VIC, and pass some very complicated VICE testprograms such as the irqdma suite. However, some sprite tests like those used by various emutesters, and some inline video mode changes are buggy.
C1541: The drive support is arguably fairly weak, and we suffer from compatibility issues in various demos. Yet, many things work just fine with jsidplay2.
ReSID: Sound work is always ongoing, but I consider the distortion emulation to be fairly complete and compatible.
Cartridges: We have started to add support for various classic cartridges and the CRT format. We can support normal 8k and 16k, and some freezer cartridges like atomic power and action replay.