Hi Thomas,
The first thing I'll need is a working M-Network implementation. I've started looking at Wickeycolumbus' E7 Template. Hopefully I can get that working this weekend. Once I have the bitmap running in actual RAM, I'll try implementing a line drawing routine.
Your cycle estimate is accurate. The C= Hacking article mentioned above gave an estimate of 38 cycles average per point plotted:
Fortunately, the third installment of the 3D article offers a clever optimization for line drawing that will reduce this value. But even a highly optimized solution will probably average 30 cycles per pixel.
The biggest problem is going to be drawing long lines, because they contain the most pixels. The demo image above contains ~700 pixels. A single line that spans the width of the buffer is 96 pixels, and it takes a long time to draw.
The half screen buffer method will get me down to ~350 pixels, but it will still be tough. On the bright side, this image is a worst case scenario. Most of the time the ships will be farther back, and therefore smaller and less effort to draw. My first demo will be something simple, like a box. You can't go wrong with a box.
The fall-back plan if I can't get this half-buffer solution to work would be to use two full 1K buffers, or reduce the screen size to 64 pixel height, so it would fit in 768 bytes, with 2 3-page buffers. Then I could spend multiple frames updating the buffer without worrying about a half-drawn buffer.
Or I could just try using half-drawn buffers, and see if that still looks acceptable. If you're spending 8 frames to draw a complex display, it might not be too bad if 1 of those 8 frames is only partially drawn.
The reality is I can't use the entire 2K of RAM on just screen buffers. Significant memory will still be needed for other aspects of the game. For example, every ship is going to need:
6 bytes RAM to define its position (X,Y,Z) x 2
3 bytes RAM to define its rotational orientation (X,Y,Z)
Either 1 or 3 bytes RAM to define its velocity (Either X,Y,Z velocity, or a 1-byte scalar that incorporates the rotational orientation to define the velocity vector)
And at least 256 bytes RAM will be needed to define all the lines necessary to be drawn for the display, with 4 bytes defining a line (X0,Y0 to X1,Y1). The demo ship is 41 lines, but I will likely reduce that down to 27 lines by making the back of the ship a trapezoid.
Using the Melody cart, I could probably just throw RAM at the problem. An ideal bank-switching solution for me would be:
3 slices
slice 1 - A 2K block of selectable ROM, from 8 2K sections
slice 2 - A 512 byte block of selectable RAM that uses 1K of addresses (for read and write), selectable from 8 512 byte sections, for a total of 4K RAM.
slice 3 - A fixed 1K block of ROM for common routines and to define the bankswitching for the other slices.
I took an upper-level computer graphics course back in college in the mid 90s that will help with some of this work. For the final project, we had to implement a 3D wire-frame object moving around the screen. Of course I chose to design a spaceship. But the class used these expensive high-end 60Mhz Pentium machines, so performance optimization wasn't much of a concern.