Working with PLASMA – Comparison to C

I wanted to compare PLASMA with CC65 on several different points. At this point, with my limited experience with PLASMA, I’ll just start with:

  • Easy of understanding/similarity
  • Speed

I took my “moving monster” test program and rewrote it using PLASMA to compare it to how I had it written in C. ┬áHaving read that PLASMA took some inspiration of it’s structure from modern languages, I was pleasantly surprised how similar the code for each is and how easy the port was. It actually helped me improve my C code a bit as well.

C code

// Put image on screen
void putImage(imageData *image, char page, char x, char y) {
    char b, f, r;
    // Convert X to byte offset
    b = xToByte[x];
    // Convert X to needed shift frame
    f = xToFrame[x] * image->height*image->width;
    // Draw frame line by line
    for (r = 0; r < image->height; r++) {;
        memcpy((char *)(hgrpage[page] + yToAddr[y + r] + b), image->data + f + (r * image->width), image->width);

int main() {
    int x = 0;
    int count = 0;
    // Clear both Hi-Res pages (Bad: Clearing holes too!)
    memset((char *)0x2000, 0, 0x2000);
    memset((char *)0x4000, 0, 0x2000);
    // Activate graphics
    POKE(-16304, 0);
    // Full screen graphics
    // Hi-Res graphics
    // Put initial image on non-displayed page so when we flip it's there
    putImage(&image, !page, 0, 30);
    // Move across the screen by 2
    for(x=2; x <= 200; x+=2) {
        // Flip page
        page = !page;
        POKE(showpage[page], 0)
        // Draw new image on non-displayed page
        putImage(&image, !page, x, 30);
        // Pause

    // Go back to page 0 (1)
    POKE(showpage[0], 0)

    // Text mode
    POKE(-16303, 0);



// Put image on screen
def putImage(imgdata, imgheight, imgwidth, page, x, y)
    byte b, f, r

    // Convert X to byte offset
    b = xToByte[x]

    // Comvert X to needed shift frame
    f = xToFrame[x] * imgwidth * imgheight

    // Draw frame line by line
    for r = 0 to imgheight-1
        memcpy(hgrpage[page] + yToAddr[y + r] + b, imgdata + f + (r * imgwidth), imgwidth)

// Clear both Hi-Res pages (Bad: Clearing holes too!)
memset(hgr1, 0, $2000)
memset(hgr2, 0, $2000)

// Activate graphics

// Full screen graphics

// Hi-Res graphics

// Put intial image on non-displayed page so when we flip it's there
putImage(@data, height, width, (!page&$01), 0, 30)

// Move across screen by 2
for x = 2 to 200 step 2

    // Flip page
    page = (!page&$01)

    // Drw new image on non-displayed page
    putImage(@data, height, width, (!page&$01), x, 30)

    // Pause
    for count = 1 to 500

// Go back to page 0 (1)

// Text mode

As you can see, they are very similar. Should be an easy move over for people familiar with C/Java and languages of that ilk. Very impressive.

Next I took a look at performance. When I originally started looking at comparing performance, I was shocked at the speed difference between the two (which I’ll show shortly). That was before I realized that I was wrong about PLASMA.

I was thinking that PLASMA was more of a “pre-assembler” or “pre-compiler” that took high level structures and generated 6502 assembly for the corresponding code. It actually produces byte-code that is then run under the PLASMA VM. This can be sped up by writing raw assembly for routines that need more power. Silly me.

Now, I don’t consider that a bad thing for the same reason I don’t consider it a bad thing for Java vs C. It’s just a different approach and both have their merits.

C Performance

PLASMA Performance

As you can see in the above videos, without some native assembly to do some of the heavy lifting where needed, the C compiled code runs much faster than the PLASMA code. With a byte-code VM, that is to be expected.

Again, I want to reiterate, this is not a bash on PLASMA at all. On the contrary, even with the little I’ve worked with it I’m very impressed with it and it’s an amazing piece of engineering. Especially doing a byte-code/VM on a 8-bit platform. Well done, well done.

I’m working on getting some timing routines in both the C side and the PLASMA side that will read from the No-Slot Clock, since it gives hundredths of seconds resolution. Then I’ll publish some exact numbers comparing the two. Again, not as a “C is faster/better” but just to show some of the trade-offs.

Leave a Reply

Your email address will not be published. Required fields are marked *