I’m happy to finally be able to let the cat out of the bag. Darron Schall and myself have been working on a low level 6502/6510 emulator and, based on that, on a Commodore C64 emulator/simulator.

The emulator is completely written in Actionscript 3 and runs on Flash Player 9. It loads the original binary C64 Kernel ROMs at runtime, and executes them just like the original hardware would do.

The sources are released under GPL, get them here:
Trac: https://mirror1.cvsdude.com/trac/osflash/fc64/
SVN: http://svn1.cvsdude.com/osflash/fc64/

Quoting Darrons blog post from today:

It’s still a work in progress, and we’re looking for hardware-nerds to step up to the plate and help us finish it. The CPU code is complete, but hasn’t been extensively tested. The memory code is a work in progress, and we haven’t had a chance to start on the display code yet. Still though, it’s a good start.

At this point, we’re just running the CPU as fast as possible without trying to get the timing completely accurate. On the debug Flash Player, it runs at ~2.5 MHz. On the release Flash Player, it runs at closer to 6 or 7 MHz. This is a good thing, as the original Commodore chip only runs at 1 MHz. So, in theory, it should be possible to emulate the games in real-time without any slow down or speed delays (holy @#!@).

The Flash Player 8.5 features a nifty API to dynamically load assets at runtime, using the flash.display.Loader and flash.system.ApplicationDomain classes. Let’s assume we have a package, test.c1, that we want to keep in a separate SWF and only load it into the main SWF when needed.

We create a project Main that has the following structure:

• Main.as
• Child1.as
• test/c1/TestClass.as

Child1.as is compiled into Child1.swf and contains test.c1.TestClass.

Main.as is our main application class that loads Child1.swf and uses test.c1.TestClass.

test/c1/TestClass.as

package test.c1
{
   public class TestClass
   {
      public function TestClass() { }

      public function method():String {
         return 'test.c1.TestClass.method()';
      }
   }
}

Child1.as

package
{
   import flash.display.Sprite;
   import test.c1.TestClass;

   public class Child1 extends Sprite
   {
      public var TestClassInst:TestClass;

      public function Child1() { }
   }
}

Main.as

package
{
   import flash.display.Sprite;
   import flash.display.Loader;
   import flash.system.ApplicationDomain;
   import flash.net.URLRequest;
   import flash.events.*;
   import flash.util.trace;

   public class Main extends Sprite
   {
      private var child1:Loader;
		
      public function Main()
      {
         var url1:URLRequest = new URLRequest('Child1.swf');
         url1.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain);

         child1 = new Loader();
         child1.addEventListener(EventType.COMPLETE, onChild1Complete);
         child1.load(url1);
      }

      private function onChild1Complete(e:Event):Void {
         trace('onChild1Complete ' + e);
         var c:Class = child1.loadeeInfo.applicationDomain.getClass('test.c1.TestClass');
         var co:Object = new c();
         trace('test.c1.TestClass.method() returns: ' + co.method());
      }
   }
}

Using this method we could have different implementations of an API in different SWFs, and load the one we need at runtime. Naturally, we would want to use interfaces to ensure the API implements the right things, and use those interfaces for both the external modules and the main app. Note that i instantiate test.c1.TestClass as an anonymous object in the above example (var co:Object = new c();). I actually should have provided an interface definition test.ITestClass that describes the features of that external class (var co:ITestClass = new c();), however the alpha of Flex Builder has a bug that currently prevents us from doing so. Macromedia is aware of that bug so hopefully this is fixed soon.