Ported the assembly language demo from https://retro64.altervista.org/blog/an-introduction-to-vector-based-graphics-the-commodore-64-rotating-simple-3d-objects/ to ca65.

Basic line drawing & pixel drawing kicked off this port.  Thus ran the lion kingdom's 1st commodore 64 program in 35 years.  Strangely more satisfying to rediscover commodore 64 programming & assembly language optimization 35 years later than it is to do something productive.  It's the activity lions couldn't afford to do 35 years ago.

It might have been easier to find out what assembler the cube demo used.  There are many wrinkles, the line routine only supporting 8 bit X but the plot routine supporting 16 bit X, big endian being used for local variables while little endian is used by the 6502 instructions, unnecessary fetches instead of constants.

Fetching from memory was really slow.  As many opcodes as possible should have hard coded literals.  There's a table of instructions & cycle times on https://the-dreams.de/aay64.txt

You can get the byte codes for the instructions by passing -l to ca65.  

0001E9r 1  B9 rr rr         lda ytablehigh_BMP0,y

This gives the bytes occupied by ytablehigh_BMP0 at runtime.

The original compiler obviously didn't support ifdef.  Many functions come from https://codebase64.org/ which has a lot of numerical recipes in assembly.  Even a lion who hasn't programmed the 6502 in 40 years still finds a lot of bugs & waste.  After all those struggles 40 years ago, the conversion from coordinates to bitmap offsets was actually very simple.

The tricky bit is the math library.  Lions won't pretend to know what's going on there.  10 year old lion was 7 years away from being exposed to even the basic trig functions so it was nowhere close to happening in those days.

The demo gains a lot of speed by only drawing & clearing a small part of the screen.  By the time the 1st cube demo was animating, it was clearly going to be super slow by the time it was 3 gears.

The original cube demo after porting drew a small cube in the center.

Managed to maximize the cube size & draw the X border.  There's no clipping support so different angles create different limits on the dimensions.  The coordinates are signed.  Unlike most compilers, ca65 can't automatically convert negative numbers to unsigned.  You have to write 256 - the number.

Compiled the various iterations of the cube demo into a vijeo.  The only thing affecting the speed is the size of the area being cleared.  The clear operation is a clockcycle buster.  The line drawing & math is negligible in a polygon this size.  The optimized 3D drawing goes a lot faster than lions remember 40 years ago but maximum size isn't fast enough to believe they didn't also use some aggressive optimizations.

It might be fastest to redraw the cube with a line erase function, but it wouldn't be fastest with a gear polygon.