Anyone up for decompiling some 8080 code for Kaleidoscope?

Question

I came across a series of blog posts about Kaleidoscope, a demo program for the Cromemco Dazzler graphics card. The series implements an emulator for the system so that it could run this code again, which you can see in the page. It was a four-part series, with the last entry explaining the actual workings of the code.

Unfortunately, the author stopped working on his blog before part 4 was posted. In part 3 he describes the basic layout in pseudo-code, leaving the key details as do_something. Being unfamiliar with either the 8080 or Dazzler, figuring that bit out is beyond me.

I'm wondering if anyone out there would be willing to take up the task of decompiling this into a complete pseudo-code description? The code is only ~90 lines long. I'd love to make a Swift+SpriteKit conversion.

Answer 1

I had a look at the source and added a few comments (*1). Might not be the expected full high level abstract description, but should be still helpful as a first, tiny step to see its workings.

---

Doing this I think I can understand why the 4th instalment never happened: The program structure might be somewhat alien to today's programmers, expecting neat initialization and complex but clean math, supported by verbose handling of data elements :))

This is none of that. It's short, highly intervened, extreme compact and down to the bare minimum - can't imagine any compiler getting that kind of code when programmed without already implying these optimizations. It may take a second or third reading to see the beauty.

---

*1 - Bloated that beautiful 90 lines up to 255. Sorry. But it's at least a nice binary FFh complementing the code length of 7Fh :)

Answer 2

Thanks to @Raffzahn commented code (in his answer) I was able to port the code into simple C++ code:

//---------------------------------------------------------------------------
const int VRAM_xs=64,VRAM_ys=64;// resolution
BYTE VRAM[VRAM_ys][VRAM_xs];    // video ram
const DWORD pal[16]=            // color palette (VCL pf32bit format)
    {
    //00BBGGRR
    0x00000000,
    0x00000080,
    0x00008000,
    0x00008080,
    0x00800000,
    0x00800080,
    0x00808000,
    0x00808080,
    0x00000000,
    0x000000FF,
    0x0000FF00,
    0x0000FFFF,
    0x00FF0000,
    0x00FF00FF,
    0x00FFFF00,
    0x00FFFFFF,
    };
BYTE x=0,y=0,m=0;               // Kaleidoscope state
void Kaleidoscope()
    {
    const int xc=VRAM_xs>>1,yc=VRAM_ys>>1;  // center of screen for mirroring
    BYTE c,xx,yy,cc;
    // render
    for (c=0;c<32;c++)
        {
        // update position
        yy=y;
        y+=(x >>2)&m;
        x-=(yy>>2)&m;
        // render 4x mirrored pixels
        xx=x>>3;
        yy=y>>3;
        if (c&1) cc=c>>1; else cc=0;
        VRAM[yc-yy][xc-xx]=cc;
        VRAM[yc-yy][xc+xx]=cc;
        VRAM[yc+yy][xc-xx]=cc;
        VRAM[yc+yy][xc+xx]=cc;
        }
    x++; y++; m++;
    }
//---------------------------------------------------------------------------

You just call the Kaleidoscope() on each frame and then just visualize the content of VRAM[][] in gfx api used... In VCL I did it like this:

void TMain::draw()
    {
    if (!_redraw) return;

    // clear buffer
    bmp->Canvas->Brush->Color=clBlack;
    bmp->Canvas->FillRect(TRect(0,0,xs,ys));

    Kaleidoscope();

    int x,y,xx,yy,xxx,yyy;
    DWORD c;
    for (yy=0,y=0;y<VRAM_ys;y++,yy+=pixel_sz)
     for (xx=0,x=0;x<VRAM_xs;x++,xx+=pixel_sz)
        {
        c=pal[VRAM[y][x]&15];
        for (yyy=yy;yyy<yy+pixel_sz;yyy++)
         for (xxx=xx;xxx<xx+pixel_sz;xxx++)
          pyx[yyy][xxx]=c;
        }

    // render backbuffer
    Main->Canvas->Draw(0,0,bmp);
    _redraw=false;
    }

Where Main is app window and pyx[ys][xs] is direct pixel access to backbuffer bitmap bmp... Also BYTE,DWORD types are unsigned 8 and 32 bit integers so use whatever you have at disposal in case you do not have them or typedef them ...

Here preview:

PS I am not familiar with the Dazzler so The palette I created might be wrong and also I changed the iteration a bit (count also 0 as there where not as many black pixels as colored ones and the image tends to grow too much to my taste)...

Answer 3

Ok, here is my Swift+SpriteKit version. I'd love it if someone could check the logic in the main updateKalidescope method.

Very annoying: in assembler, adding 200 to a register containing 200 is perfectly legal and you'll get the 144 that you want. The same appears true for the C++ code above? In Swift, you have to clamp the results, because using a UInt8 will get you an overflow. sigh

A curiosity: this is built using Apple's SpriteKit template, which uses SKShapeNode. This gave <1 fps! Changing it to SKSpriteNode gives >60. It seems SKShapeNode is re-drawing (or something) every sprite even if its unchanged.

It's currently updating 60 fps, does that match the Dazzler, or would it have been 30 (or infinity?)