Q: Can you introduce FC64 to our readers?

DS: FC64 is a Commdore64 emulator written in ActionScript for Flash Player 9. An emulator is a system that acts as, or emulates, another system. A special Flash movie containing the emulator (FC64.swf) is loaded into the Flash Player. FC64 re-creates the Commodore64's hardware in a software layer. It understands how to interpret the instructions written for the original C64 hardware, and converts those instructions to ones that the Flash Player can understand. Through this process, original C64 programs can be run inside of a web browser just as if they were running an original C64 machine.

The technology stack looks roughly like this:

---------------------------------------
| C64 instructions (just 1s and 0s    |
| that have special meaning to a C64) |
---------------------------------------
                 |
  ----------------------------------
  |         FC64 Emulator          |
  | (pretends to be C64 hardware,  |
  | executes the C64 instructions) |
  ----------------------------------
                 |
 -----------------------------------
 |          Flash Player 9         |
 | (executes the instructions that |
 | the FC64 emulator tells it to)  |
 -----------------------------------
                 |
          ---------------
          | Web Browser |
          ---------------

CW: It's also worth mentioning that FC64 is an open source project, and we took great care to make the source code as modular as possible so that people can just take the FC64 core and use it to build emulators for other 6502 based hardware such as NES, Atari 2600, VIC-20 or Apple ][, just to name a few.

Q: How much time did it take to develop?

DS: This one is really hard to gauge. FC64 is a side project of both Claus and I, and as such it's hard to quantify the number of hours spent on it. Essentially, whenever we had free time and wanted to work on it, we did. An hour here and there... I'm sure it adds up, but it's hard to give an honest assessment. If project size is any indication of time, for what it's worth there are more than a few thousand lines of code and has been in development for more than a year.

Q: Where did you start from to start building the emulator?

DS: In April of 2005 I was sitting at a table at the FITC 2005 Conference with Grant, Ted, and Guy, and we were talking about pushing the limits of Flash. From my experience with emulators in college, and knowing that the Bitmap API was around, I thought it might be fun to try and write an emulator in ActionScript. I started working the emulator immediately after the conference. Originally it was codenamed "Wonderland" and it was meant to emulator a regular Nintendo Entertainment System (NES). I had a rough-version of the CPU working around July 2005 when my enthusiasm for the project started to wane. The project silently died and started collecting dust on my harddrive.

Then, later that year, I saw a weblog entry for a Chip8 emulator. Claus had left a comment about teaming up to write a MOS 6502 emulator. I wasn't sure how serious he was, but I sent him an email saying that I was working on a NES emulator and had the 6502 chip already done.

From there FC64 was born, I guess officially in December of 2005. Claus was more interested in the C64 hardware and was happy to have a heard start on it. I was happy to finally have some help, so we dusted off the old code and ran with it. We kept it closed-source for awhile while we silently made progress on it, and then I announced it as an open source project during my ActionScript 3 session at FITC 2006, almost exactly a year later from when the original idea had started.

Q: What are the tech specs of the Commodore 64 and what is currently being emulated?

CW: The 64 sports an eight bit 6510 processor running at around 1MHz, 64 kb of RAM and 20 kb of ROM. The 6510 is the compatible successor of the infamous 6502. The only noticeable difference between the two is the 6510s Internal I/O port used to map ROM and I/O register banks in and out (the 64 has a total of 88 kb memory, but the 6510 can only address 64 kb at a time).

Another important component is the VIC-II video chip, delivering a groundbreaking resolution of 320x200 pixel, 16 colors and 'Movable Object Blocks', better known as 'sprites'. In the 80s, people soon found out how to hack the VIC-II appropriately and achieved quite stunning visual effects, ultimately kicking off the demo scene and producing truckloads of games that soon brought the videogame console industry to a grinding halt.

All of the hardware above, and a bit more, is emulated in FC64 on an as low as possible level. The main thing that's missing yet is emulation of the third very important chip in the 64, the SID sound chip, which is today, 25 years later, still famous for it's characteristic sound and still being used to produce music. This is going to be a hard nut to crack. And although we already easily support advanced features of the VIC-II (like raster IRQs), I doubt that we will be able to get it render each and every dirty trick used in the demo scene (like line crunch, DMA delay and other bad line magic).

