brooke/mandel-6502
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

update readme

Browse source
This commit is contained in:
Brooke Vibber 2023-01-06 17:28:35 -08:00
parent 32bd5a540c
commit b36ab77e97
1 changed files with 10 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
readme.md
View file

@ -3,18 +3,19 @@
Work-in-progress Mandelbrot fractal viewer for Atari 8-bit home computers. Mostly an excuse to write an integer multiplication routine for the 6502 for practice.
Goals:
* have fun learning 6502 assembly
* make an old machine do something inefficient as efficiently as possible.
* post cool screenshots of low-res fractals
Non-goals:
* maintain anything long-term (but feel free to copy/fork if you want to make major changes!)
Enjoy! I'll probably work on this off and on for the next few weeks until I've got it producing fractals.
-- brion, january 2023
## Current state
The 16-bit signed integer multiplication seems to be working, though I need to double-check it some more. It takes two 16-bit inputs and emits one 32-bit output in the zero page, using the Atari OS ROM's floating point registers as workspaces. Inputs are clobbered.
@ -23,9 +24,15 @@ The main loop is a basic add-and-shift, using 16-bit adds which requires flippin
The loop is unrolled which saves 148 cycles, but at the cost of making the routine quite large. This is an acceptable tradeoff for the Mandelbrot, where imul16 is the dominant performance cost and the rest of the program will be small.
The mandelbrot loop is partly sketched out but I have future updates to make on that.
The mandelbrot loop is now written out, but untested and probably buggy. With three multiplications, several additions/subtractions, and three sets of annoying bit shifts and rounds, it weighs in at 1939 - 3007 cycles per iteration.
I've also sketched out a 16-bit rounding macro, which is not yet committed.
## Next steps
After a quick once-over to make sure it looks right, it's probably time to slap a display list together and draw some pixels to the screen and see what happens.
Reaching max iterations (256 runs through the loop) will take a half second or so per pixel -- this can be optimized by keeping a buffer of a few past zx/zy values and checking for duplicates which would signal a loop that will never escape. (Another technique I learned from Fractint!)
160x192 is luckily only 30,720 pixels, so there's a hard rendering time limit of about 4.5 hours. :D
## Deps and build instructions