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.
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.