Well, let's see :)

Q: Was it easy to find the C64 technical documentation?

CW: Yes, there is plenty of information available online. Even today, almost 25 years after the C64 went into production, software is still developed by loyal enthusiasts, mostly active in the demo scene. This obviously requires detailed technical documentation, which has been carefully archived.

For example, many original books have been converted to the ASCII format (often hand-typed) by an initiative called "Project 64". There is also a wide variety of C64 fanzines available on the net containing a lot of invaluable tips and tricks, in depth tutorials, and undocumented hacks. The FC64 project wiki features a small collection of links to documents that helped us in developing FC64.

Q: How ROMS are loaded / imported in the emulator?

CW: We currently load ROMs directly into memory and support the common PRG and PXX file formats. Tape and floppy disk support, and support for the D64 file format (1541 floppy disk image) is on our roadmap.

Q: What are the games that are currently working in FC64?

CW: The demo currently features five carefully selected games, not only because they are placed in the public domain by their authors, but also because they don't make use of sprites (cough ;)). Some text adventures work, and a few other arcade games. I haven't tested too many other games yet, so there are probably some more that will work out the box.

Support for sprites is almost done, as well as support for the lo-res bitmap mode. We already have an internal build that correctly executes classics like Elite, Donkey Kong, Frogger, Hacker and Fort Apocalypse, and I expect a whole bunch of other games to “just work” [tm] with the next major release.

Q: What were the main difficulties you had to overcome while developing the emulator?

DS: As strange as it sounds, the biggest problem we've faced so far is really just finding the time to work on it. There's so much documentation about what the hardware should do, and Claus and I have experience in building emulators from previous projects, that it really just comes down to finding the time to devote to it since everything we need to know is readily available.

Tracking down a few of the bugs, however, has proven to be difficult. It's hard getting everything emulated perfectly, since when you emulate you even have to make sure to emulate bugs present in the original system.

The biggest hurdle, technology-wise, is probably sound generation because the Flash Player doesn't contain an API to make noise yet. However, two other people have recently joined the FC64 team to tackle that problem, and so far they're doing some amazing work. More on that later. :)

CW: The devil always is in the details. It's hard to get the internal timings of the original 64 hardware completely right, and a lot of games and demos depend on very cycle exact timings.

Q: What are the minimum requirements to run the emulator?

DS: To be honest, I'm not really sure. We're still adding new features which take up more resources and drive the minimum system requirements up. I can say that on two of my computers (a 2.4 GHz AMD 64, and a 3.4 GHz Pentium 4, both with 2 GB of ram), the emulator executes C64 programs faster than original C64 hardware does.

Because everything happens in a web browser though, it's hard to nail system requirements exactly. I'm going to guess and say a 1.6 GHz processor and 1 GB of ram for decent performance, though processor power is definitely more important than ram for this application. It will run on less, but I'm not sure what the user experience would be, and I'm not sure what the minimum requirements might be for an OSX-based system (either PPC or Intel).

CW: FC64 currently consumes only about 2 or 3MB of RAM, while it is close to maxing out the CPU especially when a lot is going on onscreen in the emulator (i.e. a lot of sprites and complex bitmap stuff). I am developing and testing on a 3GHz Pentium 4 and even complex games are still running at normal speed on that machine, but i could imagine that things are going to slow down on machines with slower processors.

Q: What are the new features introduced by Flex and the AVM2 that made this project possible?

DS: Speed, by far. ActionScript 3 has a completely new bytecode model and requires a brand new virtual machine to execute it, and was built from the ground up for killer performance. The code is Just-in-Time compiled, meaning the ActionScript bytecode is actually converted to native machine code on-the-fly for whatever processor is in your system. As a result, the new model is wicked fast.

There are new native data types as well. Obviously having an int and uint type allow us to keep CPU registers as integer values and speed up performance in calculations by avoiding some of the internal int-to-double number conversion that would otherwise take up some precious cycle time. In general, ActionScript 3 deals with bytes better and offers the type of low-level support that a project like FC64 needs.

The Bitmap API introduced in Flash 8 makes a world of difference as well. We can write pixel colors directly to the screen now, which is must more efficient than create a MovieClip for each pixel and using setRGB on it.

Another feature that wasn't a driving force for the project, but definitely is useful, is the new Loader class. Specifically, there isn't an API for generating sounds in the Flash Player. Through clever use of the Loader.loadBytes method, however, new members of the FC64 team (Martin Wood and Ralph Hauwert) have been exploring ways to leverage this functionality. By constructing a .swf file in memory as an array of bytes that contain the definition for the sound, and then loading that in-memory .swf into the Flash Player by passing that byte array through to a loadBytes call, the Flash Player thinks its just loading another .swf that has a sound and so consequently the sound is played. Something like this just wouldn't have been possible in earlier version of the Flash Player. It's really amazing to see this sound generation technique in action.

CW: I also love the new Proxy class, which basically is __resolve gone nuts. It can be used to intercept calls to an object's properties and methods, and we currently use it in FC64 to implement the MemoryManager.

Q: ActionScript 3 does not provide a "byte" data type, what type did you use instead? Does this have an impact on the final memory usage?

DS: Instead of using bytes, we're using ints. At first I was bothered by this. After all, an 8 bit system has 8 bit registers and the byte data type is 8 bits so it makes perfect sense to use the data type that best first. Using a 32-bit integer seems like a waste, and you would think that it would be inefficient. However, this turns out to not be the case. If the Flash Player supported a byte data type, it would 32 bits long anyway. In a class, memory would only be saved if the byte fields were adjacent and packed like in C. Additionally, accessing a byte is slower than accessing an int on 32-bit hardware, so really the byte data type doesn't buy anything.

The only part where it became tricky is overflow since bytes overflow long before ints do. For instance, if you add 1 to 0xFF, you should get 0 in the byte world, but instead you get 0x100. Care had to be taken to make sure that calculations stay within their required ranges, but I don't think the bounds enforcement is a performance bottleneck at all.

Q: Now that Flex builder is based on Eclipse developers have a great tool for coding. Did you find it helpful? Do you a wish list for further future improvements?

DS: FlexBuilder is awesome for coding in ActionScript 3. Flash developers finally have a first-class IDE to work in that gives good code insight and sports a killer debugger. No more messing with trace statements or Debug -> List Variables - just set a breakpoint and hit debug.

Personally, I've never had this much fun coding for Flash before, nor have I ever been this productive. It's a joy to use FlexBuilder, and since it's built on Eclipse it integrates with the other tools that I've been using for awhile anyway, such as Subclipse, CFEclipse, and the Java Development Tool (JDT). It's great being able to stay in the same IDE all day long.

As for a wishlist for future improvements, I think FlexBuilder is pretty solid as it is right now. However, there are some features that I miss when working with the JDT that I wish FlexBuilder had. For instance, the biggest is probably refactoring support, but I understand that's a huge undertaking to implement. I'd like see some of the little things like TODO: and FIXME: comments integrated into the Tasks view, better QuickFix support to auto-correct errors, ASDoc integration, etc. I'm excited to see what future versions of FlexBuilder bring to the table, and I know Adobe is actively working on making it better.

Q: Judging from the runtime speed of FC64, do you think the AVM2 would be capable of emulating even more sophisticated systems, maybe a 16 bit console?

CW: I honestly don't think so. You can probably get 16 bit CPUs emulated with Flash Player 9, but to emulate an entire computer system is a whole different kettle of fish, especially in regards to video. Video emulation is critical, and is quite processor intensive in FC64 already. Once we're done with sprite emulation, we probably won't have too many resources left.

Q: Many developers are probably still wondering about the main advantages of using AS 3.0 compared to AS 2. Could you give us a short overview?

DS: It's really night and day. It's hard to summarize here, but I'll just try to outline a few key points:

* Just-in-time compiled performance
* Better handling of binary data in general - see: ByteArray, Socket, Loader, etc.
* Run time error messages - no more things silently failing leaving you wondering what's wrong
* Finally a debugger that's really useful
* A killer IDE in FlexBuilder
* A brand new display list model that's more intuitive and more flexible
* E4X support to make working with XML a breeze

Once you use ActionScript 3 and get accustomed to it, it's hard to go back. Try building a project with it to work through some of the learning, and you'll see what I mean if you try and switch back to ActionScript 2.

Q: What are the next improvements you are going to add to FC64?

CW: Right now we are focusing on implementing sprites and sprite collision detection, along with more flexible keyboard mappings. Also, and I'm very excited about this, two new contributors have recently joined the team and are currently experimenting with emulating the SID (Sound Interface Device), as Darron mentioned earlier.

Q: FC64 is part of the open source flash community (www.osflash.org) This is probably one of the greatest initiatives in the Flash community ever. Now that the Flex2 SDK is available for free it will probably attract more developers. What do you foresee?

CW: We should really emphasize that the SDK is *FREE* (as in beer), and it comes with the command-line compiler and debugger, which are also *FREE* of course, and they even throw a *FREE* one CPU, unlimited users commercial Flex Data Services license at you. This is great, and is going to attract many developers who may have had issues with the previously rather designer oriented workflow and who were used
to having free access to their tools.

One should also not forget to mention MTASC and HaXe, the first being an open source ActionScript 2 compiler, the latter a whole new programming language (ECMA meets C++ meets Java I would say) plus open source compiler (that compiles to SWF 6 through 9, JavaScript and NekoVM bytecode) and the standalone NekoVM.

There is innovation going on everywhere. All of these free tools are surely going to pull more and more developers towards the Flash platform, hopefully resulting in more open source projects. The performance and the new API of Flash Player 9 make things possible that we wouldn't even dream about in Flash 8 days (not that long ago). I foresee amazing things coming down the road.

Q: Can you unveil your future open source projects?

CW: I currently have three projects in the pipeline.

The first one of course being FC64. We're not done yet. We're adding more features and soon I'm going to start working on a great application built on FC64: An interactive C64 community site where you are going to be able to not only play your favorite ROMs, but develop software on a C64, debug a C64, hack and rip a C64, and create artwork on a C64. Live. Web-based.

The second is a small one that's almost ready for release. It's called FZip and enables users to load standard ZIP archives and extract compressed files from it (while the archive is still loading). This comes extremely handy when you need to load many files into the player at runtime (such as thumbnails for image galleries or tile bitmaps for games, just to name two examples of many) because it completely eliminates the need for rather complicated loading queues and provides additional compression, if needed.

The third is DENG, a project that already has been released in its first version. DENG 2.0, that I'm working on whenever I find some free time, is supposed to become a generic AS3 application framework built on open web standards, rendering everything-XML-plus-CSS (like XHTML, SVG, RSS, XForms, XFrames, etc.) at runtime. Developers would be able to build everything from tiny web widgets to complex web applications without the need of learning yet another proprietary user interface language or anything Flash specific. This is my vision of a sane Web 3.0 or whatever you might want to call it.

DS: Obviously I want to continue with FC64. Claus has been the driving force behind the project lately, but I want to continue to contribute and watch it grow into something that no one thought was possible. A big area of interest for me is using the Socket class to create multi-player systems over the Internet. Imagine playing a two player C64 game with a friend from around the world. The original hardware confined multi-player games to the same living room, but with FC64 I hope that we can remove that barrier.

I'm also working on FVNC, a screen-sharing and remote-control solution using just the Flash Player. You can connect to a remote computer, and through your web browser you see the computer screen. As you click in your browser on the parts of the screen, the remote computer receives those actions and the display updates are pushed back through to the browser. I already have something that works, now I just need to optimize it and build out the feature set.

A third project of mine is just a simple Solitaire game I built to showcase the new Display List API, specifically the ability to reparent entire display hierarchies without having to recreate all of the individual visual elements by hand. That's a lot lower on the totem pole for me, but should be released eventually. It's done, but it just needs a few tweaks first.

I have some other projects in the works at various stages of development, but they're not far enough along yet to talk about any of them (and they might not ever be released, so I'd rather not mention them right now). Most of the hobby development time I have is focused on FC64 or FVNC.